Commit Graph

776 Commits

Author SHA1 Message Date
Norman Maurer
8bc21ecdd0 [#3376] Use IllegalArgumentException as replacement for NPE as stated in javadocs
Motivation:

SSLEngine specifies that IllegalArgumentException must be thrown if a null argument is given when using wrap(...) or unwrap(...).

Modifications:

Replace NullPointerException with IllegalArgumentException to match the javadocs.

Result:

Match the javadocs.
2015-01-30 05:56:20 +01:00
Norman Maurer
4619e88a7b [#3375] Correctly calculate the endOffset when wrap multiple ByteBuffer
Motivation:

We failed to correctly calculate the endOffset when wrap multiple ByteBuffer and so not wrapped everything when an offset > 0 is used.

Modifications:

Correctly calculate endOffset.

Result:

All ByteBuffers are correctly wrapped when offset > 0.
2015-01-30 05:37:17 +01:00
Trustin Lee
392fb764b6 Fix IndexOutOfBoundsException from SslHandler on JDK 8
Motivation:

When SslHandler.unwrap() copies SSL records into a heap buffer, it does
not update the start offset, causing IndexOutOfBoundsException.

Modifications:

- Copy to a heap buffer before calling unwrap() for simplicity
- Do not copy an empty buffer to a heap buffer.
  - unwrap(... EMPTY_BUFFER ...) never involves copying now.
- Use better parameter names for unwrap()
- Clean-up log messages

Result:

- Bugs fixed
- Cleaner code
2015-01-13 18:14:37 +09:00
Norman Maurer
1bb818bb59 Reduce memory copies when using OpenSslEngine with SslHandler
Motivation:

When using OpenSslEngine with the SslHandler it is possible to reduce memory copies by unwrap(...) multiple ByteBuffers at the same time. This way we can eliminate a memory copy that is needed otherwise to cumulate partial received data.

Modifications:

- Add OpenSslEngine.unwrap(ByteBuffer[],...) method that can be used to unwrap multiple src ByteBuffer a the same time
- Use a CompositeByteBuffer in SslHandler for inbound data so we not need to memory copy
- Add OpenSslEngine.unwrap(ByteBuffer[],...) in SslHandler if OpenSslEngine is used and the inbound ByteBuf is backed by more then one ByteBuffer
- Reduce object allocation

Result:

SslHandler is faster when using OpenSslEngine and produce less GC
2015-01-12 20:19:42 +01:00
Trustin Lee
cb7ab1f6a4 Fix a compilation error 2015-01-09 16:00:26 +09:00
Norman Maurer
50af9b916c Eliminate memory copy in ByteToMessageDecoder whenever possible
Motivation:

Currently when there are bytes left in the cumulation buffer we do a byte copy to produce the input buffer for the decode method. This can put quite some overhead on the impl.

Modification:

- Use a CompositeByteBuf to eliminate the byte copy.
- Allow to specify if a CompositeBytebug should be used or not as some handlers can only act on one ByteBuffer in an efficient way (like SslHandler :( ).

Result:

Performance improvement as shown in the following benchmark.

Without this patch:
[xxx@xxx ~]$ ./wrk-benchmark
Running 5m test @ http://xxx:8080/plaintext
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    20.19ms   38.34ms   1.02s    98.70%
    Req/Sec   241.10k    26.50k  303.45k    93.46%
  1153994119 requests in 5.00m, 155.84GB read
Requests/sec: 3846702.44
Transfer/sec:    531.93MB

With the patch:
[xxx@xxx ~]$ ./wrk-benchmark
Running 5m test @ http://xxx:8080/plaintext
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    17.34ms   27.14ms 877.62ms   98.26%
    Req/Sec   252.55k    23.77k  329.50k    87.71%
  1209772221 requests in 5.00m, 163.37GB read
Requests/sec: 4032584.22
Transfer/sec:    557.64MB
2015-01-09 15:56:30 +09:00
Trustin Lee
98731a51c8 Add the URL of the wiki for easier troubleshooting
Motivation:

When a user sees an error message, sometimes he or she does not know
what exactly he or she has to do to fix the problem.

Modifications:

Log the URL of the wiki pages that might help the user troubleshoot.

Result:

We are more friendly.
2015-01-08 12:45:34 +09:00
Trustin Lee
2c3f4a374a Do not log CNFE when tcnative is not in classpath
Motivation:

When a user deliberatively omitted netty-tcnative from classpath, he or
she will see an ugly stack trace of ClassNotFoundException.

Modifications:

Log more briefly when netty-tcnative is not in classpath.

Result:

Better-looking log at DEBUG level
2015-01-08 12:27:04 +09:00
Trustin Lee
df186f38a0 Do not pre-populate cipher suite conversion table
Motivation:

- There's no point of pre-population.
- Waste of memory and time because they are going to be cached lazily
- Some pre-populated cipher suites are ancient and will be unused

Modification:

- Remove cache pre-population

Result:

Sanity restored
2014-12-31 20:33:53 +09:00
Norman Maurer
405cdc89dd Only call JNI methods if really needed
Motivation:

Calling JNI methods is pretty expensive, so we should only do if needed.

Modifications:

Lazy call methods if needed.

Result:

Better performance.
2014-12-30 19:45:23 +09:00
Trustin Lee
ea5f38955a Raise an exception when the specified cipher suite is not available
Motivation:

SSL_set_cipher_list() in OpenSSL does not fail as long as at least one
cipher suite is available.  It is different from the semantics of
SSLEngine.setEnabledCipherSuites(), which raises an exception when the
list contains an unavailable cipher suite.

Modifications:

- Add OpenSsl.isCipherSuiteAvailable(String) which checks the
  availability of a cipher suite
- Raise an IllegalArgumentException when the specified cipher suite is
  not available

Result:

Fixed compatibility
2014-12-30 19:26:06 +09:00
Trustin Lee
7d50f7864c Implement OpenSslEngine.getSupportedCipherSuites() and get/setEnabledCipherSuites()
Motivation:

To make OpenSslEngine a full drop-in replacement, we need to implement
getSupportedCipherSuites() and get/setEnabledCipherSuites().

Modifications:

- Retrieve the list of the available cipher suites when initializing
  OpenSsl.
- Improve CipherSuiteConverter to understand SRP
- Add more test data to CipherSuiteConverterTest
- Add bulk-conversion method to CipherSuiteConverter

Result:

OpenSslEngine should now be a drop-in replacement for JDK SSLEngineImpl
for most cases.
2014-12-30 19:26:05 +09:00
Trustin Lee
a093f00b67 Cipher suite conversion between Java and OpenSSL
Related: #3285

Motivation:

When a user attempts to switch from JdkSslContext to OpenSslContext, he
or she will see the initialization failure if he or she specified custom
cipher suites.

Modifications:

- Provide a utility class that converts between Java cipher suite string
  and OpenSSL cipher suite string
- Attempt to convert the cipher suite so that a user can use the cipher
  suite string format of Java regardless of the chosen SslContext impl

Result:

- It is possible to convert all known cipher suite strings.
- It is possible to switch from JdkSslContext and OpenSslContext and
  vice versa without any configuration changes
2014-12-30 17:27:25 +09:00
Trustin Lee
a77070fe9f Clean-up 2014-12-29 15:55:57 +09:00
Frederic Bregier
2681112080 Fix big transfer and Write traffic shaping issues
Motivation:

Several issues were shown by various ticket (#2900 #2956).
Also use the improvement on writability user management from #3036.
And finally add a mixte handler, both for Global and Channels, with
the advantages of being uniquely created and using less memory and
less shaping.

Issue #2900

When a huge amount of data are written, the current behavior of the
TrafficShaping handler is to limit the delay to 15s, whatever the delay
the previous write has. This is wrong, and when a huge amount of writes
are done in a short time, the traffic is not correctly shapened.

Moreover, there is a high risk of OOM if one is not using in his/her own
handler for instance ChannelFuture.addListener() to handle the write
bufferisation in the TrafficShapingHandler.

This fix use the "user-defined writability flags" from #3036 to
allow the TrafficShapingHandlers to "user-defined" managed writability
directly, as for reading, thus using the default isWritable() and
channelWritabilityChanged().
This allows for instance HttpChunkedInput to be fully compatible.

The "bandwidth" compute on write is only on "acquired" write orders, not
on "real" write orders, which is wrong from statistic point of view.

Issue #2956

When using GlobalTrafficShaping, every write (and read) are
synchronized, thus leading to a drop of performance.
ChannelTrafficShaping is not touched by this issue since synchronized is
then correct (handler is per channel, so the synchronized).

Modifications:
The current write delay computation takes into account the previous
write delay and time to check is the 15s delay (maxTime) is really
exceeded or not (using last scheduled write time). The algorithm is
simplified and in the same time more accurate.

This proposal uses the #3036 improvement on user-defined writability
flags.

When the real write occurs, the statistics are update accordingly on a
new attribute (getRealWriteThroughput()).

To limit the synchronisations, all synchronized on
GlobalTrafficShapingHandler on submitWrite were removed. They are
replaced with a lock per channel (since synchronization is still needed
to prevent unordered write per channel), as in the sendAllValid method
for the very same reason.
Also all synchronized on TrafficCounter on read/writeTimeToWait() are
removed as they are unnecessary since already locked before by the
caller.
Still the creation and remove operations on lock per channel (PerChannel
object) are synchronized to prevent concurrency issue on this critical
part, but then limited.

Additionnal changes:
1) Use System.nanoTime() instead of System.currentTimeMillis() and
minimize calls
2) Remove / 10 ° 10 since no more sleep usage
3) Use nanoTime instead of currentTime such that time spend is computed,
not real time clock. Therefore the "now" relative time (nanoTime based)
is passed on all sub methods.
4) Take care of removal of the handler to force write all pending writes
and release read too
8) Review Javadoc to explicit:

- recommandations to take into account isWritable

- recommandations to provide reasonable message size according to
traffic shaping limit

- explicit "best effort" traffic shaping behavior when changing
configuration dynamically

Add a MixteGlobalChannelTrafficShapingHandler which allows to use only one
handler for mixing Global and Channel TSH. I enables to save more memory and
tries to optimize the traffic among various channels.

Result:
The traffic shaping is more stable, even with a huge number of writes in
short time by taking into consideration last scheduled write time.

The current implementation of TrafficShapingHandler using user-defined
writability flags and default isWritable() and
fireChannelWritabilityChanged works as expected.

The statistics are more valuable (asked write vs real write).

The Global TrafficShapingHandler should now have less "global"
synchronization, hoping to the minimum, but still per Channel as needed.

The GlobalChannel TrafficShapingHandler allows to have only one handler for all channels while still offering per channel in addition to global traffic shaping.

And finally maintain backward compatibility.
2014-12-29 15:47:06 +09:00
Norman Maurer
b8dd95b8ad Allow to set the context for which sessions can be used.
Motivation:

Openssl supports the SSL_CTX_set_session_id_context function to limit for which context a session can be used. We should support this.

Modifications:

Add OpenSslServerSessionContext that exposes a setSessionIdContext(...) method now.

Result:

It's now possible to use SSL_CTX_set_session_id_context.
2014-12-26 15:03:35 +01:00
Norman Maurer
8e6739ddc0 Explicit allow to enable / disable session cache
Motivation:

It is sometimes useful to enable / disable the session cache.

Modifications:

* Add OpenSslSessionContext.setSessionCacheEnabled(...) and isSessionCacheEnabled()

Result:

It is now possible to enable / disable cache on the fly
2014-12-26 14:57:10 +01:00
Norman Maurer
8a1c7f2ca6 Allow to enable/disable protocols on the OpenSslEngine
Motivation:

To be compatible with SSLEngine we need to support enable / disable procols on the OpenSslEngine

Modifications:

Implement OpenSslEngine.getSupportedProtocols() , getEnabledProtocols() and setEnabledProtocols(...)

Result:

Better compability with SSLEngine
2014-12-26 09:34:21 +01:00
Norman Maurer
7423db0b8e Add proper Openssl.SSLSession.getId() implementation
Motivation:

The current implementation not returns the real session as byte[] representation.

Modifications:

Create a proper Openssl.SSLSession.get() implementation which returns the real session as byte[].

Result:

More correct implementation
2014-12-26 09:30:32 +01:00
Norman Maurer
fb3b16d9d4 Allow to enable session cache when using OpenSsl
Motivation:

At the moment it is not possible to make use of the session cache when OpenSsl is used. This should be possible when server mode is used.

Modifications:

- Add OpenSslSessionContext (implements SSLSessionContext) which exposes all the methods to modify the session cache.
- Add various extra methods to OpenSslSessionContext for extra functionality
- Return OpenSslSessionContext when OpenSslEngine.getSession().getContext() is called.
- Add sessionContext() to SslContext
- Move OpenSsl specific session operations to OpenSslSessionContext and mark the old methods @deprecated

Result:

It's now possible to use session cache with OpenSsl
2014-12-26 09:22:38 +01:00
Trustin Lee
cf6eb70f93 Fix NoClassDefFoundError when netty-tcnative is unavailable
Motivation:

ProxyHandlerTest fails with NoClassDefFoundError raised by
SslContext.newClientContext().

Modifications:

Fix a missing 'return' statement that makes the switch-case block fall
through unncecessarily

Result:

- ProxyHandlerTest does not fail anymore.
- SslContext.newClientContext() does not raise NoClassDefFoundError
  anymore.
2014-12-26 15:44:39 +09:00
Norman Maurer
5c57b5de5b Check for errors without object allocation
Motivation:

