Upgraded to Netty 4 #14
Conversation
|
Wow, almost a complete re-write! Nice job. |
|
Yes, Netty 4 is very different to Netty 3 - but also implementing back pressure rather than buffer limits meant it changed significantly. |
|
Yep, I've heard that backpressure is a good thing. ;-) |
| } | ||
| } | ||
| }); | ||
| private final Map<Integer, List<WriteMessage>> bufferedEvents = new HashMap<>(); |
There was a problem hiding this comment.
|
really complete rewrite ,so seems like the architecture keep the same ,and the akka stream will work on the HttpMessage level. |
|
Added travis, and it's now passing. |
| /** | ||
| * The number of requests in flight | ||
| */ | ||
| private final AtomicInteger inFlight = new AtomicInteger(); |
There was a problem hiding this comment.
inFlight should use int
channel is only one to an event loop,and an event loop is backend by a thread,and the bind between channel<->eventloop will keep during the eventloop's lifetime.so I think it's threadsafe.why AtomicInteger?
There was a problem hiding this comment.
Ah, I did not know that Netty 4 had a new thread model that made things thread safe. That should let me simplify this somewhat.
There was a problem hiding this comment.
Updated - I actually removed inFlight since it can be determined from receive sequence and current sending sequence.
There was a problem hiding this comment.
|
@normanmaurer would you mind help a little here.Netty3 to Netty4 is a big jump. thanks very much. |
jroper
force-pushed
the
netty-4
branch
2 times, most recently
from
8aca1f9 to
268f498
Compare
In addition, made the following changes to the way the handler works: * Messages are buffered in a hash map by sequence ID if it's not the right time for the sequence. * Removed subsequence ordering - writes for a given request are required to be sequential without the pipelining handler, so with it we can assume the same. * Replaced buffer limit with back pressure - if the number of in flight requests exceeds a high water mark, the handler now exerts back pressure on the client by blocking read completed events, and unblocks them, and requests a new read, when a low watermark is reached.
|
Apparently you need to add channelActive() override and set inactive=false, otherwise pipelining test fails because writeInSequence never puts messages into buffer thinking the channel is inactive. |
In addition, made the following changes to the way the handler works: