Skip to content
Commits on May 31, 2016
  1. @normanmaurer

    Allow to change link capacity via system property

    Motivation:
    
    Sometimes people may want to trade GC with memory overhead. For this it can be useful to allow to change the capacity of the array that is hold in the Link that is used by the Recycler internally.
    
    Modifications:
    
    Introduce a new system property , io.netty.recycler.linkCapacity which allows to change the capcity.
    
    Result:
    
    More flexible configuration of netty.
    normanmaurer committed May 25, 2016
  2. @normanmaurer
  3. @normanmaurer

    Ensure the same ByteBufAllocator is used in the EmbeddedChannel when …

    …compress / decompress. Related to [#5294]
    
    Motivation:
    
    The user may specify to use a different allocator then the default. In this case we need to ensure it is shared when creating the EmbeddedChannel inside of a ChannelHandler
    
    Modifications:
    
    Use the config of the "original" Channel in the EmbeddedChannel and so share the same allocator etc.
    
    Result:
    
    Same type of buffers are used.
    normanmaurer committed May 22, 2016
Commits on May 30, 2016
  1. @normanmaurer

    Add optimized version of setZero(...) / writeZero(...) for Unsafe*Byt…

    …eBuf implementations
    
    Motivation:
    
    Unsafe offers a method to set memory to a specific value. This can be used to implement an optimized version of setZero(...) and writeZero(...)
    
    Modifications:
    
    Add implementation for all Unsafe*ByteBuf implementations.
    
    Result:
    
    Faster setZero(...) and writeZero(...)
    normanmaurer committed May 23, 2016
  2. @normanmaurer

    Fix small race in DefaultChannelPipeline introduced by a729e0f

    Motivation:
    
    There is a small race while adding handlers to the pipeline because callHandlerAddedForAllHandlers() may not be run when the user calls add* but the Channel is already registered.
    
    Modifications:
    
    Ensure we always delay handlerAdded(..) / handlerRemoved(...) until callHandlerAddedForAllHandlers() was called.
    
    Result:
    
    No more race on pipeline modifications possible.
    normanmaurer committed May 30, 2016
  3. @normanmaurer

    Remove volatile where not needed.

    Motivation:
    
    We can remove the volatile keyword from the cached Runnables as at worse these will just be re-created.
    
    Modifications:
    
    Remove volatile.
    
    Result:
    
    Less overhead.
    normanmaurer committed May 25, 2016
Commits on May 28, 2016
  1. @normanmaurer

    [#5297] Ensure calling NioEventLoop.pendingTasks() and EpollEventLoop…

    ….pendingTasks() will not produce livelock
    
    Motivation:
    
    SingleThreadEventExecutor.pendingTasks() will call taskQueue.size() to get the number of pending tasks in the queue. This is not safe when using MpscLinkedQueue as size() is only allowed to be called by a single consumer.
    
    Modifications:
    
    Ensure size() is only called from the EventLoop.
    
    Result:
    
    No more livelock possible when call pendingTasks, no matter from which thread it is done.
    normanmaurer committed May 23, 2016
Commits on May 25, 2016
  1. @normanmaurer
  2. @normanmaurer
Commits on May 24, 2016
  1. @normanmaurer

    [#5239] Allow adding handlers to pipeline with null name.

    Motivation:
    
    While doing 8fe3c83 I made a change which disallowed using null as name for handlers in the pipeline (this generated a new name before).
    
    Modifications:
    
    Revert to old behaviour and adding test case.
    
    Result:
    
    Allow null name again
    normanmaurer committed May 23, 2016
Commits on May 22, 2016
  1. @normanmaurer
  2. @normanmaurer

    Update tcnative version

    Motivation:
    
    Previous tcnative version had a bug with the uberjar on windows.
    
    Modifications:
    
    Update version.
    
    Result:
    
    Depend on latest tcnative version.
    normanmaurer committed May 20, 2016
Commits on May 21, 2016
  1. @normanmaurer

    Add CompositeByteBuf.addComponent(boolean ...) method to simplify usage

    Motivation:
    
    At the moment the user is responsible to increase the writer index of the composite buffer when a new component is added. We should add some methods that handle this for the user as this is the most popular usage of the composite buffer.
    
    Modifications:
    
    Add new methods that autoamtically increase the writerIndex when buffers are added.
    
    Result:
    
    Easier usage of CompositeByteBuf.
    normanmaurer committed May 17, 2016
  2. @normanmaurer

    Decouple DefaultChannelPipeline from AbstractChannel

    Motivation:
    
    DefaultChannelPipeline was tightly coupled to AbstractChannel which is not really needed.
    
    Modifications:
    
    Move logic of calling handlerAdded(...) for handlers that were added before the Channel was registered to DefaultChannelPipeline by making it part of the head context.
    
    Result:
    
    Less coupling and so be able to use DefaultChannelPipeline also with other Channel implementations that not extend AbstractChannel
    normanmaurer committed May 20, 2016
  3. @normanmaurer

    Decouple AbstractChannel and AbstractChannelHandlerContext

    Motivation:
    
    We do a "blind" cast to AbstractChannel in AbstractChannelHandlerContext which we should better no do. It would be better to decouble AbstractChannelHandlerContext from AbstractChannel.
    
    Modifications:
    
    Decouble AbstractChannelHandlerContext from AbstractChannel by move logic to DefaultChannelPipeline
    
    Result:
    
    Less coubling and less casting.
    normanmaurer committed May 20, 2016
  4. @normanmaurer

    [#4906] Ensure addLast(...) works as expected in EmbeddedChannel

    Motivation:
    
    If the user will use addLast(...) on the ChannelPipeline of EmbeddedChannel after its constructor was run it will break the EmbeddedChannel as it will not be able to collect inbound messages and exceptions.
    
    Modifications:
    
    Ensure addLast(...) work as expected by move the logic of handling messages and exceptions ti protected methods of DefaultChannelPipeline and use a custom implementation for EmbeddedChannel
    
    Result:
    
    addLast(...) works as expected when using EmbeddedChannel.
    normanmaurer committed May 20, 2016
  5. @normanmaurer

    Ensure all methods are correctly override in *LeakAware*ByteBuf imple…

    …mentations
    
    Motivation:
    
    We missed to override a few methods and so some actions on the ByteBuf failed.
    
    Modifications:
    
    - Override all methods
    - Add unit tests to ensure all is fixed.
    
    Result:
    
    All *LeakAware*ByteBuf have correct implementations
    normanmaurer committed May 17, 2016
Commits on May 20, 2016
  1. @normanmaurer

    Mark Recycler.recycle(...) deprecated and update usage.

    Motivation:
    
    Recycler.recycle(...) should not be used anymore and be replaced by Handle.recycle().
    
    Modifications:
    
    Mark it as deprecated and update usage.
    
    Result:
    
    Correctly document deprecated api.
    normanmaurer committed May 17, 2016
  2. @normanmaurer

    Add more tests for PoolArenaMetric

    Motivation:
    
    We should add some more tests for PoolarenaMetric
    
    Modifications:
    
    Add more tests
    
    Result:
    
    Better test coverage for metrics
    normanmaurer committed May 20, 2016
  3. @normanmaurer

    Remove unused class

    Motivation:
    
    We should remove unused classes that are package-private
    
    Modifications:
    
    Remove unused class
    
    Result:
    
    Less cruft in code-base.
    normanmaurer committed May 20, 2016
  4. @normanmaurer

    Add timeout to PooledByteBufAllocatorTest

    Motivation:
    
    Some tests in PooledByteBufAllocatorTest are blocking on a CountDownLatch. We should use a timeout on these tests so these will not block forever on a failure.
    
    Modifications:
    
    Add timeout param to @Test annotation
    
    Result:
    
    Have sane timeouts on tests.
    normanmaurer committed May 17, 2016
  5. @normanmaurer

    Correctly implement DefaultByteBufHolder.equals(...) and hashCode()

    Motivation:
    
    DefaultByteBufHolder.equals(...) and hashCode() should be implemented so it works correctly with instances that share the same content.
    
    Modifications:
    
    Add implementations and a unit-test.
    
    Result:
    
    Have correctly working equals(...) and hashCode() method
    normanmaurer committed May 13, 2016
  6. @normanmaurer

    Introduce CodecOutputList to reduce overhead of encoder/decoder

    Motivation:
    
    99dfc9e introduced some code that will more frequently try to forward messages out of the list of decoded messages to reduce latency and memory footprint. Unfortunally this has the side-effect that RecycleableArrayList.clear() will be called more often and so introduce some overhead as ArrayList will null out the array on each call.
    
    Modifications:
    
    - Introduce a CodecOutputList which allows to not null out the array until we recycle it and also allows to access internal array with extra range checks.
    - Add benchmark that add elements to different List implementations and clear them
    
    Result:
    
    Less overhead when decode / encode messages.
    
    Benchmark                                     (elements)   Mode  Cnt         Score        Error  Units
    CodecOutputListBenchmark.arrayList                     1  thrpt   20  24853764.609 ± 161582.376  ops/s
    CodecOutputListBenchmark.arrayList                     4  thrpt   20  17310636.508 ± 930517.403  ops/s
    CodecOutputListBenchmark.codecOutList                  1  thrpt   20  26670751.661 ± 587812.655  ops/s
    CodecOutputListBenchmark.codecOutList                  4  thrpt   20  25166421.089 ± 166945.599  ops/s
    CodecOutputListBenchmark.recyclableArrayList           1  thrpt   20  24565992.626 ± 210017.290  ops/s
    CodecOutputListBenchmark.recyclableArrayList           4  thrpt   20  18477881.775 ± 157003.777  ops/s
    
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 246.748 sec - in io.netty.handler.codec.CodecOutputListBenchmark
    normanmaurer committed May 3, 2016
Commits on May 18, 2016
  1. @normanmaurer

    [#5174] Expose Bootstrap getter methods and add some additional ones

    Motivation:
    
    The Bootstrap class (applies also to AbstractBootstrap and ServerBootstrap) has a few package private getter methods and some things such as #attr() and #options() aren't exposed at all.
    
    Modifications:
    
    Expose "getters" for configured things in a safe-manner via the config() method.
    
    Result:
    
    Easier for the user to check what is configured for a Bootstrap/ServerBootstrap.
    normanmaurer committed May 9, 2016
Commits on May 17, 2016
  1. @normanmaurer

    [#5104] Fix possible deadlock in DefaultChannelPipeline

    Motivation:
    
    When a user has multiple EventLoops in an EventLoopGroup and calls pipeline.add* / remove* / replace from an EventLoop that belongs to another Channel it is possible to deadlock if the other EventLoop does the same.
    
    Modification:
    
    - Only ensure the actual modification takes place in a synchronized block and not wait until the handlerAdded(...) / handlerRemoved(...) method is called. This is ok as we submit the task to the executor while still holding the look and so ensure correct order of pipeline modifications.
    - Ensure if an AbstractChannelHandlerContext is put in the linked-list structure but the handlerAdded(...) method was not called we skip it until handlerAdded(...) was called. This is needed to ensure handlerAdded(...) is always called first.
    
    Result:
    
    Its not possible to deadlock when modify the DefaultChannelPipeline.
    normanmaurer committed Apr 9, 2016
  2. @normanmaurer

    Remove ChannelHandlerInvoker

    Motivation:
    
    We tried to provide the ability for the user to change the semantics of the threading-model by delegate the invoking of the ChannelHandler to the ChannelHandlerInvoker. Unfortunually this not really worked out quite well and resulted in just more complexity and splitting of code that belongs together. We should remove the ChannelHandlerInvoker again and just do the same as in 4.0
    
    Modifications:
    
    Remove ChannelHandlerInvoker again and replace its usage in Http2MultiplexCodec
    
    Result:
    
    Easier code and less bad abstractions.
    normanmaurer committed May 17, 2016
Commits on May 14, 2016
  1. @normanmaurer

    [#3127] Allow to write with VoidPromise to Channels in ChannelGroup

    Motivation:
    
    Users sometimes want to use Channel.voidPromise() when write to a Channel to reduce GC-pressure. This should be also possible when write via a ChannelGroup.
    
    Modifications:
    
    Add new write(...) and writeAndFlush(...) overloads which allow to signale that a VoidPromise should be used to write to the Channel
    
    Result:
    
    Users can write with VoidPromise when using ChannelGroup
    normanmaurer committed May 12, 2016
  2. @normanmaurer

    Add ChannelInboundInvoker and ChannelOutboundInvoker

    Motivation:
    
    ChannelHandlerContext, ChannelPipeline and Channel share various method signatures. We should provide an interface to share.
    
    Modifications:
    
    Add ChannelInboundInvoker and ChannelOutboundInvoker and extend these.
    
    Result:
    
    Better API abstraction.
    normanmaurer committed May 12, 2016
  3. @normanmaurer
  4. @normanmaurer

    Use ConnectException when connection failed for LocalChannel

    Motivation:
    
    To be more consistent we should use ConnectException when we fail the connect attempt because no LocalServerChannel exists with the given address.
    
    Modifications:
    
    Use correct exception.
    
    Result:
    
    More consistent handling of connection refused between different transports.
    normanmaurer committed May 12, 2016
  5. @normanmaurer

    Ensure Bootstrap.connect(...) not throw IllegalStateException when re…

    …gistration is delayed.
    
    Motivation:
    
    Bootstrap.connect(...) tries to obtain the EventLoop of a Channel before it may be registered. This will cause an IllegalStateException. We need to ensure we handle the cause of late registration and not throw in this case.
    
    Modifications:
    
    Ensure we only try to access the EventLoop after the Channel is registered and handle the case of late registration.
    
    Result:
    
    Bootstrap.connect(...) not fails on late registration.
    normanmaurer committed May 12, 2016
  6. @normanmaurer

    Allow to extend IdleStateHandler and so provide more details for Idle…

    …StateEvents
    
    Motivation:
    
    Sometimes it is useful to include more details in the IdleStateEvents that are produced by the IdleStateHandler. For this users should be able to create their own IdleStateEvents that encapsulate more informations.
    
    Modifications:
    
    - Make IdleStateEvent constructor protected and the class non-final
    - Add protected method to IdleStateHandler that users can override and so create their own IdleStateEvents.
    
    Result:
    
    More flexible and customizable IdleStateEvents / IdleStateHandler
    normanmaurer committed May 9, 2016
Commits on May 13, 2016
  1. @normanmaurer
  2. @normanmaurer

    Fix possible leaks in Http2ServerDowngraderTest

    Motivation:
    
    We need to ensure we release all ReferenceCounted objects during tests to not leak.
    
    Modifications:
    
    Fix possible leaks by calling release()
    
    Result:
    
    No more leaks in tests.
    normanmaurer committed May 10, 2016
  3. @normanmaurer

    Ensure ChannelHandlerContext.attr(...) and ChannelHandlerContext.hasA…

    …ttr(...) has no semantic change
    
    Motivation:
    
    The ChannelHandlerContext.attr(...) and ChannelHandlerContext.hasAttr(...) delegated to Channel for the attributes which is a semantic change compared to 4.0 releases. We should not change the semantic to not break users applications when upgrading to 4.1.0
    
    Modifications:
    
    - Revert semantic change
    - Mark ChannelHandlerContext.attr(...) and hasAttr(...) as @deprecated so we can remove these later
    
    Result:
    
    Semantic of attribute operations on ChannelHandlerContext is the same in 4.1 as in 4.0 again.
    normanmaurer committed May 12, 2016
Something went wrong with that request. Please try again.