At the moment we use SSL.getLastError() in unwrap(...) to check for error. This is very inefficient as it creates a new String for each check and we also use a String.startsWith(...) to detect if there was an error we need to handle.

Modifications:

Use SSL.getLastErrorNumber() to detect if we need to handle an error, as this only returns a long and so no String creation happens. Also the detection is much cheaper as we can now only compare longs. Once an error is detected the lately SSL.getErrorString(long) is used to conver the error number to a String and include it in log and exception message.

Result:

Performance improvements in OpenSslEngine.unwrap(...) due less object allocation and also faster comparations.
2014-12-22 21:09:49 +01:00
Norman Maurer
1729859c68 Use OpenSslClientContext as default if openssl is avaible
Motivation:

As we now support OpenSslEngine for client side, we should use it when avaible.

Modifications:

Use SslProvider.OPENSSL when openssl can be found

Result:

OpenSslEngine is used whenever possible
2014-12-22 21:08:04 +01:00
Norman Maurer
15ca81a565 Allow to use custom TrustManagerFactory for JdkSslServerContent and OpenSslServerContext
Motivation:

When using client auth it is sometimes needed to use a custom TrustManagerFactory.

Modifications:

Allow to pass in TrustManagerFactory

Result:

It's now possible to use custom TrustManagerFactories for JdkSslServerContext and OpenSslServerContext
2014-12-22 20:56:49 +01:00
Norman Maurer
393e3ea383 Use TrustManager for certificate verification
Motivation:

To make OpenSsl*Context a drop in replacement for JdkSsl*Context we need to use TrustManager.

Modifications:

Correctly hook in the TrustManager

Result:

Better compatibility
2014-12-22 20:26:53 +01:00
Norman Maurer
473c23aec9 Allow to enable client authentication on the OpenSslEngine
Motivation:

At the moment there is no way to enable client authentication when using OpenSslEngine. This limits the uses of OpenSslEngine.

Modifications:

Add support for different authentication modes.

Result:

OpenSslEngine can now also be used when client authenticiation is needed.
2014-12-22 20:18:51 +01:00
Norman Maurer
87eca066da More complete OpenSslEngine SSLSession implementation
Motivation:

The current SSLSession implementation used by OpenSslEngine does not support various operations and so may not be a good replacement by the SSLEngine provided by the JDK implementation.

Modifications:

- Add SSLSession.getCreationTime()
- Add SSLSession.getLastAccessedTime()
- Add SSLSession.putValue(...), getValue(...), removeValue(...), getValueNames()
- Add correct SSLSession.getProtocol()
- Ensure OpenSSLEngine.getSession() is thread-safe
- Use optimized AtomicIntegerFieldUpdater when possible

Result:

More complete OpenSslEngine SSLSession implementation
2014-12-22 20:12:51 +01:00
Norman Maurer
682df517c9 Add OpenSslClientContext to allow creating SslEngine for client side
Motivation:

We only support openssl for server side at the moment but it would be also useful for client side.

Modification:

* Upgrade to new netty-tcnative snapshot to support client side openssl support
* Add OpenSslClientContext which can be used to create SslEngine for client side usage
* Factor out common logic between OpenSslClientContext and OpenSslServerContent into new abstract base class called OpenSslContext
* Correctly detect handshake failures as soon as possible
* Guard against segfault caused by multiple calls to destroyPools(). This can happen if OpenSslContext throws an exception in the constructor and the finalize() method is called later during GC

Result:

openssl can be used for client and servers now.
2014-12-22 19:38:30 +01:00
Norman Maurer
b7e82b2ccb Efficiently handle writing ( wrap(...) ) of CompositeByteBuf when using SslHandler
Motivation:

SslHandler.wrap(...) does a poor job when handling CompositeByteBuf as it always call ByteBuf.nioBuffer() which will do a memory copy when a CompositeByteBuf is used that is backed by multiple ByteBuf.

Modifications:

- Use SslEngine.wrap(ByteBuffer[]...) to allow wrap CompositeByteBuf in an efficient manner
- Reduce object allocation in unwrapNonAppData(...)

Result:

Performance improvement when a CompositeByteBuf is written and the SslHandler is in the ChannelPipeline.
2014-12-22 12:15:07 +01:00
Norman Maurer
699e6e3b02 Fix memory leak in OpenSslEngine
Motivation:

When a remote peer did open a connection and only do the handshake without sending any data and then directly close the connection we did not call shutdown() in the OpenSslEngine. This leads to a native memory leak. Beside this it also was not fireed when a OpenSslEngine was created but never used.

Modifications:

- Make sure shutdown() is called in all cases when closeInbound() is called
- Call shutdown() also in the finalize() method to ensure we release native memory when the OpenSslEngine is GC'ed

Result:

No more memory leak when using OpenSslEngine
2014-12-21 09:27:49 +01:00
Trustin Lee
e72b2235fb Make sure to notify handshake success even if SSLEngine is closed
Related:

e9685ea45a

Motivation:

SslHandler.unwrap() does not evaluate the handshake status of
SSLEngine.unwrap() when the status of SSLEngine.unwrap() is CLOSED.

It is not correct because the status does not reflect the state of the
handshake currently in progress, accoding to the API documentation of
SSLEngineResult.Status.

Also, sslCloseFuture can be notified earlier than handshake notification
because we call sslCloseFuture.trySuccess() before evaluating handshake
status.

Modifications:

- Notify sslCloseFuture after the unwrap loop is finished
- Add more assertions to SocketSslEchoTest

Result:

Potentially fix the regression caused by:
- e9685ea45a
2014-12-12 11:55:27 +09:00
Trustin Lee
d5a24d4f6c Make SslHandler work when autoRead is turned off
Related: #2958

Motivation:

SslHandler currently does not issue a read() request when it is
handshaking. It makes a connection with autoRead off stall, because a
user's read() request can be used to read the handshake response which
is invisible to the user.

Modifications:

- SslHandler now issues a read() request when:
  - the current handshake is in progress and channelReadComplete() is
    invoked
  - the current handshake is complete and a user issued a read() request
    during handshake
- Rename flushedBeforeHandshakeDone to flushedBeforeHandshake for
  consistency with the new variable 'readDuringHandshake'

Result:

SslHandler should work regardless whether autoRead is on or off.
2014-12-11 17:57:28 +09:00
Trustin Lee
1dc1831abf Add SslHandler.renegotiate()
Related: #3125

Motivation:

We did not expose a way to initiate TLS renegotiation and to get
notified when the renegotiation is done.

Modifications:

- Add SslHandler.renegotiate() so that a user can initiate TLS
  renegotiation and get the future that's notified on completion
- Make SslHandler.handshakeFuture() return the future for the most
  recent handshake so that a user can get the future of the last
  renegotiation
- Add the test for renegotiation to SocketSslEchoTest

Result:

Both client-initiated and server-initiated renegotiations are now
supported properly.
2014-12-10 18:59:50 +09:00
Trustin Lee
9ff234abed Call ctx.flush() at least once in ChunkedWriteHandler.flush()
Related: #3219

Motivation:

ChunkedWriteHandler.flush() does not call ctx.flush() when channel is
not writable. This can be a problem when other handler / non-Netty
thread writes messages simultaneously, because
ChunkedWriteHandler.flush() might have no chance to observe
channel.isWritable() returns true and thus the channel is never flushed.

Modifications:

- Ensure that ChunkedWriteHandler.flush() calls ctx.flush() at least
  once.

Result:

A stall connection issue, that occurs when certain combination of
handlers exist in a pipeline, has been fixed. (e.g. SslHandler and
ChunkedWriteHandler)
2014-12-09 18:17:46 +09:00
Trustin Lee
bf58f871c3 Overall clean-up of the initial SniHandler/DomainNameMapping work
- Parameterize DomainNameMapping to make it useful for other use cases
  than just mapping to SslContext
- Move DomainNameMapping to io.netty.util
- Clean-up the API documentation
- Make SniHandler.hostname and sslContext volatile because they can be
  accessed by non-I/O threads
2014-12-04 18:23:07 +09:00
Trustin Lee
96d596802b Fix dependency issues with hamcrest
Motivation:

We use 3 (!) libraries to build mock objects - easymock, mockito, jmock.
Mockito and jMock pulls in the different versions of Hamcrest, and it
conflicts with the version pulled by jUnit.

Modifications:

- Replace mockito-all with mockito-core to avoid pulling in outdated
  jUnit and Hamcrest
- Exclude junit-dep when pulling in jmock-junit4, because it pulls an
  outdated Hamcrest version
- Pull in the hamcrest-library version used by jUnit explicitly

Result:

No more dependency hell that results in NoSuchMethodError during the
tests
2014-12-04 17:59:15 +09:00
Sun Ning
8f77c80795 Added support for SSL Server Name Indication.
Motivation:

When we need to host multiple server name with a single IP, it requires
the server to support Server Name Indication extension to serve clients
with proper certificate. So the SniHandler will host multiple
SslContext(s) and append SslHandler for requested hostname.

Modification:

* Added SniHandler to host multiple certifications in a single server
* Test case

Result:

User could use SniHandler to host multiple certifcates at a time.
It's server-side only.
2014-12-03 11:03:15 +01:00
Ronald Chen
e1273147fa replaced broken &lt with < and same for gt 2014-11-29 19:33:50 +01:00
Graham Edgecombe
d33a80da26 Use Triple DES in JdkSslContext cipher suite list.
Motivation:

JdkSslContext used SSL_RSA_WITH_DES_CBC_SHA in its cipher suite list.
OpenSslServerContext used DES-CBC3-SHA in the same place in its cipher suite
list, which is equivalent to SSL_RSA_WITH_3DES_EDE_CBC_SHA.

This means the lists were out of sync. Furthermore, using
SSL_RSA_WITH_DES_CBC_SHA is not desirable as it uses DES, a weak cipher. Triple
DES should be used instead.

Modifications:

Replace SSL_RSA_WITH_DES_CBC_SHA with SSL_RSA_WITH_3DES_EDE_CBC_SHA in
JdkSslContext.

Result:

The JdkSslContext and OpenSslServerContext cipher suite lists are now in sync.
Triple DES is used instead of DES, which is stronger.
2014-11-27 08:15:34 +01:00
Trustin Lee
88aa9e7c4a Remove or de-prioritize RC4 from default cipher suites
Motivation:

RC4 is not a recommended cipher suite anymore, as the recent research
reveals, such as:

- http://www.isg.rhul.ac.uk/tls/

Modifications:

- Remove most RC4 cipher suites from the default cipher suites
- For backward compatibility, leave RC4-SHA, while de-prioritizing it

Result:

Potentially safer default
2014-11-25 17:17:20 +09:00
Idel Pivnitskiy
35db3c6710 Small performance improvements
Motivation:

Found performance issues via FindBugs and PMD.

Modifications:

- Removed unnecessary boxing/unboxing operations in DefaultTextHeaders.convertToInt(CharSequence) and DefaultTextHeaders.convertToLong(CharSequence). A boxed primitive is created from a string, just to extract the unboxed primitive value.
- Added a static modifier for DefaultHttp2Connection.ParentChangedEvent class. This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.
- Added a static compiled Pattern to avoid compile it each time it is used when we need to replace some part of authority.
- Improved using of StringBuilders.

Result:

Performance improvements.
2014-11-20 00:10:06 -05:00
Trustin Lee
f2678a31ff Add ApplicationProtocolConfig.DISABLED
Motivation:

When ALPN/NPN is disabled, a user has to instantiate a new
ApplicationProtocolConfig with meaningless parameters.

Modifications:

- Add ApplicationProtocolConfig.DISABLED, the singleton instance
- Reject the constructor calls with Protocol.NONE, which doesn't make
  much sense because a user should use DISABLED instead.

Result:

More user-friendly API when ALPN/NPN is not needed by a user.
2014-10-31 14:09:46 +09:00
Trustin Lee
06217aefb7 Add back the removed deprecated methods in SslContext
Motivation:

Previous backport removed the old methods and constructors. They should
not be removed in 4.x but just deprecated in favor of the new methods
and constructors.

Modifications:

Add back the removed methods and constructors in SslContext and its
subtypes for backward compatibility.

Result:

Backward compatibility issues fixed.
2014-10-31 13:53:31 +09:00
Trustin Lee
16fb44cf97 Code clean-up
- Fix the inspector warnings
- Fix the infinite recursion in SslContext.newClientContext()
- Fix Javadoc errors
2014-10-31 13:00:05 +09:00
Scott Mitchell
04f77b76f8 Backport ALPN and Mutual Auth SSL
Motivation:

Improvements were made on the main line to support ALPN and mutual
authentication for TLS. These should be backported.

Modifications:

- Backport commits from the master branch
  - f8af84d599
  - e74c8edba3

Result:

Support for ALPN and mutual authentication.
2014-10-31 12:52:26 +09:00
Scott Mitchell
746c8cab32 SslHander wrap conditional direct buffer allocation
Motivation:
The SslHandler currently forces the use of a direct buffer for the input to the SSLEngine.wrap(..) operation. This allocation may not always be desired and should be conditionally done.

Modifications:
- Use the pre-existing wantsDirectBuffer variable as the condition to do the conversion.

Result:
- An allocation of a direct byte buffer and a copy of data is now not required for every SslHandler wrap operation.
2014-10-30 10:10:30 +01:00
Scott Mitchell
06ea226a28 SslHandler wrap memory leak
Motivation:
The SslHandler wrap method requires that a direct buffer be passed to the SSLEngine.wrap() call. If the ByteBuf parameter does not have an underlying direct buffer then one is allocated in this method, but it is not released.

