Ingo Oeser all time


 0 Collaborator

 5 Patch
ae7adae99b60700984f8acb007deed7b5f7e5285, 93aced8f230cbe935a771cf0918959b82b25003e, 181004e14a3fb735efcc826a4256369d0c96747b, fd286400aded7929877665feca1a94e834edd109, 0b2eb416e271c33762958cc75c04bf0e26131304

ae7adae99b60700984f8acb007deed7b5f7e5285 | Author: Ingo Oeser <nightlyone@googlemail.com>
 | 2020-02-21 12:37:32+01:00

    Add ExponentialReconnectionPolicy.MaxInterval (#1407)
    
    Allow specifying MaxInterval for exponential reconnection policy.

93aced8f230cbe935a771cf0918959b82b25003e | Author: Ingo Oeser <nightlyone@gmail.com>
 | 2019-01-26 13:00:22+01:00

    repair write coalescing (#1245)
    
    * repair write coalescing
    
    Current write coalescing depends on the idea that the passed in
    connection can do the writev syscall.
    
    In Go only net.Conns implemented by the net package have this property,
    since that the mechanism requires an implementation of a private method,
    checked against an interface private to the net package.
    
    So in practise only real TCP connections implement that.
    
    TLS connections cannot do that either, but that is not handled here.
    
    To get a real tcp connection, I broke up the abstraction of the
    deadlineWriter and put the effect of it into the flush call.
    
    To make it clearer that we really need a network connection, I changed
    the interface passed in to the clearer net.Conn.
    
    This is just the minimal fix to get writev back. A little cleanup work
    is needed to.
    
    Without this fix, we get only delayed writes which later happen
    in quick succession instead of coalesced writes,
    which adds only latency without any beneficial effect.
    
    Coalescing tests needed adaption, since we really need a net.Conn now.
    
    * tls and write coalescing doesn't work together
    
    since write coalescing as implemented in Go can only work on connections
    directly implemented in the net package of the Go stdlib. No wrappers
    providing framing like TLS are allowed. Using anything else but a pure
    TCP connection will lead to delayed writing of small packets instead of
    write coalescing via writev.
    
    This simply disables coalescing transparently in that case to avoid
    unwanted delays.
    
    I would have loved to return an error instead, but write coalescing is
    on by default and I didn't want to suddenly return errors with the defaults.

181004e14a3fb735efcc826a4256369d0c96747b | Author: Ingo Oeser <nightlyone@gmail.com>
 | 2018-05-06 20:46:54+02:00

    add myself to authors (#1106)
    
    since I forgot that for the last PRs.

fd286400aded7929877665feca1a94e834edd109 | Author: Ingo Oeser <nightlyone@gmail.com>
 | 2018-05-05 14:53:17+02:00

    Improve query pool (#1104)
    
    * do as much work as possible outside the lock
    
    so the lock hold time is shortened.
    
    * simplify query struct clearing
    
    while modern Go compilers should combine all those stores to an more
    efficient clearing, lets be explicit here and have a little simpler code.
    
    This also makes it impossible to forget any newly added fields.
    
    * initialize query everywhere the same way
    
    so we don't miss any settings, like missing Query.serialCons and
    Query.defaultTimestamp in the Session.Bind method.
    
    * extract copying of session defaults
    
    so in stays consistent in the future between Session.Bind and Session.Query.
    
    * use queryPool for Session.Bind

0b2eb416e271c33762958cc75c04bf0e26131304 | Author: Ingo Oeser <nightlyone@gmail.com>
 | 2018-05-05 14:39:43+02:00

    reduce Conn.mu hold times (#1105)
    
    The streamPool is already internally serialized by the Go runtime and
    designed for high scalability. But currently retrieval from that pool
    is unnecessarily serialized by the Conn.mu instead.
    
    Additionally when the pool is empty, the hold times are even higher,
    also this channel allocation for the timeout channel eas in that lock scope.
    
    All of this amounted to enough overhead to make the lock appear in
    internal profiles.
    
    Technically the only thing required to be serialized are the accesses to
    the Conn.calls map, so limit lock scope to exactly these operations.