Commit Graph

1531 Commits

Author SHA1 Message Date
Norman Maurer
b6c320bd0a Add methods to easily release messages from inbound / outbound buffer of EmbeddedChannel
Motivation:

Often the user uses EmbeddedChannel within unit tests where the only "important" thing is to know if any pending messages were in the buffer and then release these.
We should provide methods for this so the user not need to manually loop through these and release.

Modifications:

Add methods to easily handle releasing of messages.

Result:

Less boiler-plate code for the user to write.
2016-03-24 11:15:29 +01:00
Norman Maurer
64dc03a25d [maven-release-plugin] prepare for next development iteration 2016-03-21 10:34:26 +01:00
Norman Maurer
e444e8d7a6 [maven-release-plugin] prepare release netty-4.0.35.Final 2016-03-21 10:32:08 +01:00
Tibor Csögör
4784f2761a trivial javadoc fixes
- fix the formatting of the diagram in ChannelFuture's javadoc
- update external link in AutobahnServer
- fix various spelling issues
2016-03-16 20:22:43 +01:00
Scott Mitchell
e775b49e95 Deprecate PromiseAggregator
Motivation:
PromiseAggregator's API allows for the aggregate promise to complete before the user is done adding promises. In order to support this use case the API structure would need to change in a breaking manner.

Modifications:
- Deprecate PromiseAggregator and subclasses
- Introduce PromiseCombiner which corrects these issues

Result:
PromiseCombiner corrects the deficiencies in PromiseAggregator.
2016-03-14 11:02:06 -07:00
Max Ng
ec946f8a3e Guard against re-entrance in PendingWriteQueue.
Motivation:

PendingWriteQueue should guard against re-entrant writes once
removeAndFailAll() is run.

Modifications:

removeAndFailAll() should repeat until the queue is finally empty.

Result:

assertEmpty() will always hold.
2016-03-14 08:53:13 +01:00
Norman Maurer
a47c03c3d7 Add asserts so users will see errors when try to use methods from outside the EventLoop.
Motivation:

We should guard users from using Unsafe methods from outside the EventLoop if not designed to do so.

Modifications:

Add asserts

Result:

Easier for users to detect miss-use.
2016-03-08 09:04:28 +01:00
Scott Mitchell
27c68a10ec DefaultChannelHandlerContext write leak
Motivation:
DefaultChannelHandlerContext calls a utility method validatePromise which may throw if the arguments are not valid. If this method throws then the message will not be released.

Modifications:
- If an exception is thrown the message should be released

Result:
No more leak in DefaultChannelHandlerContext.write
2016-03-07 09:30:11 -08:00
Xiaoyan Lin
1b231cbfe8 Fork SpscLinkedQueue and SpscLinkedAtomicQueue from JCTools
Motivation:

See #3746.

Modifications:

Fork SpscLinkedQueue and SpscLinkedAtomicQueue from JCTools based on 7846450e28

Result:

Add SpscLinkedQueue and SpscLinkedAtomicQueue and apply it in LocalChannel.
2016-02-22 15:55:23 +01:00
Roman Timushev
02329d10c7 Enable shutdownOutput for EpollDomainSocketChannel
Motivation:

See #4882
Modification:

isInputShutdown, isOutputShutdown and shutdownOutput methods moved from io.netty.channel.socket.SocketChannel to a new interface io.netty.channel.socket.DuplexChannel.
io.netty.channel.unix.DomainSocketChannel now extends DuplexChannel
Methods implementing DuplexChannel moved from EpollSocketChannel to AbstractEpollStreamChannel.
Result:

Possible to call shutdownOutput on EpollDomainSocketChannel
2016-02-18 18:09:48 -08:00
Norman Maurer
b6882a5d52 Ensure handlerAdded(...) and handlerRemoved(...) is always called from the right thread
Motiviation:

We should ensure that handlerAdded(...) and handlerRemoved(...) is always called from the EventExecutor that also invokes the other methods of the ChannelHandler. Also we need to ensure we always call handlerAdded(...) before any other method can be calld to ensure correct ordering.

