Commits on Jul 19, 2016
  1. @alandau

    Let transport know that TApplicationException is about to be sent

    Useful if the transport needs to do something special before sending
    those
    alandau committed Jul 18, 2016
Commits on Jul 7, 2016
  1. @andrewcox
  2. @andrewcox
  3. @andrewcox
Commits on Jun 29, 2016
  1. @siyengar

    Add support to set ssl version

    siyengar committed Jun 25, 2016
Commits on Jun 15, 2016
  1. @siyengar

    Rename class names to fit naming convention

    Summary:
    This also changes code style as well
    
    Test Plan:
    Run tests
    siyengar committed Jun 15, 2016
  2. @siyengar

    Add config updater

    Summary:
    Add support for config updater which
    will update ssl configs on the transportt
    dynamically
    
    Test Plan:
    Unit tests
    siyengar committed Jun 12, 2016
  3. @siyengar

    Add support for session tickets

    Summary:
    Adds support for session tickets and ticket
    rotation of session tickets.
    
    Tickets can be rotated by updating the sslserverconfig
    on the netty server.
    
    This also moves SSL context initialization into the
    constructors of the SSLServerConfig and clientConfig. This
    will prevent us from performing IO during normal operations
    and only once during initialization.
    
    Test Plan:
    Wrote a unit test to test resumption and updation.
    However the netty client only supports stateful resumption.
    
    Also tested with openssl ticket resumption locally, works great.
    siyengar committed Jun 12, 2016
  4. @siyengar
  5. @siyengar

    Add ssl support to nifty

    siyengar committed Jun 10, 2016
Commits on Jun 2, 2016
  1. @andrewcox
  2. @andrewcox
Commits on Jun 1, 2016
  1. @tageorgiou
Commits on Mar 16, 2016
  1. @faisal-hameed
Commits on Jan 31, 2016
  1. @andrewcox
  2. @andrewcox
Commits on Jan 6, 2016
  1. @andrewcox
Commits on Jan 4, 2016
  1. @andrewcox
  2. @andrewcox
Commits on Dec 30, 2015
  1. @andrewcox
  2. @andrewcox
Commits on Dec 29, 2015
  1. @andrewcox
  2. @andrewcox
  3. @andrewcox
  4. @andrewcox
  5. @andrewcox
  6. @andrewcox
  7. @andrewcox
  8. @andrewcox
Commits on Nov 19, 2015
  1. @andrewcox
  2. @andrewcox
  3. @andrewcox
Commits on Nov 18, 2015
  1. @andrewcox

    Fix read-blocking in server dispatcher

    The intent was to block reads on channels where the client required ordered responses, to prevent the server caching an unlimited number of responses while waiting for some response that needs to be sent before the others. But the code was actually sometimes blocking reads on out-of-order-aware channels, which was a problem because the unblocking code was only operating for order-required channels.
    andrewcox committed Nov 18, 2015
Commits on Jul 27, 2015
  1. @alandau

    Add TNiftyTransport.setOutputBuffer()

    This can be used by transports wrapping TNiftyTransport to avoid data
    copies.
    alandau committed Jul 27, 2015
  2. @jesboat

    Don't use Netty's ChannelLocal for ConnectionContexts

    ChannelLocal has two modes. In one we were using, the value for a
    Channel is cleared when the Channel is closed. This is a problem,
    because if a client drops a connection after sending a full request but
    before NiftyDispatcher processes a request (e.g. if the Executor given
    to NiftyDispatcher takes a long time to begin the task and the client
    times out), the ConnectionContext will have been discarded. The
    ChanneLocal will make a new ConnectionContext when NiftyProcessor tries
    to access it, and that new context will be missing information like the
    remote address. This, in turn, leads to the infamous "impossible
    exception".
    
    The alternative mode for ChannelLocal is to keep values around until the
    Channels get GC'd (using a WeakHashMap). Using this would solve the
    problem above, but still has the confusing behavior with object
    lifetimes (a ConnectionContext comes into existence magically for any
    Channel and may or may not be fully initialized at time of use.)
    
    So, instead of ChannelLocal, use the ChannelHandlerContext Netty
    provides for our ConnectionContextHandler. When the socket is first
    accepted, ConnectionContextHandler creates a ConnectionContext,
    initializes it, and puts it in its ConnectionContextHandler (which is
    unique to the pipeline and therefore to the Channel). When other code
    wants the context, `ConnectionContexts.get()` can ensure it's been set
    before returning. (This won't break compatibility with anything, since
    ConnectionContextHandler is first in the pipeline which means the
    context will always be set before anything else gets the Channel.)
    
    Test Plan: tests pass
    jesboat committed Jul 12, 2015