Permalink
Switch branches/tags
netty-5.0.0.Alpha1 netty-4.1.0.Beta3 netty-4.1.0.Beta2 netty-4.1.0.Beta1 netty-4.0.23.Final netty-4.0.22.Final netty-4.0.21.Final netty-4.0.20.Final netty-4.0.19.Final netty-4.0.18.Final netty-4.0.17.Final netty-4.0.16.Final netty-4.0.15.Final netty-4.0.14.Final netty-4.0.14.Beta1 netty-4.0.13.Final netty-4.0.12.Final netty-4.0.11.Final netty-4.0.10.Final netty-4.0.9.Final netty-4.0.8.Final netty-4.0.7.Final netty-4.0.6.Final netty-4.0.5.Final netty-4.0.4.Final netty-4.0.3.Final netty-4.0.2.Final netty-4.0.1.Final netty-4.0.0.Final netty-4.0.0.CR9 netty-4.0.0.CR8 netty-4.0.0.CR7 netty-4.0.0.CR6 netty-4.0.0.CR5 netty-4.0.0.CR4 netty-4.0.0.CR3 netty-4.0.0.CR2 netty-4.0.0.CR1 netty-4.0.0.Beta3 netty-4.0.0.Beta2 netty-4.0.0.Beta1 netty-4.0.0.Alpha8 netty-4.0.0.Alpha7 netty-4.0.0.Alpha6 netty-4.0.0.Alpha5 netty-4.0.0.Alpha4 netty-4.0.0.Alpha3 netty-4.0.0.Alpha2 netty-4.0.0.Alpha1 netty-3.9.4.Final netty-3.9.3.Final netty-3.9.2.Final netty-3.9.1.1.Final netty-3.9.1.Final netty-3.9.0.Final netty-3.8.2.Final netty-3.8.1.Final netty-3.8.0.Final netty-3.7.1.Final netty-3.7.0.Final netty-3.6.10.Final netty-3.6.9.Final netty-3.6.8.Final netty-3.6.7.Final netty-3.6.6.Final netty-3.6.5.Final netty-3.6.4.Final netty-3.6.3.Final netty-3.6.2.Final netty-3.6.1.Final netty-3.6.0.Final netty-3.6.0.Beta1 netty-3.5.13.Final netty-3.5.12.Final netty-3.5.11.Final netty-3.5.10.Final netty-3.5.9.Final netty-3.5.8.Final netty-3.5.7.Final netty-3.5.6.Final netty-3.5.5.Final netty-3.5.4.Final netty-3.5.3.Final netty-3.5.2.Final netty-3.5.1.Final netty-3.5.0.Final netty-3.5.0.Beta1 netty-3.4.6.Final netty-3.4.5.Final netty-3.4.4.Final netty-3.4.3.Final netty-3.4.2.Final netty-3.4.1.Final netty-3.4.0.Final netty-3.4.0.Beta1 netty-3.4.0.Alpha2 netty-3.4.0.Alpha1 netty-3.3.1.Final netty-3.3.0.Final netty-3.2.10.Final
Nothing to show
Commits on Oct 17, 2014
  1. Fix another resource leak in DnsNameResolver

    trustin committed Oct 17, 2014
    - Fix a bug in cache expiration task; wrong object was being released
    - Added more sanity checks when caching an entry