Modifications:
- Release the direct ByteBuffer only accessible in the scope of SslHandler.wrap

Result:
Memory leak in SslHandler.wrap is fixed.
2014-10-28 06:12:45 +01:00
Trustin Lee
a1af35313c Disable SSLv3 to avoid POODLE vulnerability
Related: #3031

Motivation:

The only way to protect ourselves from POODLE vulnerability in Java for
now is to disable SSLv3.

- http://en.wikipedia.org/wiki/POODLE
- https://blogs.oracle.com/security/entry/information_about_ssl_poodle_vulnerability

Modifivation:

Disable SSLv3 in SslContext implementations

Result:

Prevent POODLE vulnerability when a user used SslContext with the
default configuration
2014-10-21 14:00:43 +09:00
kerr
b828e823ef Change the operator order of TrafficCounter to calculate the throughput to get the correct result
Motivation:
Currently the last read/write throughput is calculated by first division,this will be 0 if the last read/write bytes < interval,change the order will get the correct result

Modifications:
Change the operator order from first do division to multiplication

Result:
Get the correct result instead of 0 when bytes are smaller than interval
2014-10-01 06:37:36 +02:00
Frederic Bregier
a25c585f39 Fix overriden method not called in TrafficShaping
Motivation:
handlerAdded and handlerRemoved were overriden but super was never
called, while it should.
Also add one missing information in the toString method.

Modifications:
Add the super corresponding call, and add checkInterval to the
toString() method

Result;
super method calls are correctly passed to the super implementation
part.
2014-09-20 20:42:49 +02:00
Wolfgang Profer
57f48e0ec8 Fixed FingerprintTrustManagerFactory constructor
Motivation:

When constructing a FingerprintTrustManagerFactory from an Iterable of Strings, the fingerprints were correctly parsed but never added to the result array. The constructed FingerprintTrustManagerFactory consequently fails to validate any certificate.

Modifications:

I added a line to add each converted SHA-1 certificate fingerprint to the result array which then gets passed on to the next constructor.

Result:

Certificate fingerprints passed to the constructor are now correctly added to the array of valid fingerprints. The resulting FingerprintTrustManagerFactory object correctly validates certificates against the list of specified fingerprints.
2014-09-19 19:48:58 +02:00
Brad Fritz
f7616d22eb Correct javadoc typo in IdleStateHandler example code 2014-09-10 20:55:39 +02:00
Jakob Buchgraber
b285994e10 Support IPv4 default route in ipfilter.
Motivation:

In GitHub issue #2767 a bug was reported that the IPv4
default route leads to the ipfilter package denying
instead of accepting all addresses.

While the issue was reported for Netty 3.9, this bug
also applies to Netty 4 and higher.

Modifications:

When computing the subnet address from the CIDR prefix,
correctly handle the case where the prefix is set to zero.

Result:

Ipfilter accepts all addresses when passed the
IPv4 default route.
2014-08-17 14:32:27 +02:00
Trustin Lee
b5f61d0de5 [maven-release-plugin] prepare for next development iteration 2014-08-16 03:27:42 +09:00
Trustin Lee
76ac3b21a5 [maven-release-plugin] prepare release netty-4.1.0.Beta3 2014-08-16 03:27:37 +09:00
Trustin Lee
b3c1904cc9 [maven-release-plugin] prepare for next development iteration 2014-08-15 09:31:03 +09:00
Trustin Lee
e013b2400f [maven-release-plugin] prepare release netty-4.1.0.Beta2 2014-08-15 09:30:59 +09:00
plucury
ca29be5e77 Allow ChunkedInput to provide the progress of its transfer
Related issue: #2741 and #2151

Motivation:

There is no way for ChunkedWriteHandler to know the progress of the
transfer of a ChannelInput. Therefore, ChannelProgressiveFutureListener
cannot get exact information about the progress of the transfer.

If you add a few methods that optionally provides the transfer progress
to ChannelInput, it becomes possible for ChunkedWriteHandler to notify
ChannelProgressiveFutureListeners.

If the input has no definite length, we can still use the progress so
far, and consider the length of the input as 'undefined'.

Modifications:

- Add ChunkedInput.progress() and ChunkedInput.length()
- Modify ChunkedWriteHandler to use progress() and length() to notify
  the transfer progress

Result:

ChunkedWriteHandler now notifies ChannelProgressiveFutureListener.
2014-08-14 16:49:09 -07:00
fbregier
bc1379d19d [#2721] Improve Traffic Shaping handler
Motivation:
Currently Traffic Shaping is using 1 timer only and could lead to
"partial" wrong bandwidth computation when "short" time occurs between
adding used bytes and when the TrafficCounter updates itself and finally
when the traffic is computed.
Indeed, the TrafficCounter is updated every x delay and it is at the
same time saved into "lastXxxxBytes" and set to 0. Therefore, when one
request the counter, it first updates the TrafficCounter with the added
used bytes. If this value is set just before the TrafficCounter is
updated, then the bandwidth computation will use the TrafficCounter with
a "0" value (this value being reset once the delay occurs). Therefore,
the traffic shaping computation is wrong in rare cases.

Secondly the traffic shapping should avoid if possible the "Timeout"
effect by not stopping reading or writing more than a maxTime, this
maxTime being less than the TimeOut limit.

Thirdly the traffic shapping in read had an issue since the readOp
was not set but should, turning in no read blocking from socket
point of view.

Modifications:
The TrafficCounter has 2 new methods that compute the time to wait
according to read or write) using in priority the currentXxxxBytes (as
before), but could used (if current is at 0) the lastXxxxxBytes, and
therefore having more chance to take into account the real traffic.

Moreover the Handler could change the default "max time to wait", which
is by default set to half of "standard" Time Out (30s:2 = 15s).

Finally we add the setAutoRead(boolean) accordingly to the situation,
as proposed in #2696 (this pull request is in error for unknown reason).

