{"push_id":697548322,"size":5,"distinct_size":5,"ref":"refs/heads/CoalescingFlowController","head":"b06b5d13c6032fa6deb557d475f91895f623b8de","before":"7064d94fe7eb195dd1ee940e1b5c53d06b9b4b51","commits":[{"sha":"3308510bc94d86b45a4acacd90485002a129bbcd","author":{"email":"330e4303411e1fbd4ff825c4416851d277ea7a5f@apple.com","name":"Norman Maurer"},"message":"Allow to receive a ChannelGroupFuture that will be notified once all Channels are closed.\n\nMotivation:\n\nIt's useful to be able to be notified once all Channels that are part of the ChannelGroup are notified. This can for example be useful if you want to do a graceful shutdown.\n\nModifications:\n\n- Add ChannelGroup.newCloseFuture(...) which will be notified once all Channels are notified that are part of the ChannelGroup at the time of calling.\n\nResult:\n\nEasier to be notified once all Channels within a ChannelGroup are closed.","distinct":true,"url":"https://api.github.com/repos/louiscryan/netty/commits/3308510bc94d86b45a4acacd90485002a129bbcd"},{"sha":"c4d861844c8821c1810b20d890f7858f874546e8","author":{"email":"48c7abc241cbc1b37b75615aa26fe35b4afe0179@free.fr","name":"Frederic Bregier"},"message":"Get uploaded size while upload is in progress\n\nProposal to fix issue #3636\n\nMotivations:\nCurrently, while adding the next buffers to the decoder\n(`decoder.offer()`), there is no way to access to the current HTTP\nobject being decoded since it can only be available currently once fully\ndecoded by `decoder.hasNext()`.\nSome could want to know the progression on the overall transfer but also\nper HTTP object.\nWhile overall progression could be done using (if available) the global\nContent-Length of the request and taking into account each HttpContent\nsize, the per HttpData object progression is unknown.\n\nModifications:\n1) For HTTP object, `AbstractHttpData` has 2 protected properties named\n`definedSize` and `size`, respectively the supposely final size and the\ncurrent (decoded until now) size.\nThis provides a new method `definedSize()` to get the current value for\n`definedSize`. The `size` attribute is reachable by the `length()`\nmethod.\n\nNote however there are 2 different ways that currently managed the\n`definedSize`:\na) `Attribute`: it is reset each time the value is less than actual\n(when a buffer is added, the value is increased) since the final length\nis not known (no Content-Length)\nb) `FileUpload`: it is set at startup from the lengh provided\n\nSo these differences could lead in wrong perception;\na) `Attribute`: definedSize = size always\nb) `FileUpload`: definedSize >= size always\n\nTherefore the comment tries to explain clearly the different behaviors.\n\n2) In the InterfaceHttpPostRequestDecoder (and the derived classes), I\nadd a new method: `decoder.currentPartialHttpData()` which will return a\n`InterfaceHttpData` (if any) as the current `Attribute` or `FileUpload`\n(the 2 generic types), which will allow then the programmer to check\naccording to the real type (instance of) the 2 methods `definedSize()`\nand `length()`.\n\nThis method check if currentFileUpload or currentAttribute are null and\nreturns the one (only one could be not null) that is not null.\n\nNote that if this method returns null, it might mean 2 situations:\na) the last `HttpData` (whatever attribute or file upload) is already\nfinished and therefore accessible through `next()`\nb) there is not yet any `HttpData` in decoding (body not yet parsed for\ninstance)\n\nResult:\nThe developper has more access and therefore control on the current\nupload.\nThe coding from developper side could looks like in the example in\nHttpUloadServerHandler.","distinct":true,"url":"https://api.github.com/repos/louiscryan/netty/commits/c4d861844c8821c1810b20d890f7858f874546e8"},{"sha":"f5fd34e4ba996def9696ba3b596d61cd12ef3188","author":{"email":"a8c456a6b54fc41d6e961143bac21b6e0910a8a8@apple.com","name":"Scott Mitchell"},"message":"Channel writable bytes feature\n\nMotivation:\nTo avoid buffering too much it would be useful to get an estimate of how many bytes can be written to a Channel before it becomes unwritable.\n\nModifications:\n- Update the Channel interface to support 2 new methods. 1 to give how many bytes before unwritable. 1 to give how many bytes before writable.\n- Update the AbstractChannel implementation to delegate to the ChannelOutboundBuffer.\n\nResult:\nThe Channel interface supports 2 new methods which provide more visibility into writability.","distinct":true,"url":"https://api.github.com/repos/louiscryan/netty/commits/f5fd34e4ba996def9696ba3b596d61cd12ef3188"},{"sha":"8925fe4228392ff0e12d42d1797232497e2c57a5","author":{"email":"330e4303411e1fbd4ff825c4416851d277ea7a5f@apple.com","name":"Norman Maurer"},"message":"[#3881] FixedChannelPool creates 1 more channel than maxConnections\n\nMotivation:\n\nFixedChannelPool should enforce a number of maximal used channels, but due a bug we fail to correctly enforce this.\n\nModifications:\n\nChange check to correctly only acquire channel if we not hit the limit yet.\n\nResult:\n\nCorrect limiting.","distinct":true,"url":"https://api.github.com/repos/louiscryan/netty/commits/8925fe4228392ff0e12d42d1797232497e2c57a5"},{"sha":"b06b5d13c6032fa6deb557d475f91895f623b8de","author":{"email":"a7633af3c87391d70cbf6224f8db6fa997c866eb@google.com","name":"Louis Ryan"},"message":"Make the flow-controllers write fewer, fatter frames to improve throughput.\n\nMotivation:\n\nCoalescing many small writes into a larger DATA frame reduces framing overheads on the wire and reduces the number of calls to Http2FrameListeners on the remote side.\nDelaying the write of WINDOW_UPDATE until flush allows for more consumed bytes to be returned as the aggregate of consumed bytes is returned and not the amount consumed when the threshold was crossed.\n\nModifications:\n- Remote flow controller no longer immediately writes bytes when a flow-controlled payload is enqueued. Sequential data payloads are now merged into a single CompositeByteBuf which are written when 'writePendingBytes' is called.\n- Listener added to remote flow-controller which observes written bytes per stream.\n- Local flow-controller no longer immediately writes WINDOW_UPDATE when the ratio threshold is crossed. Now an explicit call to 'writeWindowUpdates' triggers the WINDOW_UPDATE for all streams who's ratio is exceeded at that time. This results in\n  fewer window updates being sent and more bytes being returned.\n- Http2ConnectionHandler.flush triggers 'writeWindowUpdates' on the local flow-controller followed by 'writePendingBytes' on the remote flow-controller so WINDOW_UPDATES preceed DATA frames on the wire.\n\nResult:\n- Better throughput for writing many small DATA chunks followed by a flush, saving 9-bytes per coalesced frame.\n- Fewer WINDOW_UPDATES being written and more flow-control bytes returned to remote side more quickly, thereby improving throughput.","distinct":true,"url":"https://api.github.com/repos/louiscryan/netty/commits/b06b5d13c6032fa6deb557d475f91895f623b8de"}]}