Commits on Oct 16, 2014
  1. Upgrading HTTP/2 hpack to latest version

    nmittler committed Oct 16, 2014
    Motivation:
    
    Twitter hpack has upgraded to 0.9.1, we should upgrade to the latest.
    
    Modifications:
    
    Updated the parent pom to specify the dependency version. Updated the
    http2 pom to use the version specified by the parent.
    
    Result:
    
    HTTP/2 updated to the latest hpack release.
  2. Fix test failures in ProxyHandlerTest

    trustin committed Oct 14, 2014
    Motivation:
    
    The default name resolver attempts to resolve the bad host name (destination.com) and actually succeeds, making the ProxyHandlerTest fail.
    
    Modification:
    
    Use NoopNameResolverGroup instead.
    
    Result:
    
    ProxyHandlerTest passes again.
  3. Name resolver API and DNS-based name resolver

    trustin committed Sep 19, 2014
    Motivation:
    
    So far, we relied on the domain name resolution mechanism provided by
    JDK.  It served its purpose very well, but had the following
    shortcomings:
    
    - Domain name resolution is performed in a blocking manner.
      This becomes a problem when a user has to connect to thousands of
      different hosts. e.g. web crawlers
    - It is impossible to employ an alternative cache/retry policy.
      e.g. lower/upper bound in TTL, round-robin
    - It is impossible to employ an alternative name resolution mechanism.
      e.g. Zookeeper-based name resolver
    
    Modification:
    
    - Add the resolver API in the new module: netty-resolver
    - Implement the DNS-based resolver: netty-resolver-dns
      .. which uses netty-codec-dns
    - Make ChannelFactory reusable because it's now used by
      io.netty.bootstrap, io.netty.resolver.dns, and potentially by other
      modules in the future
      - Move ChannelFactory from io.netty.bootstrap to io.netty.channel
      - Deprecate the old ChannelFactory
      - Add ReflectiveChannelFactory
    
    Result:
    
    It is trivial to resolve a large number of domain names asynchronously.
  4. Add EDNS support to DnsQueryEncoder

    trustin committed Oct 7, 2014
    Motivation:
    
    DnsQueryEncoder does not encode the 'additional resources' section at all, which contains the pseudo-RR as defined in RFC 2671.
    
    Modifications:
    
    - Modify DnsQueryEncoder to encode the additional resources
    - Fix a bug in DnsQueryEncoder where an empty name is encoded incorrectly
    
    Result:
    
    A user can send an EDNS query.
  5. Do not consider PortUnreachableException to require channel closure

    trustin committed Sep 23, 2014
    Motivation:
    
    When a datagram packet is sent to a destination where nobody actually listens to,
    the server O/S will respond with an ICMP Port Unreachable packet.
    The ICMP Port Unreachable packet is translated into PortUnreachableException by JDK.
    PortUnreachableException is not a harmful exception that prevents a user from sending a datagram.
    Therefore, we should not close a datagram channel when PortUnreachableException is caught.
    
    Modifications:
    
    - Do not close a channel when the caught exception is PortUnreachableException.
    
    Result:
    
    A datagram channel is not closed unexpectedly anymore.
Commits on Oct 14, 2014
  1. Finish porting netty-proxy module

    trustin committed Oct 14, 2014
    - Fix problems introduced by de9c81b
    - Fix inspector warnings
  2. Add proxy support for client socket connections

    trustin committed Aug 25, 2014
    Related issue: #1133
    
    Motivation:
    
    There is no support for client socket connections via a proxy server in
    Netty.
    
    Modifications:
    
    - Add a new module 'handler-proxy'
    - Add ProxyHandler and its subclasses to support SOCKS 4a/5 and HTTP(S)
      proxy connections
    - Add a full parameterized test for most scenarios
    - Clean up pom.xml
    
    Result:
    
    A user can make an outgoing connection via proxy servers with only
    trivial effort.
  3. Add AbstractUnsafe.annotateConnectException()

    trustin committed Sep 16, 2014
    Motivation:
    
    JDK's exception messages triggered by a connection attempt failure do
    not contain the related remote address in its message.  We currently
    append the remote address to ConnectException's message, but I found
    that we need to cover more exception types such as SocketException.
    
    Modifications:
    
    - Add AbstractUnsafe.annotateConnectException() to de-duplicate the
      code that appends the remote address
    
    Result:
    
    - Less duplication
    - A transport implementor can annotate connection attempt failure
      message more easily
  4. Fix an incorrect use of ByteBuf.array() in Socks5CmdRequestDecoder

    trustin committed Sep 16, 2014
    Motivation:
    
    Socks5CmdRequestDecoder uses ByteBuf.array() naively assuming that the
    array's base offset is always 0, which is not the case.
    
    Modification:
    
    - Allocate a new byte array and copy the content there instead
    
    Result:
    
    Another bug fixed
  5. Fix a bug in NetUtil.createByteArrayFromIpAddressString()

    trustin committed Sep 16, 2014
    Motivation:
    
    An IPv6 string can have a zone index which is followed by the '%' sign.
    When a user passes an IPv6 string with a zone index,
    NetUtil.createByteArrayFromIpAddressString() returns an incorrect value.
    
    Modification:
    
    - Strip the zone index before conversion
    
    Result:
    
    An IPv6 string with a zone index is decoded correctly.
  6. Auto-generate the handler name when null is specified as a name

    trustin committed Sep 16, 2014
    Motivation:
    
    There's no way to generate the name of a handler being newly added
    automatically and reliably.
    
    For example, let's say you have a routine that adds a set of handlers to
    a pipeline using addBefore() or addAfter().  Because addBefore() and
    addAfter() always require non-conflicting non-null handler name, making
    the multiple invocation of the routine on the same pipeline is
    non-trivial.
    
    Modifications:
    
    - If a user specifies null as the name of the new handler,
      DefaultChannelPipeline generates one.
    - Update the documentation of ChannelPipeline to match the new behavior
    
    Result:
    
    A user doesn't need to worry about name conflicts anymore.
  7. Add the encoder/decoder getter methods to HttpClientCodec

    trustin committed Sep 16, 2014
    Motivation:
    
    There's no way for a user to get the encoder and the decoder of an
    HttpClientCodec.  The lack of such getter methods makes it impossible to
    remove the codec handlers from the pipeline correctly.
    
    For example, a user could add more than one HttpClientCodec to the
    pipeline, and then the user cannot easily decide which encoder and
    decoder to remove.
    
    Modifications:
    
    - Add encoder() and decoder() method to HttpClientCodec which returns
      HttpRequestEncoder and HttpResponseDecoder respectively
    - Also made the same changes to HttpServerCodec
    
    Result:
    
    A user can distinguish the handlers added by multiple HttpClientCodecs
    easily.