Result:
The Traffic Shaping is better take into account (no 0 value when it
shouldn't) and it tries to not block traffic more than Time Out event.

Moreover the read is really stopped from socket point of view.

This version is similar to #2388 and #2450.
This version is for V4.1, and includes the #2696 pull request
to ease the merge process.
It is compatible with master too.

Including also #2748

The test minimizes time check by reducing to 66ms steps (55s).
2014-08-13 01:40:32 +02:00
Norman Maurer
02e7e53cbb [#2752] Add PendingWriteQueue for queue up writes
Motivation:

Sometimes ChannelHandler need to queue writes to some point and then process these. We currently have no datastructure for this so the user will use an Queue or something like this. The problem is with this Channel.isWritable() will not work as expected and so the user risk to write to fast. That's exactly what happened in our SslHandler. For this purpose we need to add a special datastructure which will also take care of update the Channel and so be sure that Channel.isWritable() works as expected.

Modifications:

- Add PendingWriteQueue which can be used for this purpose
- Make use of PendingWriteQueue in SslHandler

Result:

It is now possible to queue writes in a ChannelHandler and still have Channel.isWritable() working as expected. This also fixes #2752.
2014-08-12 06:38:22 +02:00
Trustin Lee
8263a62014 Clean-up d9cccccbb3
- Revert irrelevant formatting changes
- Rename resource files
  - Add .pem
  - Remove 'netty' from names
2014-08-04 10:54:05 -07:00
Peter Schulz
20dffa8ee6 [#2718] Added private key decryption to JDK SSL server context.
Motivation:

Currently it is not possible to load an encrypted private key when
creating a JDK based SSL server context.

Modifications:

- Added static method to JdkSslServerContext which handles key spec generation for (encrypted) private keys and make use of it.
-Added tests for creating a SSL server context based on a (encrypted)
private key.

Result:

It is now possible to create a JDK based SSL server context with an
encrypted (password protected) private key.
2014-08-04 14:19:40 +02:00
Norman Maurer
c85319213a [#2675] Replace synchronization performed on util.concurrent instance in TrafficCounter
Motivation:

Message from FindBugs:
This method performs synchronization an object that is an instance of a class from the java.util.concurrent package (or its subclasses). Instances of these classes have their own concurrency control mechanisms that are orthogonal to the synchronization provided by the Java keyword synchronized. For example, synchronizing on an AtomicBoolean will not prevent other threads from modifying the AtomicBoolean.
Such code may be correct, but should be carefully reviewed and documented, and may confuse people who have to maintain the code at a later date.

Modification:

Use synchronized(this)

Result:

Less confusing code
2014-07-21 08:23:24 +02:00
Idel Pivnitskiy
b83df4c6b3 Fix NPE problems
Motivation:

Now Netty has a few problems with null values.

Modifications:

- Check HAProxyProxiedProtocol in HAProxyMessage constructor and throw NPE if it is null.
If HAProxyProxiedProtocol is null we will set AddressFamily as null. So we will get NPE inside checkAddress(String, AddressFamily) and it won't be easy to understand why addrFamily is null.
- Check File in DiskFileUpload.toString().
If File is null we will get NPE when calling toString() method.
- Check Result<String> in MqttDecoder.decodeConnectionPayload(...).
If !mqttConnectVariableHeader.isWillFlag() || !mqttConnectVariableHeader.hasUserName() || !mqttConnectVariableHeader.hasPassword() we will get NPE when we will try to create new instance of MqttConnectPayload.
- Check Unsafe before calling unsafe.getClass() in PlatformDependent0 static block.
- Removed unnecessary null check in WebSocket08FrameEncoder.encode(...).
Because msg.content() can not return null.
- Removed unnecessary null check in DefaultStompFrame(StompCommand) constructor.
Because we have this check in the super class.
- Removed unnecessary null checks in ConcurrentHashMapV8.removeTreeNode(TreeNode<K,V>).
- Removed unnecessary null check in OioDatagramChannel.doReadMessages(List<Object>).
Because tmpPacket.getSocketAddress() always returns new SocketAddress instance.
- Removed unnecessary null check in OioServerSocketChannel.doReadMessages(List<Object>).
Because socket.accept() always returns new Socket instance.
- Pass Unpooled.buffer(0) instead of null inside CloseWebSocketFrame(boolean, int) constructor.
If we will pass null we will get NPE in super class constructor.
- Added throw new IllegalStateException in GlobalEventExecutor.awaitInactivity(long, TimeUnit) if it will be called before GlobalEventExecutor.execute(Runnable).
Because now we will get NPE. IllegalStateException will be better in this case.
- Fixed null check in OpenSslServerContext.setTicketKeys(byte[]).
Now we throw new NPE if byte[] is not null.

Result:

Added new null checks when it is necessary, removed unnecessary null checks and fixed some NPE problems.
2014-07-20 12:55:22 +02:00
Trustin Lee
e167b02d52 [maven-release-plugin] prepare for next development iteration 2014-07-04 17:26:02 +09:00
Trustin Lee
ba50cb829b [maven-release-plugin] prepare release netty-4.1.0.Beta1 2014-07-04 17:25:54 +09:00
Trustin Lee
787663a644 [maven-release-plugin] rollback the release of netty-4.1.0.Beta1 2014-07-04 17:11:14 +09:00
Trustin Lee
83eae705e1 [maven-release-plugin] prepare release netty-4.1.0.Beta1 2014-07-04 17:02:17 +09:00
Norman Maurer
217fb0de05 [#2618] Introduce ChannelPromise.unvoid() and ChannelFuture.isVoid()
Motivation:

There is no way for a ChannelHandler to check if the passed in ChannelPromise for a write(...) call is a VoidChannelPromise. This is a problem as some handlers need to add listeners to the ChannelPromise which is not possible in the case of a VoidChannelPromise.

Modification:

- Introduce ChannelFuture.isVoid() which will return true if it is not possible to add listeners or wait on the result.
- Add ChannelPromise.unvoid() which allows to create a ChannelFuture out of a void ChannelFuture which supports all the operations.

Result:

It's now easy to write ChannelHandler implementations which also works when a void ChannelPromise is used.
2014-07-03 14:17:12 +02:00
Trustin Lee
d0912f2709 Fix most inspector warnings
Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile
Update IntObjectHashMap

Result:

Cleaner code
2014-07-02 19:55:07 +09:00
Trustin Lee
085a61a310 Refactor FastThreadLocal to simplify TLV management
Motivation:

When Netty runs in a managed environment such as web application server,
Netty needs to provide an explicit way to remove the thread-local
variables it created to prevent class loader leaks.

FastThreadLocal uses different execution paths for storing a
thread-local variable depending on the type of the current thread.
It increases the complexity of thread-local removal.

Modifications:

- Moved FastThreadLocal and FastThreadLocalThread out of the internal
  package so that a user can use it.
- FastThreadLocal now keeps track of all thread local variables it has
  initialized, and calling FastThreadLocal.removeAll() will remove all
  thread-local variables of the caller thread.
- Added FastThreadLocal.size() for diagnostics and tests
- Introduce InternalThreadLocalMap which is a mixture of hard-wired
  thread local variable fields and extensible indexed variables
- FastThreadLocal now uses InternalThreadLocalMap to implement a
  thread-local variable.
- Added ThreadDeathWatcher.unwatch() so that PooledByteBufAllocator
  tells it to stop watching when its thread-local cache has been freed
  by FastThreadLocal.removeAll().
- Added FastThreadLocalTest to ensure that removeAll() works
- Added microbenchmark for FastThreadLocal and JDK ThreadLocal
- Upgraded to JMH 0.9

Result:

- A user can remove all thread-local variables Netty created, as long as
  he or she did not exit from the current thread. (Note that there's no
  way to remove a thread-local variable from outside of the thread.)
- FastThreadLocal exposes more useful operations such as isSet() because
  we always implement a thread local variable via InternalThreadLocalMap
  instead of falling back to JDK ThreadLocal.
- FastThreadLocalBenchmark shows that this change improves the
  performance of FastThreadLocal even more.
2014-06-19 21:13:55 +09:00
belliottsmith
2a2a21ec59 Introduce FastThreadLocal which uses an EnumMap and a predefined fixed set of possible thread locals
Motivation:
Provide a faster ThreadLocal implementation

Modification:
Add a "FastThreadLocal" which uses an EnumMap and a predefined fixed set of possible thread locals (all of the static instances created by netty) that is around 10-20% faster than standard ThreadLocal in my benchmarks (and can be seen having an effect in the direct PooledByteBufAllocator benchmark that uses the DEFAULT ByteBufAllocator which uses this FastThreadLocal, as opposed to normal instantiations that do not, and in the new RecyclableArrayList benchmark);

Result:
Improved performance
2014-06-13 10:56:18 +02:00
DhanaRaj Durairaj
eb27cd279c [#2494] Fix data curruption by ChannelTrafficShapingHandler
Motivation:
ChannelTrafficShapingHandler may corrupt inbound data stream by
scheduling the fireChannelRead event.

Modification:
Always call fireChannelRead(...) and only suspend reads after it

Result:
No more data corruption
2014-06-03 08:38:05 +02:00
Trustin Lee
2f8c13e85a Fix NPE 2014-05-22 10:29:24 +09:00
Trustin Lee
5ce410c69e Future compatibility with TLS ALPN
Motivation:

According to TLS ALPN draft-05, a client sends the list of the supported
protocols and a server responds with the selected protocol, which is
different from NPN.  Therefore, ApplicationProtocolSelector won't work
with ALPN

Modifications:

- Use Iterable<String> to list the supported protocols on the client
  side, rather than using ApplicationProtocolSelector
- Remove ApplicationProtocolSelector

Result:

Future compatibility with TLS ALPN
2014-05-22 10:03:02 +09:00
Trustin Lee
27b67e981e Fix NPE in OpenSslEngine 2014-05-21 20:02:40 +09:00
Trustin Lee
ac968fbf7b Escape a colon in protocol names 2014-05-21 17:45:18 +09:00
Trustin Lee
861ed1e7ad Add unified NextProtoNego extension support to SslContext
Motivation:

- OpenSslEngine and JDK SSLEngine (+ Jetty NPN) have different APIs to
  support NextProtoNego extension.
  - It is impossible to configure NPN with SslContext when the provider
    type is JDK.

Modification:

- Implement NextProtoNego extension by overriding the behavior of
  SSLSession.getProtocol() for both OpenSSLEngine and JDK SSLEngine.
  - SSLEngine.getProtocol() returns a string delimited by a colon (':')
    where the first component is the transport protosol (e.g. TLSv1.2)
    and the second component is the name of the application protocol
- Remove the direct reference of Jetty NPN classes from the examples
- Add SslContext.newApplicationProtocolSelector

Result:

- A user can now use both JDK SSLEngine and OpenSslEngine for NPN-based
  protocols such as HTTP2 and SPDY
2014-05-21 17:24:52 +09:00
Trustin Lee
4882377c27 Work around the JVM crash that occurs when cipher suite uses GCM
Motivation:

For an unknown reason, JVM of JDK8 crashes intermittently when
SslHandler feeds a direct buffer to SSLEngine.unwrap() *and* the current
cipher suite has GCM (Galois/Counter Mode) enabled.

Modifications:

Convert the inbound network buffer to a heap buffer when the current
cipher suite is using GCM.

Result:

JVM does not crash anymore.
2014-05-19 11:47:20 +09:00
Trustin Lee
ae61b12b9e Reduce memory usage of SslHandler when OpenSslEngine is in use
Motivation:

JDK's SSLEngine.wrap() requires the output buffer to be always as large as MAX_ENCRYPTED_PACKET_LENGTH even if the input buffer contains small number of bytes.  Our OpenSslEngine implementation does not have such wasteful behaviot.

Modifications:

If the current SSLEngine is OpenSslEngine, allocate as much as only needed.

Result:

Less peak memory usage.
2014-05-18 05:10:41 +09:00
Trustin Lee
28c390d86d Fix buffer leaks during PEM to KeyStore conversion 2014-05-18 04:29:50 +09:00
Trustin Lee
167a685a5f Fix JDK 8 compatibility issue with OpenJdkSelfSignedCertGenerator
- X509CertInfo.setSubject/setIssuer() requires X500Name instead of
  CertificateSubjectName/CertificateIssuerName.
2014-05-18 03:47:55 +09:00
Trustin Lee
9125060752 Optimize SslHandler in an OpenSslEngine-friendly way
Motivation:

Previous fix for the OpenSslEngine compatibility issue (#2216 and
18b0e95659) was to feed SSL records one by
one to OpenSslEngine.unwrap().  It is not optimal because it will result
in more JNI calls.

Modifications:

- Do not feed SSL records one by one.
- Feed as many records as possible up to MAX_ENCRYPTED_PACKET_LENGTH
- Deduplicate MAX_ENCRYPTED_PACKET_LENGTH definitions

Result:

- No allocation of intemediary arrays
- Reduced number of calls to SSLEngine and thus its underlying JNI calls
- A tad bit increase in throughput, probably reverting the tiny drop
  caused by 18b0e95659
2014-05-18 03:33:00 +09:00
Trustin Lee
b6c0c0c95f Add an OpenSslEngine and the universal API for enabling SSL
Motivation:

Some users already use an SSLEngine implementation in finagle-native. It
wraps OpenSSL to get higher SSL performance.  However, to take advantage
of it, finagle-native must be compiled manually, and it means we cannot
pull it in as a dependency and thus we cannot test our SslHandler
against the OpenSSL-based SSLEngine.  For an instance, we had #2216.

Because the construction procedures of JDK SSLEngine and OpenSslEngine
are very different from each other, we also need to provide a universal
way to enable SSL in a Netty application.

Modifications:

- Pull netty-tcnative in as an optional dependency.
  http://netty.io/wiki/forked-tomcat-native.html
- Backport NativeLibraryLoader from 4.0
- Move OpenSSL-based SSLEngine implementation into our code base.
  - Copied from finagle-native; originally written by @jpinner et al.
  - Overall cleanup by @trustin.
- Run all SslHandler tests with both default SSLEngine and OpenSslEngine
- Add a unified API for creating an SSL context
  - SslContext allows you to create a new SSLEngine or a new SslHandler
    with your PKCS#8 key and X.509 certificate chain.
  - Add JdkSslContext and its subclasses
  - Add OpenSslServerContext
- Add ApplicationProtocolSelector to ensure the future support for NPN
  (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on
  the client-side.
- Add SimpleTrustManagerFactory to help a user write a
  TrustManagerFactory easily, which should be useful for those who need
  to write an alternative verification mechanism. For example, we can
  use it to implement an unsafe TrustManagerFactory that accepts
  self-signed certificates for testing purposes.
- Add InsecureTrustManagerFactory and FingerprintTrustManager for quick
  and dirty testing
- Add SelfSignedCertificate class which generates a self-signed X.509
  certificate very easily.
- Update all our examples to use SslContext.newClient/ServerContext()
- SslHandler now logs the chosen cipher suite when handshake is
  finished.

Result:

- Cleaner unified API for configuring an SSL client and an SSL server
  regardless of its internal implementation.
- When native libraries are available, OpenSSL-based SSLEngine
  implementation is selected automatically to take advantage of its
  performance benefit.
- Examples take advantage of this modification and thus are cleaner.
2014-05-18 02:54:06 +09:00
Trustin Lee
2a6ed67efc Preparation for porting OpenSSL support in 3.10
- Add licenses and dependencies
2014-05-17 20:01:30 +09:00
Norman Maurer
0aea9eaed5 Correctly write pending data after ssl handshake completes. Related to [#2437]
Motivation:
When writing data from a server before the ssl handshake completes may not be written at all to the remote peer
if nothing else is written after the handshake was done.

Modification:
Correctly try to write pending data after the handshake was complete

Result:
Correctly write out all pending data
2014-04-30 14:23:18 +02:00
Trustin Lee
0fceef8ab6 Undeprecate deregister() and chanelUnregistered()
Motivation:

As discussed in #2250, it will become much less complicated to implement
deregistration and reregistration of a channel once #2250 is resolved.
Therefore, there's no need to deprecate deregister() and
channelUnregistered().

Modification:

- Undeprecate deregister() and channelUnregistered()
- Remove SuppressWarnings annotations where applicable

Result:

We (including @jakobbuchgraber) are now ready to play with #2250 at
master
2014-04-25 16:40:42 +09:00
Trustin Lee
d765f6b870 Synchronized between 4.1 and master (part 3)
Motivation:

4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master.  We must make sure 4.1 and master are not very
different now.

Modification:

Fix found differences

Result:

4.1 and master got closer.
2014-04-25 16:17:59 +09:00
Trustin Lee
b9039eaa82 Synchronized between 4.1 and master again (part 2)
Motivation:
4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master.  We must make sure 4.1 and master are not very
different now.

Modification:
Remove ChannelHandlerInvoker.writeAndFlush(...) and the related
implementations.

Result:
4.1 and master got closer.
2014-04-25 15:06:26 +09:00
Trustin Lee
db3709e652 Synchronized between 4.1 and master
Motivation:

4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master.  We must make sure 4.1 and master are not very
different now.

Modification:

Fix found differences

Result:

4.1 and master got closer.
2014-04-25 00:38:02 +09:00
Trustin Lee
af9ab8b370 Feed only a single SSL record to SSLEngine.unwrap()
Motivation:

Some SSLEngine implementations violate the contract and raises an
exception when SslHandler feeds an input buffer that contains multiple
SSL records to SSLEngine.unwrap(), while the expected behavior is to
decode the first record and return.

Modification:

- Modify SslHandler.decode() to keep the lengths of each record and feed
  SSLEngine.unwrap() record by record to work around the forementioned
  issue.
- Rename unwrap() to unwrapMultiple() and unwrapNonApp()
- Rename unwrap0() to unwrapSingle()

Result:

SslHandler now works OpenSSLEngine from finagle-native.  Performance
impact remains unnoticeable.  Slightly better readability. Fixes #2116.
2014-04-20 17:33:04 +09:00
Trustin Lee
e9161147a5 Work around an Android SSLEngine issue
Motivation:

Some Android SSLEngine implementations skip FINISHED handshake status
and go straightly into NOT_HANDSHAKING.  This behavior blocks SslHandler
from notifying its handshakeFuture, because we do the notification when
SSLEngine enters the FINISHED state.

Modification:

When the current handshake state is NOT_HANDSHAKING and the
handshakeFuture is not fulfilled yet, treat NOT_HANDSHAKING as FINISHED.

Result:

Better Android compatibility - fixes #1823
2014-04-18 17:59:48 +09:00
Norman Maurer
88481131be [#2353] Use a privileged block to get ClassLoader and System property if needed
Motivation:
When using System.getProperty(...) and various methods to get a ClassLoader it will fail when a SecurityManager is in place.

Modifications:
Use a priveled block if needed. This work is based in the PR #2353 done by @anilsaldhana .

Result:
Code works also when SecurityManager is present
2014-04-08 14:12:25 +02:00
Norman Maurer
3eec26b0a2 [#2358] SslHandler.safeClose(...) may not notify the ChannelPromise
Motivation:
In SslHandler.safeClose(...) we attach a ChannelFutureListener to the flushFuture and will notify the ChannelPromise which was used for close(...) in it. The problem here is that we only call ChannelHandlerContext.close(ChannelPromise) if Channel.isActive() is true and otherwise not notify it at all. We should just call ChannelHandlerContext.close(ChannelPromise) in all cases.

Modifications:
Always call ChannelHandlerContext.close(ChannelPromise) in the ChannelFutureListeiner

Result:
ChannelPromise used for close the Channel is notified in all cases
2014-04-03 13:27:33 +02:00
Ian Barfield
cf9c1f946a Deleting redundant needsFlush boolean
Motivation:

In ChunkedWriteHandler, there is a redundant variable that servers
no purpose. It implies that under some conditions you might not want
to flush.

Modifications:

Removed the variable and the if condition that read it. The boolean
was always true so just removing the if statement was fine.

Result:

Slightly less misleading code.
2014-03-29 20:21:19 +01:00
Norman Maurer
9856563144 Replace usage of System.currentTimeMillis() with System.nanoTime()
Motivation:

Currently we use System.currentTimeMillis() in our timeout handlers this is bad
for various reasons like when the clock adjusts etc.

Modifications:

Replace System.currentTimeMillis() with System.nanoTime()

Result:

More robust timeout handling
2014-03-18 16:06:16 +09:00
Trustin Lee
1e4c22453c Do not use finally to propagate events in AbstractRemoteAddressFilter
Motivation:

We don't really need to propagate an event when handling the event fails.

Modifications:

Do not use finally block in AbstractRemoteAddressFilter

Result:

AbstractRemoteaddressFilter does not forward an event in case of failure.
2014-03-12 16:17:40 +09:00
Trustin Lee
cf275237c9 Overall clean-up of ipfilter package
Motivation:

Recently merged ipfilter package has the following problems:
* AbstractIpFilterHandler could be improved to support any SocketAddress types rather than only InetSocketAddress.
* AbstractIpFilterHandler can be removed immediately after decision is made rather than keeping the outcome of the decision as an attribute.
* AbstractIpFilterHandler doesn't have a hook for the accepted addresses.
* The hook method (reject()) needs to be named in line with other handler methods (i.e. channelRejected())
* IpFilterRuleHandler should allow accepting zero rules - it's particularly useful for machine-configured setup (i.e. specifying zero rules disables ipfilter).
* IpFilterRuleType.ALLOW/DENY should be ACCEPT/REJECT for consistency.

Modifications:

* AbstractIpFilterHandler has been renamed to AbstractRemoteAddressFilter and now uses type parameter.
* Added channelAccepted() and renamed reject() to channelRejected()
* Added ChannelHandlerContext as a parameter of accept() so that accept() can add a listener to the closeFuture() of the channel. This way, UniqueIpFilter continue working even if we remove the filtering handler early.
* Various renames
  * IpFilterRuleHandler -> RuleBasedIpFilter
  * UniqueIpFilterHandler -> UniqueIpFilter

Result:

* Much cleaner API with more extensibility
2014-03-12 16:06:04 +09:00
Jakob Buchgraber
386cc2cb73 ipfilter implementation for netty 4/5 [#2129] 2014-03-10 20:43:39 +01:00
Norman Maurer
918dd54a72 [#2261] Correct javadoc of ChunkedInput 2014-03-03 07:04:11 +01:00
Trustin Lee
1884a5697c Avoid unnecessary IllegalStateException in ChunkedWriteHandler
Motivation:
ChunkedWriteHandler can sometimes fail to write the last chunk of a ChunkedInput due to an I/O error.  Subsequently, the ChunkedInput's associated promise is marked as failure and the connection is closed.  When the connection is closed, ChunkedWriteHandler attempts to clean up its message queue and to mark their promises as success or failure.  However, because the promise of the ChunkedInput, which was consumed completely yet failed to be written, is already marked as failure, the attempt to mark it as success fails, leading a WARN level log.

Modification:
Use trySuccess() instead of setSuccess() so that the attempt to mark a ChunkedInput as success does not raise an exception even if the promise is already done.

Result:
Fixes #2249
2014-02-20 17:14:25 -08:00
Trustin Lee
abcb39b638 Do not use String.format() for log message generation
- It's slow.
2014-02-13 19:31:17 -08:00
Trustin Lee
ac70dc4546 Update the version to 4.1.0.Alpha1-SNAPSHOT 2014-02-13 18:32:26 -08:00
Trustin Lee
df346a023b Change the return type of EmbeddedChannel.read*() from Object to an ad-hoc type parameter
.. so that there's no need to explicitly down-cast.

Fixes #2067
2014-02-13 17:19:26 -08:00
Trustin Lee
a8bc720977 Fixed buffer leaks in LoggingHandlerTest 2014-02-13 17:03:21 -08:00
Trustin Lee
3d874f0bd7 Improve documentation for the two-args formatter in LoggingHandler 2014-02-13 16:51:26 -08:00
Trustin Lee
fbed62249c Rename formatUserMessage to formatSimple and use it in two-args formatter in LoggingHandler 2014-02-13 16:51:15 -08:00
Trustin Lee
a9150ee7d6 Simplify two-args message formatter in LoggingHandler 2014-02-13 16:51:06 -08:00
Trustin Lee
2e58497160 Make LoggingHandler.appendHexDump(..) protected for the subclasses 2014-02-13 16:50:50 -08:00
Trustin Lee
835b4443f3 Optimize and clean up LoggingHandler
- Use ': ' instead of '(...)' for simpler string concatenation and prettier presentation
- Optimize the overall performance of format*() methods
- All format*() methods are now expected to encode the channel information by themselves so that StringBuilder instances are created less often.
- Use a look-up table for generating per-row prefixes
- Hid formatByteBuf(), formatByteBufHolder(), and formatNonByteBuf() from user because a user can always override format(ctx, eventName, arg).  For example, to disable hexdump:

    protected void format(ChannelHandlerContext ctx, String eventName, Object arg) {
        if (arg instanceof ByteBuf) {
            super.format(ctx, eventName, arg.toString());
        } else {
            super.format(ctx, eventName, arg);
        }
    }
2014-02-13 16:50:31 -08:00
Trustin Lee
499033d44f Add a shortcut method for collision-free naming 2014-02-13 15:17:09 -08:00
Trustin Lee
c4c71e6d28 Fix the potential copyright issue in SocksCommonUtils
- Add StringUtil.toHexString() methods which are based on LoggingHandler's lookup table implementation, and use it wherever possible
2014-02-06 15:00:06 -08:00
Norman Maurer
37e6588845 [#2159] Not fail the ChannelPromise with WriteTimeoutException to prevent warning 2014-01-30 07:02:06 +01:00
Norman Maurer
d67184b488 [maven-release-plugin] prepare for next development iteration 2014-01-21 08:18:32 +01:00
Norman Maurer
287515210d [maven-release-plugin] prepare release netty-4.0.15.Final 2014-01-21 08:18:26 +01:00
Trustin Lee
bc21443ea9 Fix a regression in SslHandler where delegated tasks run in a different executor makes the session hang
- Fixes #2098
- Deprecate specifying an alternative Executor for delegated tasks for SslHandler
2014-01-09 18:08:05 +09:00
Trustin Lee
e83d2e0b4e [maven-release-plugin] prepare for next development iteration 2013-12-22 21:57:48 +09:00
Trustin Lee
cdb700c7a4 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:57:40 +09:00
Trustin Lee
0b7aedb13b [maven-release-plugin] rollback the release of netty-4.0.14.Final 2013-12-22 21:53:24 +09:00
Trustin Lee
4bf6ec7171 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:52:56 +09:00
Trustin Lee
9c1a49c58e [maven-release-plugin] rollback the release of netty-4.0.14.Final 2013-12-22 21:47:35 +09:00
Trustin Lee
008a049bf4 [maven-release-plugin] prepare for next development iteration 2013-12-22 21:43:55 +09:00
Trustin Lee
f6cb9088c6 [maven-release-plugin] prepare release netty-4.0.14.Final 2013-12-22 21:43:45 +09:00
Trustin Lee
f7a3881536 Fix a bug in SslHandler where a ClassCastException is raised when non-ByteBuf message is passed
- Fixes #1828
2013-12-16 16:30:41 +09:00
Norman Maurer
b3d8c81557 Fix all leaks reported during tests
- One notable leak is from WebSocketFrameAggregator
- All other leaks are from tests
2013-12-07 00:44:56 +09:00
Norman Maurer
7c7acdcaac [#2033] Correctly handle adding of IdleStateHandler after Channel was already active and registered 2013-12-03 13:56:43 +01:00
Norman Maurer
17f5865e38 [maven-release-plugin] prepare for next development iteration 2013-11-29 19:31:01 +01:00
Norman Maurer
ead617fdcc [maven-release-plugin] prepare release netty-4.0.14.Beta1 2013-11-29 19:30:55 +01:00
Norman Maurer
6cf2748dbb [maven-release-plugin] prepare for next development iteration 2013-11-28 15:04:51 +01:00
Norman Maurer
5fe7596f49 [maven-release-plugin] prepare release netty-4.0.13.Final 2013-11-28 15:04:46 +01:00
Trustin Lee
407f0a36f5 Simplify bundle generation / Add io.netty.versions.properties to all JARs
- Fixes #2003 properly
- Instead of using 'bundle' packaging, use 'jar' packaging.  This is
  more robust because some strict build tools fail to retrieve the
  artifacts from a Maven repository unless their packaging is not 'jar'.
- All artifacts now contain META-INF/io.netty.version.properties, which
  provides the detailed information about the build and repository.
- Removed OSGi testsuite temporarily because it gives false errors
  during split package test and examination.
- Add io.netty.util.Version for easy retrieval of version information
2013-11-26 22:01:46 +09:00
Alex Petrov
90309f9065 Improve doc of IdleStateHandler according to example given in UptimeClientHandler (L57) 2013-11-20 10:24:33 +01:00
Trustin Lee
b65b4199dc Fix regression introduced by 4c7fa950cc
- Some promises were not fulfilled when SSLEngine produces 0 bytes.
2013-11-14 15:09:20 +09:00
Trustin Lee
11f95c78e2 Optimize SslHandler
- Fixes #1905
- Call ctx.flush() only when necessary
- Improve the estimation of application and packet buffer sizes
- decode() method now tries to call unwrap() with as many SSL records as
  possible to reduce the number of events triggered
2013-11-08 17:41:16 +09:00
Norman Maurer
db78581bbb [maven-release-plugin] prepare for next development iteration 2013-11-07 18:11:45 +01:00
Norman Maurer
2386777af8 [maven-release-plugin] prepare release netty-4.0.12.Final 2013-11-07 18:11:38 +01:00
Trustin Lee
51ca4f3e91 Fix a bug where SslHandler doesn't sometimes handle renegotiation correctly
- Fixes #1964
2013-11-04 16:54:13 +09:00
Trustin Lee
1c2352e6a0 Replace constructor calls on UniqueName and its subtypes with valueOf() wherever possible 2013-10-25 20:58:53 +09:00
Norman Maurer
ceab146b54 [maven-release-plugin] prepare for next development iteration 2013-10-21 07:43:42 +02:00
Norman Maurer
27a89d6032 [maven-release-plugin] prepare release netty-4.0.11.Final 2013-10-21 07:41:49 +02:00
Norman Maurer
79562d5891 [#1936] Fix example in javadoc 2013-10-20 09:32:38 +02:00
Norman Maurer
bcdb3e88d8 [#1934] Correctly log handshake errors and not print them to STDERR 2013-10-18 17:39:04 +02:00
Norman Maurer
beda02fad0 [#1898] No call fireExceptionCaught but just fail the write promise 2013-10-08 10:02:50 +02:00
Norman Maurer
c5f6760c68 [#1895] Fix IllegalStateException which was produced during failing ChunkedWrite after the channel was closed 2013-10-08 06:40:43 +02:00
Norman Maurer
d7da19f745 [maven-release-plugin] prepare for next development iteration 2013-10-02 15:48:52 +02:00
Norman Maurer
d35768ae11 [maven-release-plugin] prepare release netty-4.0.10.Final 2013-10-02 15:48:45 +02:00
Norman Maurer
cf4d25823c Propagate channelWritabilityChanged() through the pipeline after flushing. Related to [#1861] 2013-09-24 14:05:25 +02:00
Norman Maurer
ef936a6d41 Correctly handle automatically suspend/resume in ChunkedWriteHandler. Related to [#1861]
The old implementation was broken and could lead to pending message never be picked up again until the user either explicit called flush or
resumeTransfer().
2013-09-24 13:57:51 +02:00
Norman Maurer
29d34c672c [#1855] Try to calculate the correct amount of written bytes to update the ChannelProgressiveFuture 2013-09-24 07:49:26 +02:00
Norman Maurer
ffab456aca Bump up version to reflect correct one 2013-09-09 11:20:12 +02:00
Norman Maurer
363531caf9 [maven-release-plugin] rollback the release of netty-4.0.9.Final 2013-09-06 09:18:34 +02:00
Norman Maurer
9d53573ee8 [maven-release-plugin] prepare for next development iteration 2013-09-06 09:17:15 +02:00
Trustin Lee
ad0c456209 Ensure operationProgressed is invoked even on completion
- Fixes #1809
2013-09-05 18:37:14 +09:00
Norman Maurer
2e39b25cd4 [maven-release-plugin] prepare for next development iteration 2013-08-26 12:01:03 +02:00
Norman Maurer
b67659a866 [maven-release-plugin] prepare release netty-4.0.8.Final 2013-08-26 12:00:54 +02:00
Norman Maurer
9e7529b2f5 [#1743] Fix IllegalStateException by remove usage of PendingWrite in ChunkedWriteHandler. This needs more thoughts before re-introduce it 2013-08-16 08:11:19 +02:00
Norman Maurer
48eb73f9b1 [#1733] Correctly pass the promise to the ctx.write(...) in AbstractTrafficShapingHandler 2013-08-13 08:21:26 +02:00
Norman Maurer
f8f19d1539 [#1732] Fix bug which lead ChannelTrafficShapingHandler stop to work after first Channel was disconnected 2013-08-13 08:09:59 +02:00
Norman Maurer
8af5ea8d4f [#1658] Allow to use AbstractTrafficShapingHandler also with ByteBufHolder based messages 2013-08-10 20:25:35 +02:00
Norman Maurer
c1d787bff7 [#1722] ChunkedWriteHandler.doFlush(...) should not call fireExceptionCaught(..) 2013-08-09 21:32:17 +02:00
Norman Maurer
72395bf400 [#1719] Make sure PendingWrite is only recycled once in ChunkedWriteHandler 2013-08-09 18:44:58 +02:00
Norman Maurer
1d3560e389 [maven-release-plugin] prepare for next development iteration 2013-08-08 13:53:28 +02:00
Norman Maurer
8e97e6c461 [maven-release-plugin] prepare release netty-4.0.7.Final 2013-08-08 13:53:19 +02:00
Norman Maurer
3f2000fa3a [maven-release-plugin] prepare for next development iteration 2013-08-01 10:59:55 +02:00
Norman Maurer
3f70d5caa4 [maven-release-plugin] prepare release netty-4.0.6.Final 2013-08-01 10:59:46 +02:00
Norman Maurer
e3410680de [maven-release-plugin] prepare for next development iteration 2013-07-31 20:08:14 +02:00
Norman Maurer
0e124583d6 [maven-release-plugin] prepare release netty-4.0.5.Final 2013-07-31 20:08:05 +02:00
Norman Maurer
56646920c0 Formatting 2013-07-29 20:59:45 +02:00
Norman Maurer
9da81acec1 [#1657] Log content of ByteBufHolder 2013-07-29 20:57:33 +02:00
Norman Maurer
00f1533fa9 [#1671] Fix bug in ChunkedWriteHandler which produce a NPE on empty chunks 2013-07-29 16:23:43 +02:00
Norman Maurer
0cb3541b53 [#1669] Correctly notify the ChannelPromise of delayed writes 2013-07-29 08:13:29 +02:00
Norman Maurer
5e703e7419 [#1658] Let trafficshaping work with ByteBuf and ByteBufHolder out of the box 2013-07-29 07:31:09 +02:00
Frédéric Brégier
61b1214b24 Fix for first issue from #1652 on computation of time to wait in AbstractTrafficShapingHandler for Netty 4
Fix for first issue from #1652 on computation of time to wait in AbstractTrafficShapingHandler for Netty 4, using the same formula than in Netty 3 (wrong place for parenthese).
Was:

    (bytes * 1000 / limit - interval / 10) * 10;

Becomes:

    (bytes * 1000 / limit - interval) / 10 * 10;
2013-07-26 15:24:31 +02:00
Norman Maurer
2b3ac3d446 Factor out the PendingWrite class and put it in internal package. Make use of it in SslHandler and ChunkedWriteHandler to reduce GC-pressure 2013-07-25 12:36:24 +02:00
Norman Maurer
0bc7d3f5d1 [maven-release-plugin] prepare for next development iteration 2013-07-23 10:04:23 +02:00
Norman Maurer
ca00182797 [maven-release-plugin] prepare release netty-4.0.4.Final 2013-07-23 10:04:14 +02:00
Norman Maurer
fa4e15e198 Make PendingWrites recyclable to reduce GC pressure 2013-07-20 18:15:35 +02:00
Trustin Lee
4f6ba4fe3d Use tryProgress just in case of user error 2013-07-19 13:30:33 +09:00
Trustin Lee
762adfcb69 Update HttpStaticFileServer example / Fix bugs related with progress notification
- Fix a bug in DefaultProgressivePromise.tryProgress() where the notification is dropped
 - Fix a bug in AbstractChannel.calculateMessageSize() where FileRegion is not counted
 - HttpStaticFileServer example now uses zero copy file transfer if possible.
2013-07-19 13:21:32 +09:00
Trustin Lee
f96a8e5951 Implement ProgressivePromise notification in NIO byte channels and ChunkedWriteHandler
- Refine the contract of GenericProgressiveFutureListener.
- Negative 'total' now means 'unknown', which is useful for ChunkedWriteHandler.
2013-07-19 12:53:23 +09:00
Trustin Lee
6791984146 Remove unnecessary code from SslHandler
- Remove CloseNotifyListener which was used only to reduce the noisy logging.
- Instead, simply do a string match.
- Fixes #1608
2013-07-19 09:24:19 +09:00
Trustin Lee
b130ee6a6c [maven-release-plugin] prepare for next development iteration 2013-07-18 11:17:42 +09:00
Trustin Lee
10d395e829 [maven-release-plugin] prepare release netty-4.0.3.Final 2013-07-18 11:17:31 +09:00
Norman Maurer
fc7c950b08 [maven-release-plugin] prepare for next development iteration 2013-07-17 15:58:36 +02:00
Norman Maurer
bbbf72359e [maven-release-plugin] prepare release netty-4.0.2.Final 2013-07-17 15:58:28 +02:00
Trustin Lee
57eb531eb8 [maven-release-plugin] prepare for next development iteration 2013-07-16 17:16:10 +09:00
Trustin Lee
76cefcc421 [maven-release-plugin] prepare release netty-4.0.1.Final 2013-07-16 17:15:54 +09:00
Norman Maurer
def3dbe035 Add missing closing paren 2013-07-16 07:39:33 +02:00
Norman Maurer
5297eba280 [maven-release-plugin] prepare for next development iteration 2013-07-15 15:48:15 +02:00
Norman Maurer
c5d8af446a [maven-release-plugin] prepare release netty-4.0.0.Final 2013-07-15 15:48:05 +02:00
Trustin Lee
246a3ecdcb [maven-release-plugin] prepare for next development iteration 2013-07-15 20:58:33 +09:00
Trustin Lee
e8fd209115 [maven-release-plugin] prepare release netty-4.0.0.Final 2013-07-15 20:58:21 +09:00
Norman Maurer
a215ba6ef6 Some javadocs 2013-07-12 15:45:09 +02:00
Norman Maurer
023201f684 [#1570] ChunkedWriteHandler.discard(..) must not call fireExceptionCaught(...) 2013-07-12 10:58:38 +02:00
Norman Maurer
1a7d1f7023 [#1568] Fix problem where an exception was fired after the channel was closed.
* Calling fireExceptionCaught(...) in this case was not correct as we failed writes which are outbound operations.
2013-07-12 10:42:39 +02:00
Jeff Pinner
be963d4caf rewrite SslHandler's flush0 message to match docs 2013-07-12 07:18:47 +02:00
Jeff Pinner
c77ab7d092 Fix a NoSuchElementException and out-of-order event problem caused by SslHandler
The fix prevents from reentering channelRead incorrectly. It also
prevents from getting the inbound requests out of order.
2013-07-12 09:51:28 +09:00
Norman Maurer
d8479a04df Allocate buffer from ByteBufAllocator in ChunkedFile 2013-07-12 00:02:54 +02:00
Norman Maurer
64686deaff Tiny optimization 2013-07-11 15:47:29 +02:00
Norman Maurer
4d94f1d1e1 [#1534] Finally fix SslHandler to also correctly handle partial data 2013-07-11 06:40:04 +02:00
Norman Maurer
b57d9f307f Allow per-write promises and disallow promises on flush()
- write() now accepts a ChannelPromise and returns ChannelFuture as most
  users expected.  It makes the user's life much easier because it is
  now much easier to get notified when a specific message has been
  written.
- flush() does not create a ChannelPromise nor returns ChannelFuture.
  It is now similar to what read() looks like.
2013-07-11 00:49:48 +09:00
Norman Maurer
da5c6add14 Rename CodecOutput to RecyclableArrayList and move it to internal package.
* Also reuse it in SslHandler
2013-07-10 07:50:26 +02:00
Trustin Lee
26e9d70457 Remove channelReadSuspended / Rename messageReceived(Last) to channelRead(Complete)
- Remove channelReadSuspended because it's actually same with messageReceivedLast
- Rename messageReceived to channelRead
- Rename messageReceivedLast to channelReadComplete

We renamed messageReceivedLast to channelReadComplete because it
reflects what it really is for.  Also, we renamed messageReceived to
channelRead for consistency in method names.
2013-07-09 23:58:51 +09:00
Norman Maurer
354de0a8f0 [#1534] Fix handling of partial frames in SslHandler
* Let SslHandler not extend ByteToMessageDecoder
2013-07-09 23:58:50 +09:00
Trustin Lee
cbd8817905 Remove MessageList from public API and change ChannelInbound/OutboundHandler accordingly
I must admit MesageList was pain in the ass.  Instead of forcing a
handler always loop over the list of messages, this commit splits
messageReceived(ctx, list) into two event handlers:

- messageReceived(ctx, msg)
- mmessageReceivedLast(ctx)

When Netty reads one or more messages, messageReceived(ctx, msg) event
is triggered for each message.  Once the current read operation is
finished, messageReceivedLast() is triggered to tell the handler that
the last messageReceived() was the last message in the current batch.

Similarly, for outbound, write(ctx, list) has been split into two:

- write(ctx, msg)
- flush(ctx, promise)

Instead of writing a list of message with a promise, a user is now
supposed to call write(msg) multiple times and then call flush() to
actually flush the buffered messages.

Please note that write() doesn't have a promise with it.  You must call
flush() to get notified on completion. (or you can use writeAndFlush())

Other changes:

- Because MessageList is completely hidden, codec framework uses
  List<Object> instead of MessageList as an output parameter.
2013-07-09 23:51:48 +09:00
Norman Maurer
1d196c5b59 [#1534] Fix handling of partial frames in SslHandler
* Let SslHandler not extend ByteToMessageDecoder
2013-07-09 15:53:18 +02:00
Norman Maurer
9c1b31d20a [#1535] Remove Channel.id() and so fix the possible leakage of the previous used Channel id map
The user can still use Channel.hashCode() for logging. It's just not 100% unique but should be good enough for most cases
2013-07-08 14:07:18 +02:00
Trustin Lee
da5a5af520 Add Test case for truncated SSL packets
- Related issue: #1534
- Also made sure ByteToMessageDecoder does not wrap EncoderException.
2013-07-07 11:52:34 +09:00
Trustin Lee
5010fe0a61 Fix a bug in SslHandler where a truncated packet isn't handled correctly
- Fixes #1534
2013-07-07 11:22:02 +09:00
Norman Maurer
824bb3419a [#1511] Fix NPE in AbstractTrafficShapingHandler which could happen if the READ_SUSPEND attr was not set yet 2013-07-02 19:30:05 +02:00
Norman Maurer
ec5e793a2f [maven-release-plugin] prepare for next development iteration 2013-07-02 11:41:18 +02:00
Norman Maurer
ca73eaef0d [maven-release-plugin] prepare release netty-4.0.0.CR9 2013-07-02 11:41:09 +02:00
Norman Maurer
830c559405 [maven-release-plugin] rollback the release of netty-4.0.0.CR9 2013-07-02 11:34:29 +02:00
Norman Maurer
66a16b133c [maven-release-plugin] prepare release netty-4.0.0.CR9 2013-07-02 10:45:12 +02:00
Trustin Lee
7e3a01cc51 [maven-release-plugin] prepare for next development iteration 2013-07-02 10:26:48 +09:00
Trustin Lee
149db34c19 [maven-release-plugin] prepare release netty-4.0.0.CR8 2013-07-02 10:26:32 +09:00
Trustin Lee
613547b0b9 [maven-release-plugin] prepare for next development iteration 2013-06-28 22:15:33 +09:00
Trustin Lee
a6abd2feb2 [maven-release-plugin] prepare release netty-4.0.0.CR7 2013-06-28 22:15:20 +09:00
Trustin Lee
a6795d7780 [maven-release-plugin] prepare for next development iteration 2013-06-25 11:07:15 +09:00
Trustin Lee
2221446425 [maven-release-plugin] prepare release netty-4.0.0.CR6 2013-06-25 11:07:15 +09:00
Norman Maurer
e06fcdbc6a [#1475] Correctly handle writes with empty MessageList in SslHandler 2013-06-25 11:07:14 +09:00
Norman Maurer
ad73dce7a1 [#1464] Make sure the ChannelPromise for writes is notified while using SslHandler 2013-06-25 11:07:14 +09:00
Trustin Lee
39d71440e1 Fix checkstyle 2013-06-25 11:07:13 +09:00
Trustin Lee
b6fdac7df3 Remove unnecessary logging handler - ByteLoggingHandler and MessageLoggingHandler / Extensible log message formatiing 2013-06-25 11:07:13 +09:00
Trustin Lee
a5871dfd86 [maven-release-plugin] prepare for next development iteration 2013-06-14 12:55:15 +09:00
Trustin Lee
f5377cc8d7 [maven-release-plugin] prepare release netty-4.0.0.CR5 2013-06-14 12:55:05 +09:00
Trustin Lee
e5ca6518ba [maven-release-plugin] prepare for next development iteration 2013-06-13 17:02:32 +09:00
Trustin Lee
381063e09c [maven-release-plugin] prepare release netty-4.0.0.CR4 2013-06-13 17:02:19 +09:00
Trustin Lee
01d9f10af6 Remove the volatile modifiers where they are unnecessary 2013-06-13 14:43:39 +09:00
Trustin Lee
7eb0f6105d Fix memory leaks 2013-06-13 13:32:47 +09:00
Norman Maurer
07858a3bd4 [#1411] Correctly check for null in AbstractTrafficShapperHandler.read() and so prevent NPE 2013-06-10 09:25:09 +02:00
Trustin Lee
14158070bf Revamp the core API to reduce memory footprint and consumption
The API changes made so far turned out to increase the memory footprint
and consumption while our intention was actually decreasing them.

Memory consumption issue:

When there are many connections which does not exchange data frequently,
the old Netty 4 API spent a lot more memory than 3 because it always
allocates per-handler buffer for each connection unless otherwise
explicitly stated by a user.  In a usual real world load, a client
doesn't always send requests without pausing, so the idea of having a
buffer whose life cycle if bound to the life cycle of a connection
didn't work as expected.

Memory footprint issue:

The old Netty 4 API decreased overall memory footprint by a great deal
in many cases.  It was mainly because the old Netty 4 API did not
allocate a new buffer and event object for each read.  Instead, it
created a new buffer for each handler in a pipeline.  This works pretty
well as long as the number of handlers in a pipeline is only a few.
However, for a highly modular application with many handlers which
handles connections which lasts for relatively short period, it actually
makes the memory footprint issue much worse.

Changes:

All in all, this is about retaining all the good changes we made in 4 so
far such as better thread model and going back to the way how we dealt
with message events in 3.

To fix the memory consumption/footprint issue mentioned above, we made a
hard decision to break the backward compatibility again with the
following changes:

- Remove MessageBuf
- Merge Buf into ByteBuf
- Merge ChannelInboundByte/MessageHandler and ChannelStateHandler into ChannelInboundHandler
  - Similar changes were made to the adapter classes
- Merge ChannelOutboundByte/MessageHandler and ChannelOperationHandler into ChannelOutboundHandler
  - Similar changes were made to the adapter classes
- Introduce MessageList which is similar to `MessageEvent` in Netty 3
- Replace inboundBufferUpdated(ctx) with messageReceived(ctx, MessageList)
- Replace flush(ctx, promise) with write(ctx, MessageList, promise)
- Remove ByteToByteEncoder/Decoder/Codec
  - Replaced by MessageToByteEncoder<ByteBuf>, ByteToMessageDecoder<ByteBuf>, and ByteMessageCodec<ByteBuf>
- Merge EmbeddedByteChannel and EmbeddedMessageChannel into EmbeddedChannel
- Add SimpleChannelInboundHandler which is sometimes more useful than
  ChannelInboundHandlerAdapter
- Bring back Channel.isWritable() from Netty 3
- Add ChannelInboundHandler.channelWritabilityChanges() event
- Add RecvByteBufAllocator configuration property
  - Similar to ReceiveBufferSizePredictor in Netty 3
  - Some existing configuration properties such as
    DatagramChannelConfig.receivePacketSize is gone now.
- Remove suspend/resumeIntermediaryDeallocation() in ByteBuf

This change would have been impossible without @normanmaurer's help. He
fixed, ported, and improved many parts of the changes.
2013-06-10 16:10:39 +09:00
Norman Maurer
d9c700e9fe [#1392] Fix bug where SslHandler returned wrong value for getCloseNotifyTimeoutMillis() 2013-05-24 23:18:14 +02:00
Norman Maurer
81e3c1719a [maven-release-plugin] prepare for next development iteration 2013-05-18 09:59:13 +02:00
Norman Maurer
99caefdf39 [maven-release-plugin] prepare release netty-4.0.0.CR3 2013-05-18 09:57:11 +02:00
Trustin Lee
50433f7b9a Make sure successful SslHandshakeCompletionEvent is a singleton
- Related: #1373
- This commit is an amendment to 2a7bea2ad3
2013-05-18 05:50:58 +09:00
Norman Maurer
2a7bea2ad3 [#1373] Make SslHandshakeCompletionEvent constructor public 2013-05-17 19:39:52 +02:00
Trustin Lee
dc13b68632 Make sure ChannelHandler.handlerRemoved() is always invoked
- Fixes #1366: No elegant way to free non-in/outbound buffers held by a handler
- handlerRemoved() is now also invoked when a channel is deregistered, as well as when a handler is removed from a pipeline.
- A little bit of clean-up for readability
- Fix a bug in forwardBufferContentAndRemove() where the handler buffers are not freed (mainly because we were relying on channel.isRegistered() to determine if the handler has been removed from inside the handler.
- ChunkedWriteHandler.handlerRemoved() is unnecessary anymore because ChannelPipeline now always forwards the content of the buffer.
2013-05-16 19:32:39 +09:00
Norman Maurer
f4ad6173ca [#1299] Make sure a handshake error will not trigger fireExceptionCaught two times 2013-05-12 17:01:12 +02:00
Norman Maurer
c43950a03f [maven-release-plugin] prepare for next development iteration 2013-05-08 18:19:51 +02:00
Norman Maurer
ae76502040 [maven-release-plugin] prepare release netty-4.0.0.CR2 2013-05-08 18:19:38 +02:00
Norman Maurer
5dd867ee23 [#1340] use full url in comment 2013-05-07 14:54:27 +02:00
Norman Maurer
6cbc6e9886 [#1340] Log SslExceptions thrown by SslEngine.closeInbound() with debug level 2013-05-07 09:42:02 +02:00
Trustin Lee
7884574c7b Remove freeInboundBuffer() and freeOutboundBuffer() which has no value
- Fixes #1308

freeInboundBuffer() and freeOutboundBuffer() were introduced in the early days of the new API when we did not have reference counting mechanism in the buffer. A user did not want Netty to free the handler buffers had to override these methods.

However, now that we have reference counting mechanism built into the buffer, a user who wants to retain the buffers beyond handler's life cycle can simply return the buffer whose reference count is greater than 1 in newInbound/OutboundBuffer().
2013-04-25 09:15:55 +09:00
Trustin Lee
cd26da96b8 Add more safe-to-ignore exception messages for SslHandler
- Just in case SslHandler is used on UDT
2013-04-24 18:06:14 +09:00
Trustin Lee
322449eedc Add another safe-to-ignore socket error message for SslHandler
.. which covers the 'Software caused connection abort: recv failed' from Windows
2013-04-24 17:05:55 +09:00
Trustin Lee
b5989e2449 Reduce exception instantiation overhead in SslHandler / Reduce unnecessary empty array creation
- Added EmptyArrays as an internal utility class
2013-04-24 09:32:53 +09:00
Norman Maurer
c95796d981 [#1302] Make sure the handshake future is failed with a ClosedChannelException on channelInactive 2013-04-23 18:20:38 +02:00
Norman Maurer
1cdb9e0b48 Just fail all futures that are left to not cause out-of-order writes 2013-04-19 07:06:22 +02:00
Norman Maurer
ca5554dfe7 [#1236] Fix problem where adding a new ChannelHandler could block the eventloop
This change also introduce a few other changes which was needed:
 * ChannelHandler.beforeAdd(...) and ChannelHandler.beforeRemove(...) were removed
 * ChannelHandler.afterAdd(...) -> handlerAdded(...)
 * ChannelHandler.afterRemoved(...) -> handlerRemoved(...)
 * SslHandler.handshake() -> SslHandler.hanshakeFuture() as the handshake is triggered automatically after
   the Channel becomes active
2013-04-19 07:00:50 +02:00
Trustin Lee
e556232aeb Rename HandshakeCompletionEvent to SslHandshakeCompletionEvent 2013-04-11 16:50:42 +09:00
Norman Maurer
b3429af1cc [#1260] Fire a HandshakeCompletationEvent once the SSL handshake completes 2013-04-11 06:47:43 +02:00
Norman Maurer
d34daebeca [#1238] Correctly log the content of the MessageBuf and not depend on MessageBuf.toString()
Add an extra static method to BufUtil which will convert the content of any MessaBuf implementation to a String
2013-04-08 09:45:00 +02:00
Norman Maurer
b36e815026 [#1241] Fix NPE in AbstractTrafficShapingHandler and the logic 2013-04-07 11:02:32 +02:00
Trustin Lee
d299eeb485 Fix a bug in AbstractTrafficShapingHandler.getTimeToWait() where it doesn't work OK when system time goes back. 2013-04-05 13:44:51 +09:00
Andrei Pozolotin
a3e760a003 fix #1234 - duplicate package-info.java errors in eclipse requires release of netty-build v 19 and netty-parent update. 2013-04-05 05:38:05 +09:00
Prajwal Tuladhar
05850da863 enable checkstyle for test source directory and fix checkstyle errors 2013-03-30 13:18:57 +01:00
Norman Maurer
59012390f6 Fix version numbering 2013-03-25 08:01:11 +01:00
Jeff Pinner
4e60c395a9 Fix SslHandler handshake timeout cancellation bug 2013-03-25 06:46:22 +01:00
Norman Maurer
7d7b676eeb [maven-release-plugin] prepare for next development iteration 2013-03-22 15:20:35 +01:00
Norman Maurer
60fc7dac4d [maven-release-plugin] prepare release netty-4.0.0.CR1 2013-03-22 15:20:11 +01:00
Trustin Lee
2a87950784 [maven-release-plugin] prepare for next development iteration 2013-03-16 18:41:36 +09:00
Trustin Lee
adfb29330b [maven-release-plugin] prepare release netty-4.0.0.Beta3 2013-03-16 18:40:59 +09:00
Norman Maurer
17ebbdec20 Let ChannelGroupFuture extends ChannelFuture and ChannelGroupFutureListener GenericFutureListener 2013-03-12 08:35:39 +01:00
Norman Maurer
806e9b1f8c Make sure we handle outbound messages of type ByteBuf special 2013-03-11 08:59:00 +09:00
Norman Maurer
fd3f923b52 Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
Trustin Lee
a9a29bdf3f Use I/O buffer whenever possible now that our direct buffers are as fast as heap buffers 2013-03-08 11:21:08 +09:00
Norman Maurer
88cc8c1739 [#1065] Provide Future/Promise without channel reference 2013-03-07 07:21:37 +01:00
Trustin Lee
0f8fbac9f8 Fix a problem in SslHandler where it doesn't work with TLS False Start
.. as suggested by @justinsb
2013-03-07 12:51:07 +09:00
Norman Maurer
42dad6d9d4 [#1106] Also handle FileRegion in ByteToByteEncoder and SslHandler 2013-02-28 19:40:34 +01:00
Trustin Lee
49aa907bd0 [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
Trustin Lee
5026c2f359 [maven-release-plugin] prepare release netty-4.0.0.Beta2 2013-02-26 16:54:53 -08:00
Trustin Lee
f67441354a Move logging classes from internal to internal.logging
.. because internal is crowded
2013-02-26 14:54:25 -08:00
Trustin Lee
d68a04a879 [maven-release-plugin] prepare for next development iteration 2013-02-14 12:56:24 -08:00
Trustin Lee
59e638f8f5 [maven-release-plugin] prepare release netty-4.0.0.Beta1 2013-02-14 12:56:15 -08:00
Trustin Lee
1011227b88 Remove apiviz tags - we are focusing on user guide instead and putting diagrams there 2013-02-14 12:09:16 -08:00
Norman Maurer
7cf7d7455d [#1048] Make sure the promise is not notified multiple times on failure 2013-02-12 20:46:39 +01:00
Trustin Lee
b4f4b95739 Move io.netty.logging to io.netty.internal / Move Signal out of internal because we use it in Channel*MessageAdapters 2013-02-11 20:08:18 +09:00
Trustin Lee
b9996908b1 Implement reference counting
- Related: #1029
- Replace Freeable with ReferenceCounted
- Add AbstractReferenceCounted
- Add AbstractReferenceCountedByteBuf
- Add AbstractDerivedByteBuf
- Add EmptyByteBuf
2013-02-10 13:10:09 +09:00
Trustin Lee
779870321c More precise close_notify handling 2013-02-09 18:41:00 +09:00
Trustin Lee
affd514b8c Rename ByteBufUtil to BufUtil and move ChannelHandlerUtil.freeMessage() there / Remove ChannelHandlerUtil 2013-02-08 23:23:26 +09:00
Trustin Lee
b4eaedf712 Remove confusing ChannelState/OperationHandlerAdapter.inboundBufferUpdated/flush() implementation 2013-02-08 17:17:39 +09:00
Trustin Lee
71136390f1 Extract type parameter finder code to a utility class 2013-02-08 15:57:23 +09:00
Norman Maurer
539418ecac Let ChannelPipeline.set* methods return itself to be more consistent with the reset 2013-02-08 07:24:55 +01:00
Trustin Lee
d4742bbe16 Clean up abstract ChannelHandler impls / Remove ChannelHandlerContext.hasNext*()
- Rename ChannelHandlerAdapter to ChannelDuplexHandler
- Add ChannelHandlerAdapter that implements only ChannelHandler
- Rename CombinedChannelHandler to CombinedChannelDuplexHandler and
  improve runtime validation
- Remove ChannelInbound/OutboundHandlerAdapter which are not useful
- Make ChannelOutboundByteHandlerAdapter similar to
  ChannelInboundByteHandlerAdapter
- Make the tail and head handler of DefaultChannelPipeline accept both
  bytes and messages.  ChannelHandlerContext.hasNext*() were removed
  because they always return true now.
- Removed various unnecessary null checks.
- Correct method/field names:
  inboundBufferSuspended -> channelReadSuspended
2013-02-07 23:47:45 +09:00
Norman Maurer
fd75615d7a [#870] Convert all modules into osgi bundles 2013-02-06 07:57:11 +01:00
Trustin Lee
2ec932798f Replace .readable() and .writable() to .isReadable() and .isWritable() 2013-01-31 18:24:33 +01:00
Trustin Lee
42c65cca3a Make MessageBuf bounded
- Move common methods from ByteBuf to Buf
- Rename ensureWritableBytes() to ensureWritable()
- Rename readable() to isReadable()
- Rename writable() to isWritable()
- Add isReadable(int) and isWritable(int)
- Add AbstractMessageBuf
- Rewrite DefaultMessageBuf and QueueBackedMessageBuf
  - based on Josh Bloch's public domain ArrayDeque impl
2013-01-31 18:11:06 +01:00
Norman Maurer
9da01417b2 [#973] Use static IdleStateEvents to reduce GC pressure 2013-01-23 17:34:27 +01:00
Trustin Lee
4472fe9795 Remove 'get' prefix 2013-01-17 15:06:46 +09:00
Trustin Lee
64ae8b6a37 Replace and merge DetectionUtil and DirectByteBufUtil into PlatformDependent and PlatformDependent0
PlatformDependent delegates the operations requires sun.misc.* to PlatformDependent0 to avoid runtime errors due to missing sun.misc.* classes.
2013-01-11 14:03:27 +09:00
Trustin Lee
eb337ff5a7 Fix various inspection warnings 2013-01-10 15:23:58 +09:00
Trustin Lee
dd6b7969b7 Give a handler more control over how its buffers' read bytes are discarded.
This pull request adds two new handler methods: discardInboundReadBytes(ctx) and discardOutboundReadBytes(ctx) to ChannelInboundByteHandler and ChannelOutboundByteHandler respectively. They are called between every inboundBufferUpdated() and flush() respectively. Their default implementation is to call discardSomeReadBytes() on their buffers and a user can override this behavior easily. For example, ReplayingDecoder.discardInboundReadBytes() looks like the following:

    @Override
    public void discardInboundReadBytes(ChannelHandlerContext ctx) throws Exception {
        ByteBuf in = ctx.inboundByteBuffer();
        final int oldReaderIndex = in.readerIndex();
        super.discardInboundReadBytes(ctx);
        final int newReaderIndex = in.readerIndex();
        checkpoint -= oldReaderIndex - newReaderIndex;
    }

If a handler, which has its own buffer index variable, extends ReplayingDecoder or ByteToMessageDecoder, the handler can also override discardInboundReadBytes() and adjust its index variable accordingly.
2013-01-09 13:34:09 +09:00
Trustin Lee
7d80182e51 Fix a bug where SslHandler does not respect the startTls flag
- Fixes #856
- Add a dedicated test case: SocketStartTlsTest
2013-01-01 15:03:37 +09:00
Norman Maurer
e0a6dc0ac3 Remove ChannelFutureProgressListener 2012-12-31 23:27:37 +09:00
Norman Maurer
4e77bacdf7 [#873] [#868] Split ChannelFuture into ChannelFuture and ChannelPromise 2012-12-31 23:27:16 +09:00
Trustin Lee
0909878581 Read only when requested (read-on-demand)
This pull request introduces a new operation called read() that replaces the existing inbound traffic control method. EventLoop now performs socket reads only when the read() operation has been issued. Once the requested read() operation is actually performed, EventLoop triggers an inboundBufferSuspended event that tells the handlers that the requested read() operation has been performed and the inbound traffic has been suspended again. A handler can decide to continue reading or not.

Unlike other outbound operations, read() does not use ChannelFuture at all to avoid GC cost. If there's a good reason to create a new future per read at the GC cost, I'll change this.

This pull request consequently removes the readable property in ChannelHandlerContext, which means how the traffic control works changed significantly.

This pull request also adds a new configuration property ChannelOption.AUTO_READ whose default value is true. If true, Netty will call ctx.read() for you. If you need a close control over when read() is called, you can set it to false.

Another interesting fact is that non-terminal handlers do not really need to call read() at all. Only the last inbound handler will have to call it, and that's just enough. Actually, you don't even need to call it at the last handler in most cases because of the ChannelOption.AUTO_READ mentioned above.

There's no serious backward compatibility issue. If the compiler complains your handler does not implement the read() method, add the following:

public void read(ChannelHandlerContext ctx) throws Exception {
    ctx.read();
}

Note that this pull request certainly makes bounded inbound buffer support very easy, but itself does not add the bounded inbound buffer support.
2012-12-31 23:26:00 +09:00
Norman Maurer
926a20f105 [#880] correctly use methods which take a ChannelFuture as parameter 2012-12-31 11:43:05 +01:00
Luke Wood
5adb37de3d Port traffic handler to netty 4 2012-12-26 21:54:40 +01:00
Norman Maurer
8a7bc2c606 Add a lot of javadocs to make usage more clear 2012-12-21 22:22:40 +01:00
Norman Maurer
42a77eda9b And again javadocs cleanup 2012-12-21 07:35:42 +01:00
Norman Maurer
d2060ee3f1 Add more javadocs 2012-12-20 15:45:49 +01:00
Norman Maurer
a1baeeb8c0 Mark IdleStateEvent as final and add javadocs 2012-12-20 15:45:35 +01:00
Norman Maurer
1f9d165583 [#836] Correctly reset timeout on sendFile(...) 2012-12-19 21:16:41 +01:00
Norman Maurer
695665a4cf More javadocs fixes 2012-12-19 21:08:47 +01:00
Norman Maurer
db0459ea9c Fix javadocs of IdleStateHandler 2012-12-19 16:25:31 +01:00
Norman Maurer
d9b26dab29 Remove get*() from the methods to match the rest of our method signatures 2012-12-19 15:38:17 +01:00
Norman Maurer
a1368f0fa8 Some javadocs fixed to remove dead links 2012-12-19 15:36:07 +01:00
Norman Maurer
77c01d252e Fix visibily of ImmediateExecutor and add private constructor 2012-12-19 15:31:07 +01:00
Norman Maurer
11047aaa69 [#832] Add javadocs which explains how to workaround the problem 2012-12-19 15:17:10 +01:00
Trustin Lee
def12a171c Rename ChannelBuf to Buf and ChannelBufType to BufType
- Fixes #825
2012-12-17 17:43:45 +09:00
Trustin Lee
03e68482bb Remove ChannelBuf/ByteBuf.Unsafe
- Fixes #826
Unsafe.isFreed(), free(), suspend/resumeIntermediaryAllocations() are not that dangerous. internalNioBuffer() and internalNioBuffers() are dangerous but it seems like nobody is using it even inside Netty. Removing those two methods also removes the necessity to keep Unsafe interface at all.
2012-12-17 17:41:21 +09:00
Trustin Lee
ad10518fca Fix the incorrect snapshot version number 2012-12-13 22:49:31 +09:00
Trustin Lee
51e6519b67 Replace UnsafeByteBuf with ByteBuf.unsafe() again
* UnsafeByteBuf is gone. I added ByteBuf.unsafe() back.
* To avoid extra instantiation, all ByteBuf implementations implement the ByteBuf.Unsafe interface.
* To hide this implementation detail, all ByteBuf implementations are package-private.
* AbstractByteBuf and SwappedByteBuf are public and they do not implement ByteBuf.Unsafe because they don't need to.
* unwrap() is not an unsafe operation anymore.
* ChannelBuf also has unsafe() and Unsafe. ByteBuf.Unsafe extends ChannelBuf.unsafe(). ChannelBuf.unsafe() provides free() operation so that a user does not need to down-cast the buffer in freeInbound/OutboundBuffer().
2012-12-05 19:28:56 +09:00
Norman Maurer
85c570505b [maven-release-plugin] prepare for next development iteration 2012-12-03 20:34:05 +01:00
Norman Maurer
17d77ed160 [maven-release-plugin] prepare release netty-4.0.0.Alpha8 2012-12-03 20:33:49 +01:00
Trustin Lee
33c0c89fef Remove unnecessary empty lines 2012-12-03 19:58:13 +09:00
Trustin Lee
6208c62888 Fix inspector warnings introduced by recent mergences 2012-11-30 23:01:57 +09:00
Trustin Lee
81e2db10fa ByteBufAllocator API w/ ByteBuf perf improvements
This commit introduces a new API for ByteBuf allocation which fixes
issue #643 along with refactoring of ByteBuf for simplicity and better
performance. (see #62)

A user can configure the ByteBufAllocator of a Channel via
ChannelOption.ALLOCATOR or ChannelConfig.get/setAllocator().  The
default allocator is currently UnpooledByteBufAllocator.HEAP_BY_DEFAULT.

To allocate a buffer, do not use Unpooled anymore. do the following:

  ctx.alloc().buffer(...); // allocator chooses the buffer type.
  ctx.alloc().heapBuffer(...);
  ctx.alloc().directBuffer(...);

To deallocate a buffer, use the unsafe free() operation:

  ((UnsafeByteBuf) buf).free();

The following is the list of the relevant changes:

- Add ChannelInboundHandler.freeInboundBuffer() and
  ChannelOutboundHandler.freeOutboundBuffer() to let a user free the
  buffer he or she allocated. ChannelHandler adapter classes implement
  is already, so most users won't need to call free() by themselves.
  freeIn/OutboundBuffer() methods are invoked when a Channel is closed
  and deregistered.

- All ByteBuf by contract must implement UnsafeByteBuf. To access an
  unsafe operation: ((UnsafeByteBuf) buf).internalNioBuffer()

- Replace WrappedByteBuf and ByteBuf.Unsafe with UnsafeByteBuf to
  simplify overall class hierarchy and to avoid unnecesary instantiation
  of Unsafe instances on an unsafe operation.

- Remove buffer reference counting which is confusing

- Instantiate SwappedByteBuf lazily to avoid instantiation cost

- Rename ChannelFutureFactory to ChannelPropertyAccess and move common
  methods between Channel and ChannelHandlerContext there. Also made it
  package-private to hide it from a user.

- Remove unused unsafe operations such as newBuffer()

- Add DetectionUtil.canFreeDirectBuffer() so that an allocator decides
  which buffer type to use safely
2012-11-22 15:10:59 +09:00
dantran
4107b08f29 Only generate OSGi manifest only at all-in-on sub module to reduce the complexity to the build 2012-11-19 06:27:18 +01:00
dantran
105f952f5d Clean up maven-bungle-plugin warnings 2012-11-12 11:42:42 +01:00
dantran
e236f5b77d [#154] [#727] Use maven-plugin-plugin to generate OSGi manifest 2012-11-12 09:15:36 +01:00
Trustin Lee
6f2840193a Fix inspection warnings related with JUnit usage 2012-11-12 12:45:06 +09:00
Trustin Lee
ea4a0e3535 Prefer {@code ...} to <code>...</code> / Fix deprecation warnings 2012-11-12 11:51:23 +09:00
Trustin Lee
a07fb94fe7 Prefer "str".equals(var) to var.equals("str") / Add proper null checks 2012-11-12 08:59:54 +09:00
Norman Maurer
313f777491 [maven-release-plugin] prepare for next development iteration 2012-11-05 23:08:39 +01:00
Norman Maurer
57da8222a4 [maven-release-plugin] prepare release netty-4.0.0.Alpha7 2012-11-05 23:08:28 +01:00
Trustin Lee
86b777a919 [#710] flush() requests made before SSL handshake completion are not executed after completion
- Ensure SslHandler flushes its outbound buffer on handshake completion
- Enable SSL in HttpSnoopClient example
2012-11-05 16:37:40 +09:00
Norman Maurer
87cc67306f [maven-release-plugin] prepare for next development iteration 2012-10-28 18:41:25 +01:00
Norman Maurer
7315490fca [maven-release-plugin] prepare release netty-4.0.0.Alpha6 2012-10-28 18:41:17 +01:00
Norman Maurer
afc687436a Revert "[maven-release-plugin] prepare release netty-4.0.0.Alpha6"
This reverts commit 95de4db0f1.
2012-10-28 18:36:15 +01:00
Norman Maurer
16eb4ec713 Revert "[maven-release-plugin] prepare for next development iteration"
This reverts commit e3e0776c20.
2012-10-28 18:35:47 +01:00
Norman Maurer
e3e0776c20 [maven-release-plugin] prepare for next development iteration 2012-10-28 13:06:07 +01:00
Norman Maurer
95de4db0f1 [maven-release-plugin] prepare release netty-4.0.0.Alpha6 2012-10-28 13:05:59 +01:00
Norman Maurer
fb6ce4989a Javadoc fixes 2012-10-26 22:38:06 +02:00
Trustin Lee
951c49f449 [#644] SslHandler should not defer channelActive event
- otherwise a user will have a misconception about the life cycle of the actual connection.
2012-10-16 15:19:34 -07:00
Norman Maurer
9e6c616c35 Introduce helper method to detect if a buffer is encrypted. See #657 2012-10-16 13:44:30 +02:00
Norman Maurer
d504d78cb1 Fix checkstyle 2012-10-13 09:21:40 +02:00
ab
ce88ae3889 Ensure that either SslHandler's handshake timeout or the handshake
itself (or its failure) take place but not both.
2012-10-10 14:16:13 +02:00
Trustin Lee
820af50b63 [maven-release-plugin] prepare for next development iteration 2012-09-28 17:57:40 +09:00
Trustin Lee
595e1067c7 [maven-release-plugin] prepare release netty-4.0.0.Alpha5 2012-09-28 17:57:04 +09:00
Trustin Lee
7514a82c35 Disable timeouts if they are set to 0 2012-09-28 13:52:05 +09:00
Trustin Lee
817309c7c8 Remove magic numbers from SslHandler 2012-09-27 19:28:41 +09:00
norman
3295145e88 [maven-release-plugin] prepare for next development iteration 2012-09-13 10:40:52 +02:00
norman
42685759de [maven-release-plugin] prepare release netty-4.0.0.Alpha4 2012-09-13 10:40:44 +02:00
Trustin Lee
f2538a996d [maven-release-plugin] prepare for next development iteration 2012-08-30 16:47:52 +09:00
Trustin Lee
628c5598b3 [maven-release-plugin] prepare release netty-4.0.0.Alpha3 2012-08-30 16:46:58 +09:00
Trustin Lee
a3f25da228 Remove unused parameter 2012-08-29 12:28:01 +09:00
norman
3aaf7cf82b [#160] Make sure the exception is fired before the channel gets closed 2012-08-22 07:56:39 +02:00
Trustin Lee
00188a2923 [#160] No response to write if server is using SslHandler and client is not
- Make SslHandler close the connection on SSLException or NotSslRecordException
2012-08-22 13:38:09 +09:00