Motifications:

- Ensure that the right thread is used to call the methods
- Ensure correct ordering
- Add tests

Result:

Respect the thread-model for handlerAdded(...) and handlerRemoved(...) and preserve correct ordering in all cases.
2016-02-12 14:30:33 -08:00
Norman Maurer
027e8224e4 [#4805] Respect isAutoRead() once re-register Channel
Motivation:

When a channel was registered before and is re-registered we need to respect ChannelConfig.isAutoRead() and so start reading one the registration task completes. This was done "by luck" before 15162202fb.

Modifications:

Explicit start reading once a Channel was re-registered if isAutoRead() is true.

Result:

Correctly receive data after re-registration completes.
2016-02-04 15:34:06 +01:00
Norman Maurer
64d1eea608 Correctly pass ChannelPromise on to the next ChannelOutboundHandler when use CombinedChannelDuplexHandler.
Motivation:

Due a regression introduced by e969b6917c we missed to pass the original ChannelPromise to the next ChannelOutboundHandler and so
may never notify the origin ChannelPromise. This is related to #4805.

Modifications:

- Correctly pass the ChannelPromise
- Add unit test.

Result:

Correctly pass the ChannelPromise on deregister(...)
2016-02-04 15:32:38 +01:00
fu.jian
dd2f9f9acb fix the issue netty#2944 in 4.0 #4809
Motivation:

fix the issue netty#2944

Modifications:

(1) use - instead of =>, use ! instead of :> due to the connection is bidirectional. What's more, toString() method don't know the direction or there is no need to know the direction when only log channel information.
(2) add L: before local address and R: before remote address.

Result:

after the fix, toString() won't confuse the user.
2016-02-02 21:42:45 +01:00
Norman Maurer
b647513b6b [maven-release-plugin] prepare for next development iteration 2016-01-29 09:57:10 +01:00
Norman Maurer
cf1777b619 [maven-release-plugin] prepare release netty-4.0.34.Final 2016-01-29 09:23:46 +01:00
Norman Maurer
ba381f1a27 Ensure ChannelHandler.handlerAdded(...) is always called as first method of the handler
Motivation:

If a user adds a ChannelHandler from outside the EventLoop it is possible to get into the situation that handlerAdded(...) is scheduled on the EventLoop and so called after another methods of the ChannelHandler as the EventLoop may already be executing on this point in time.

Modification:

- Ensure we always check if the handlerAdded(...) method was called already and if not add the currently needed call to the EventLoop so it will be picked up after handlerAdded(...) was called. This works as if the handler is added to the ChannelPipeline from outside the EventLoop the actual handlerAdded(...) operation is scheduled on the EventLoop.
- Some cleanup in the DefaultChannelPipeline

Result:

Correctly order of method executions of ChannelHandler.
2016-01-28 14:40:51 +01:00
Xiaoyan Lin
7bf3792e6f Fix ChannelOutboundHandlerAdapter javadoc
Motivation:

ChannelOutboundHandlerAdapter's javadoc has some minor issues.

Modifications:

Fix the minor javadoc issues and resolves #4752.

Result:

ChannelOutboundHandlerAdapter's javadoc issues are fixed.
2016-01-26 10:13:43 +01:00
Norman Maurer
d7d64137e0 Let CombinedChannelDuplexHandler correctly handle exceptionCaught. Related to [#4528]
Motivation:

ChannelInboundHandler and ChannelOutboundHandler both can implement exceptionCaught(...) method and so we need to dispatch to both of them.

Modifications:

- Correctly first dispatch exceptionCaught to the ChannelInboundHandler but also make sure the next handler it will be dispatched to will be the ChannelOutboundHandler
- Add removeInboundHandler() and removeOutboundHandler() which allows to remove one of the combined handlers

Result:

Correctly handle events
2016-01-18 10:09:07 +01:00
Norman Maurer
8bfbb35979 Ensure connectPromise is not notified before fireChannelActive() is called.
Motivation:

Our contract in Channels is that the promise should always be notified before the actual callbacks of the ChannelInboundHandler are called. This was not done in the LocalChannel and so the behavior was different to other Channel implementations.

Modifications:

- First complete the ChannelPromise then call fireChannelActive()
- Guard against NPE when doClose() was called before the task was executed.

Result:

Consistent behavior between LocalChannel and other Channel implementations.
2016-01-18 09:28:56 +01:00
Norman Maurer
c18ba23838 Fix AbstractChannelTest errors caused by incorrect mocking
Motivation:

In AbstractChannelTest we not correctly mocked some methods which could lead to test errors. That said it only showed up here when running from the IDE and not from the cmdLine.

Modifications:

Mock methods that are needed for the test

Result:

Test pass in the IDE as well.
2016-01-14 21:02:13 +01:00
Norman Maurer
951bacb0ca Allow to change if EmbeddedChannel should handle close() and disconnect() different.
Motivation:

At the moment EmbeddedChannel always handle close() and disconnect() the same way which also means that ChannelOutboundHandler.disconnect(...) will never called. We should allow to specify if these are handle different or not to make the use of EmbeddedChannel more flexible.

Modifications:

Add 2 other constructors which allow to specify if disconnect / close are handled the same way or differently.

Result:

More flexible usage of EmbeddedChannel possible.
2016-01-14 07:30:08 +01:00
Fernando van Loenhout
301c40adbd Fix issue #4676
Fixed spelling mistake at EmbeddedChannel#readOutbound()
2016-01-08 18:12:49 -08:00
fu.jian
c2c0d01ddb [#2363] Correctly null out SelectionKey[] when selectAgain
Motivation:

The prefix fix of #2363 did not correctly handle the case when selectAgain is true and so missed to null out entries.

Modifications:

Move the i++ from end of loop to beginning of loop

Result:

Entries in the array will be null out so allow to have these GC'ed once the Channel close
2016-01-08 09:01:53 +01:00
Norman Maurer
bdea94d807 Simplify synchronized syntax
Motivation:

We often used synchronized(this) while the whole method was synchronized, which can be simplified by just mark the whole method as synchronized.

Modifications:

Replace synchronized(this) with synchronized on the method

Result:

Cleaner code
2016-01-05 09:02:58 +01:00
Sergey Polovko
ec8c56915b fix links to github issues in javadoc 2016-01-04 08:47:33 +01:00
Norman Maurer
15162202fb [#4435] Always invoke the actual deregisteration later in the EventLoop.
Motivation:

As a user may call deregister() from within any method while doing processing in the ChannelPipeline,  we need to ensure we do the actual deregister operation later. This is needed as for example,  we may be in the ByteToMessageDecoder.callDecode(...) method and so still try to do processing in the old EventLoop while the user already registered the Channel to a new EventLoop. Without delay, the deregister operation this could lead to have a handler invoked by different EventLoop and so threads.

Modifications:

Ensure the actual deregister will be done later on and not directly when invoked.

Result:

Calling deregister() within ByteToMessageDecoder.decode(..) is safe.
2015-12-24 14:19:47 +01:00
Alexey Ermakov
d2ddb528e4 Customizable estimation for messages written outside the EventLoop
Motivation:

Estimation algorithm currently used for WriteTasks is complicated and
wrong. Additionally, some code relies on outbound buffer size
incremented only on actual writes to the outbound buffer.

Modifications:

- Throw away the old estimator and replace with a simple algorithm that
  uses the client-provided estimator along with a statically configured
  WriteTask overhead (io.netty.transport.writeTaskSizeOverhead system
  property with the default value of 48 bytes)
- Add a io.netty.transport.estimateSizeOnSubmit boolean system property
  allowing the clients to disable the message estimation outside the
  event loop

Result:

Task estimation is user controllable and produces better results by
default
2015-12-24 00:04:37 +01:00
Jonas Berlin
eac2cc8ec7 Fix javadoc link 2015-12-22 20:53:21 +01:00
Sky Ao
38df32e2a8 Trivial javadoc fixes in ChannelHandlerContext 2015-12-18 14:03:16 +01:00
Norman Maurer
26088b778f [#4449] Remove registered events from eventloop before close
Motivation:

We need to remove all registered events for a Channel from the EventLoop before doing the actual close to ensure we not produce a cpu spin when the actual close operation is delayed or executed outside of the EventLoop.

Modifications:

Deregister for events for NIO and EPOLL socket implementations when SO_LINGER is used.

Result:

No more cpu spin.
2015-12-13 09:55:34 +01:00
Norman Maurer
61b5792340 Fix race-condition when closing a NioSocketChannel or EpollSocketChannel
Motivation:

Fix a race-condition when closing NioSocketChannel or EpollSocketChannel while try to detect if a close executor should be used and the underlying socket was already closed. This could lead to an exception that then leave the channel / in an invalid state and so could lead to side-effects like heavy CPU usage.

Modifications:

Catch possible socket exception while try to get the SO_LINGER options from the underlying socket.

Result:

No more race-condition when closing the channel is possible with bad side-effects.
2015-11-26 22:55:45 +01:00
Scott Mitchell
47d35f89cb Cleanup ChannelOption.AUTO_CLOSE javadocs
Motivation:
The javadocs for ChannelOption.AUTO_CLOSE say the default is false, but the default is currently true.

Modifications:
- Make javadocs consistent with code

Result:
Less confusing docs.
2015-11-24 15:24:47 -08:00
Norman Maurer
450939842e Fix version 2015-11-24 21:24:22 +01:00
Norman Maurer
7c5a1178b5 Mark ChannelHandler.exceptionCaught(...) as deprected.
Motivation:

exceptionCaught(...) will only handle inbound exceptions which means it makes not much sense to have it also on ChannelOutboundHandler. Because of this we should move it to ChannelInboundHandler.

Modifications:

Add @deprecated annotation to ChannelHandler.exceptionCaught(...).

Result:

Preapre to cleanup the API in later release.
2015-11-23 10:00:43 +01:00
Norman Maurer
c08c965117 Use OneTimeTask where possible to reduce object creation
Motivation:

We should use OneTimeTask where possible to reduce object creation.

Modifications:

Replace Runnable with OneTimeTask

Result:

Less object creation
2015-11-20 14:28:28 -08:00
Norman Maurer
01da38d21a Reduce memory footprint of DefaultChannelPipeline
Motivation:

If you need to handle a lot of concurrent connections (1M+) the memory footprint can be problem.

Modifications:

- Lazy create the IdentityHashMap that holds the EventExecutor mappings as this is not needed by most users anyway
- Use a sane initial capacity when creating the IdentityHashMap

Result:

Smaller memory footprint of DefaultChannelPipeline
2015-11-20 06:53:51 -08:00
Norman Maurer
19950f89e4 Remove unnecessary reference to AbstractChannel from AbstractChannelHandlerContext
Motivation:

We not need to store another reference to AbstractChannel as we can access it through DefaultChannelHandlerContext.

Modifications:

Remove reference.

Result:

Cleaner code.
2015-11-20 06:35:31 -08:00
Norman Maurer
d6c23d0af9 Remove HashMap for lookup name / ctx from DefaultChannelPipeline to reduce memory footprint
Motivation:

If you start to have 1M+ concurrent connections memory footprint can be come a big issue. We should try to reduce it as much as possible in the core of netty.

Modifications:

- Remove HashMap that was used to store name to ctx mapping. This was only used for validation and access a handler by name. As a pipeline is not expected to be very long (like 100+ handlers) we can just walk the linked list structure to find the ctx with a given name.

Result:

Less memory footprint of the DefaultChannelPipeline.
2015-11-20 06:10:39 -08:00
pieteradejong
f571f7279b fixed word - issue #4469 2015-11-19 07:32:47 -08:00
Sergio Bossa
60a240316a Improved DefaultChannelPipeline#destroy() to avoid spinning continuously in case of custom executors.
Motivation:

The previous DefaultChannelPipeline#destroy() implementation, introduced in #3156, is suboptimal as it can cause the for loop to continuously spin if the executor used by a given handler is unable to "recognize" the event loop.
It could be objected that it's the custom executor responsibility to properly implement the inEventLoop() method, but some implementetaions might not be able to do that for performance reasons, and even so, it's always better to be safe against API misuse, in particular when it is not possible to fail fast and the alternative is rather some sutle behaviour.

Modifications:

The patch simply avoids the recursive spin by explicitly passing the "in event loop" condition as a boolean parameter, preserving the same guarantees offered by #3156. A unit test has also been added.

Result:

All channel events are correctly called and no high CPU usage is seen anymore.
2015-11-06 19:37:41 +01:00
Norman Maurer
8ecfd58714 Remove synchronization overhead on generateName.
Motivation:

Changing the chache of generated names to use a cache per thread. This will remove the bottleneck when many eventloops are used and names need to generate.

Modifications:

Use a FastThreadLocal to store the cached names.

Result:

Less locking between threads.
2015-11-04 20:41:06 +01:00
Norman Maurer
69b5aefd09 [maven-release-plugin] prepare release netty-4.0.33.Final 2015-11-03 14:18:17 +01:00
Norman Maurer
c42d710c6e [#4363] Improve size calculation of messages when written from outside the EventLoop
Motiviation:

If a user writes from outside the EventLoop we increase the pending bytes of the outbound buffer before submitting the write request. This is done so the user can stop writing asap once the channel turns unwritable. Unfortunally this doesn't take the overhead of adding the task into the account and so it is very easy for an user to full up the task queue. Beside this we use a value of 0 for an unown message by default which is not ideal.

Modifications:

- port the message calculation we used in netty 3.x into AbstractChannelHandlerContext and so better calculate the overhead of a message that is submitted from outside the EventLoop
- change the default estimated size for an unknown message to 8.

Result:

Better behaviour when submiting writes from outside the EventLoop.
2015-10-28 21:34:26 +01:00
Norman Maurer
082e9cc722 [#4373] Fix assert error when trying to release Channel to closed FixedChannelPool
Motivation:

Once a FixedChannelPool was closed we must not allow to acquire or release Channels to prevent assert errors.

Modifications:

Fail release and acquire calls when FixedChannelPool is closed.

Result:

No more assert errors.1
2015-10-24 11:56:36 +02:00
Sky Ao
b79714ab5a change type definition of pipeline from DefaultChannelPipeline to ChannelPipeline 2015-10-10 20:16:07 +02:00
Norman Maurer
bd61b96efa Cleanup PendingWriteQueueTest
Motivation:

PendingWriteQueueTest needs some cleanup.

Modifications:

- Cleanup code to remove deprecation warnings
- use static imports

Result:

No more warnings
2015-10-10 20:01:48 +02:00
Norman Maurer
845a1a526a [#4316] Ensure pending tasks are run when EmbeddedChannel.close(...) or disconnect(...) is called.
Motivation:

We missed to run all pending tasks when EmbeddedChannel.close(...) or disconnect(...) was called. Because of this channelInactive(...) / channelUnregistered(...) of the handlers were never called.

Modifications:

Correctly run all pending tasks and cancel all not ready scheduled tasks when close or disconnect was called.

Result:

Correctly run tasks on close / disconnect and have channelInactive(...) / channelUnregistered(...) called.
2015-10-07 09:32:14 +02:00
Norman Maurer
696a287736 [maven-release-plugin] prepare for next development iteration 2015-09-30 09:31:26 +02:00
Norman Maurer
fb2d562306 [maven-release-plugin] prepare release netty-4.0.32.Final 2015-09-30 09:28:40 +02:00