Commits on Oct 13, 2014
  1. Access autoRead via an AtomicIntegerFieldUpdater.

    lw346 committed with normanmaurer Oct 9, 2014
    Motiviation:
    
    Before this change, autoRead was a volatile boolean accessed directly.  Any thread that invoked the DefaultChannelConfig#setAutoRead(boolean) method would read the current value of autoRead, and then set a new value.  If the old value did not match the new value, some action would be immediately taken as part of the same method call.
    
    As volatile only provides happens-before consistency, there was no guarantee that the calling thread was actually the thread mutating the state of the autoRead variable (such that it should be the one to invoke the follow-up actions).  For example, with 3 threads:
     * Thread 1: get = false
     * Thread 1: set = true
     * Thread 1: invokes read()
     * Thread 2: get = true
     * Thread 3: get = true
     * Thread 2: set = false
     * Thread 2: invokes autoReadCleared()
     * Event Loop receives notification from the Selector that data is available, but as autoRead has been cleared, cancels the operation and removes read interest
     * Thread 3: set = true
    
    This results in a livelock - autoRead is set true, but no reads will happen even if data is available (as readyOps).  The only way around this livelock currently is to set autoRead to false, and then back to true.
    
    Modifications:
    
    Write access to the autoRead variable is now made using the getAndSet() method of an AtomicIntegerFieldUpdater, AUTOREAD_UPDATER.  This also changed the type of the underlying autoRead variable to be an integer, as no AtomicBooleanFieldUpdater class exists.  Boolean logic is retained by assuming that 1 is true and 0 is false.
    
    Result:
    
    There is no longer a race condition between retrieving the old value of the autoRead variable and setting a new value.
  2. HTTP/2 Server Example Not Using Flow Controller

    Scottmitch committed with normanmaurer Oct 10, 2014
    Motiviation:
    The HTTP/2 server example is not using the outbound flow control.  It is instead using a FrameWriter directly.
    This can lead to flow control errors and other comm. related errors
    
    Modifications:
    -Force server example to use outbound flow controller
    
    Result:
    -Server example should use follow flow control rules.
  3. Fixing race condition in HTTP/2 test

    nmittler committed with normanmaurer Oct 9, 2014
    Motivation:
    
    InboundHttp2ToHttpAdapterTest swaps non-volatile CountDownLatches in
    handlers, which seems to cause a race condition that can lead to missing
    messages.
    
    Modifications:
    
    Make CountDownLatch variables in InboundHttp2ToHttpAdapterTest volatile.
    
    Result:
    
    InboundHttp2ToHttpAdapterTest should be more stable.
  4. Cleaning up GOAWAY methods.

    nmittler committed with normanmaurer Oct 9, 2014
    Motivation:
    
    The current GOAWAY methods are in each endpoint and are a little
    confusing since their called connection.<endpoint>.goAwayReceived().
    
    Modifications:
    
    Moving GOAWAY methods to connection with more clear names
    goAwaySent/goAwayReceived.
    
    Result:
    
    The GOAWAY method names are more clear.
  5. Add verification for websocket subprotocol on the client side.

    Matthias247 committed with normanmaurer Sep 26, 2014
    Motivation:
    
    Websocket clients can request to speak a specific subprotocol. The list of
    subprotocols the client understands are sent to the server. The server
    should select one of the protocols an reply this with the websocket
    handshake response. The added code verifies that the reponded subprotocol
    is valid.
    
    Modifications:
    
    Added verification of the subprotocol received from the server against the
    subprotocol(s) that the user requests. If the user requests a subprotocol
    but the server responds none or a non-requested subprotocol this is an
    error and the handshake fails through an exception. If the user requests
    no subprotocol but the server responds one this is also marked as an
    error.
    
    Addiontionally a getter for the WebSocketClientHandshaker in the
    WebSocketClientProtocolHandler is added to enable the user of a
    WebSocketClientProtocolHandler to extract the used negotiated subprotocol.
    
    Result:
    
    The subprotocol field which is received from a websocket server is now
    properly verified on client side and clients and websocket connection
    attempts will now only succeed if both parties can negotiate on a
    subprotocol.
    If the client sends a list of multiple possible subprotocols it can
    extract the negotiated subprotocol through the added handshaker getter (WebSocketClientProtocolHandler.handshaker().actualSubprotocol()).
  6. Add exceptions for CONNACK's return code for MQTT 3.1 specification

    jongyeol committed with normanmaurer Oct 8, 2014
    Motivation:
    
    http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connack
    In MQTT 3.1, MQTT server must send a CONNACK with return code if CONNECT
    request contains an invalid client identifier or an unacceptable protocol
    version. The return code is one of MqttConnectReturnCode.
    But, MqttDecoder throws DecoderException when CONNECT request contains
    invalid value without distinguish situations. This makes it difficult
    for codec-mqtt users to send a response with return code to clients.
    
    Modifications:
    
    Added exceptions for client identifier rejected and unacceptable
    protocol version. MqttDecoder will throw those exceptions instead of
    DecoderException.
    
    Result:
    
    Users of codec-mqtt can distinguish which is invalid when CONNECT
    contains invalid client identifier or invalid protocol version. And, users can
    send CONNACK with return code to clients.
  7. Add a test for handover from HTTP to Websocket

    Matthias247 committed with normanmaurer Oct 6, 2014
    Motivation:
    I was not fully reassured that whether everything works correctly when a websocket client receives the websocket handshake HTTP response and a websocket frame in a single ByteBuf (which can happen when the server sends a response directly or shortly after the connect). In this case some parts of the ByteBuf must be processed by HTTP decoder and the remaining by the websocket decoder.
    
    Modification:
    Adding a test that verifies that in this scenaria the handshake and the message are correctly interpreted and delivered by Netty.
    
    Result:
    One more test for Netty.
    The test succeeds - No problems
  8. Change client id validation range in codec-mqtt

    jongyeol committed with normanmaurer Oct 10, 2014
    Motivation:
    
    In MQTT 3.1 specification, "The Client Identifier (Client ID) is between
    1 and 23 characters long, and uniquely identifies the client to the
    server". But, current client id validation length is 0~23. It must be
    1~23. The empty string is invalid client id in MQTT 3.1
    
    Modifications:
    
    Change isValidClientId method. Add MIN_CLIENT_ID_LENGTH.
    
    Result:
    
    The validation check for client id length is between 1 and 23.
  9. Adding a benchmark for websockets

    Matthias247 committed with normanmaurer Oct 1, 2014
    Motivation:
    
    It is often helpful to measure the performance of connections, e.g. the
    latency and the throughput. This can be performed through benchmarks.
    
    Modification:
    
    This adds a simple but configurable benchmark for websockets into the
    example directory. The Netty WebSocket server will echo all received
    websocket frames and will provide an HTML/JS page which serves as the
    client for the benchmark.
    The benchmark also provides a verification mode that verifies the sent
    against the received data. This can be used for the verification ob
    websocket frame encoding and decoding funtionality.
    
    Result:
    
    A benchmark is added in form a further Netty websocket example.
    With this benchmark it is easily possible to measure the performance between Netty and a browser
Commits on Oct 12, 2014
  1. Fix the leak in the WebSocketClientProtocolHandshakeHandler

    Matthias247 committed with normanmaurer Oct 6, 2014
    Motivation:
    The WebSocketClientProtocolHandshakeHandler never releases the received handshake response.
    
    Modification:
    Release the message in a finally block.
    
    Result:
    No more leak
  2. Avoid vectored writes for small websocket messages

    Matthias247 committed with normanmaurer Oct 3, 2014
    Motivation:
    The WebSocket08FrameEncoder contains an optimization path for small messages which copies the message content into the header buffer to avoid vectored writes. However this path is in the current implementation never taken because the target buffer is preallocated only for exactly the size of the header.
    
    Modification:
    For messages below a certain treshold allocate the buffer so that the message can be directly copied. Thereby the optimized path is taken.
    
    Result:
    A speedup of about 25% for 100byte messages. Declines with bigger message sizes. I have currently set the treshold to 1kB which is a point where I could still see a few percent speedup, but we should also avoid burning too many CPU cycles.
  3. Improve WebSocket performance

    Matthias247 committed with normanmaurer Oct 1, 2014
    Motivation:
    
    Websocket performance is to a large account determined through the masking
    and unmasking of frames. The current behavior of this in Netty can be
    improved.
    
    Modifications:
    
    Perform the XOR operation not bytewise but in int blocks as long as
    possible. This reduces the number of necessary operations by 4. Also don't
    read the writerIndex in each iteration.
    Added a unit test for websocket decoding and encoding for verifiation.
    
    Result:
    
    A large performance gain (up to 50%) in websocket throughput.
Commits on Oct 9, 2014
  1. NullPointerException fix in http/2 codec

    Scottmitch committed Oct 9, 2014
    Motivation:
    There is a NPE due to the order of builder initialization in the  class.
    
    Modifications:
    -Correct the ordering of initialization and building to avoid NPE.
    
    Result:
    No more NPE in  construction.
  2. Restoring access to HTTP/2 decoder's listener.

    nmittler committed Oct 9, 2014
    Motivation:
    
    This was lost in recent changes, just adding it back in.
    
    Modifications:
    
    Added listener() accessor to Http2ConnectionDecoder and the default
    impl.
    
    Result:
    
    The Http2FrameListener can be obtained from the decoder.
  3. Simplifying and centralizing HTTP/2 exception handling logic

    nmittler committed Oct 8, 2014
    Motivation:
    
    Currently, Http2LifecycleManager implements the exception handling logic
    which makes it difficult to extend or modify the exception handling
    behavior.  Simply overriding exceptionCaught() will only affect one of
    the many possible exception paths. We need to reorganize the exception
    handling code to centralize the exception handling logic into a single
    place that can easily be extended by subclasses of
    Http2ConnectionHandler.
    
    Modifications:
    
    Made Http2LifecycleManager an interface, implemented directly by
    Http2ConnectionHandler. This adds a circular dependency between the
    handler and the encoder/decoder, so I added builders for them that allow
    the constructor of Http2ConnectionHandler to set itself as the lifecycle
    manager and build them.
    
    Changed Http2LifecycleManager.onHttpException to just
    onException(Throwable) to simplify the interface. This method is now the
    central control point for all exceptions. Subclasses now only need to
    override onException() to intercept any exception encountered by the
    handler.
    
    Result:
    
    HTTP/2 has more extensible exception handling, that is less likely to
    see exceptions vanish into the ether.
Commits on Oct 5, 2014
  1. Fixing concurrency issue with HTTP/2 test mocking

    nmittler committed Oct 4, 2014
    Motivation:
    
    Some tests occasionally appear unstable, throwing a
    org.mockito.exceptions.misusing.UnfinishedStubbingException. Mockito
    stubbing does not work properly in multi-threaded environments, so any
    stubbing has to be done before the threads are started.
    
    Modifications:
    
    Modified tests to perform any custom stubbing before the client/server
    bootstrap logic executes.
    
    Result:
    
    HTTP/2 tests should be more stable.
Commits on Oct 3, 2014
  1. Fix Http/2 example response timeout

    nmittler committed Oct 3, 2014
    Motivation:
    
    The HTTP/2 example can timeout at the client waiting for a response due
    to the server not flushing after writing the response.
    
    Modifications:
    
    Updated the server's HelloWorldHttp2Handler to flush after writing the
    response.
    
    Result:
    
    The HTTP/2 example runs successfully.
Commits on Oct 2, 2014
  1. Adding missing asserts to HTTP/2 tests

    nmittler committed Oct 2, 2014
    Motivation:
    
    Some tests do not properly assert that all requests have been
    sent/received, so the failures messages may be misleading.
    
    Modifications:
    
    Adding missing asserts to HTTP/2 tests for awaiting requests and
    responses.
    
    Result:
    
    HTTP/2 tests properly assert message counts.
  2. HTTP/2 unit test missed syncrhonized collection

    Scottmitch committed Oct 2, 2014
    Motiviation:
    PR netty#2948 missed a collection to synchronize in the HTTP/2 unit tests.
    
    Modifications:
    synchronize the collection that was missed
    
    Result:
    Missed collection is syncronized and initial size is corrected
Commits on Oct 1, 2014
  1. Motivation:

    nmittler committed Oct 1, 2014
    The HTTP/2 tests have been unstable, in particular the
    Http2ConnectionRoundtripTest.
    
    Modifications:
    
    Modified fields in Http2TestUtil to be volatile.
    
    Result:
    
    Tests should (hopefully) be more stable.