qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Requests for inclusion in 0.14
Date Fri, 11 Nov 2011 17:58:53 GMT
Thanks Justin, they are all merged now.

Robbie

On 11 November 2011 17:08, Justin Ross <justin@redhat.com> wrote:
> Hi, Robbie.  All approved.  Thanks for the well described request.
>
> Justin
>
> On Fri, 11 Nov 2011, Robbie Gemmell wrote:
>
>> Hi Justin,
>>
>> I would like to request the following changes for the Java
>> client+broker be considered for 0.14:
>> QPID-3611, QPID-3610, QPID-3446, QPID-3592.
>>
>>
>> - IoReceiver calls shutdownInput on an SSLSocketImpl, which is not
>> supported
>> https://issues.apache.org/jira/browse/QPID-3611
>>
>> This one makes the broker emit a nice stacktrace on every connection
>> close (amongst other things im sure) when using SSL. It was introduced
>> in 0.13 by us moving the IO layer away from MINA and then using
>> SSLSockets on the broker (unlike the client), which do not support
>> shutdownInput being called on them.
>>
>>
>> - set TCP_NODELAY true by default in the Java client to improve
>> general performance
>> https://issues.apache.org/jira/browse/QPID-3610
>>
>> As discussed on the list recently, setting this to false on the client
>> by default as we do causes numerous typical use cases to perform
>> terribly out of the box. (We have also unintentially changed its
>> default for 0-8,0-9,0-9-1 users by moving the client to a single IO
>> layer and ditching MINA).
>>
>>
>> - Deadlock observed during broker shutdown with simultaneous closing
>> of connection and attempted message delivery
>> https://issues.apache.org/jira/browse/QPID-3446
>>
>> Although this one was observed (multiple times) during broker
>> shutdown, it is possible for the issue to be replicated in other
>> conditions so I think we should get this in. The precise deadlock was
>> again tracked to changes made elsewhere during 0.13.
>>
>>
>> - Python test fails to receive more messages against the Java Broker
>> after sending message.stop and then issuing more credit
>> https://issues.apache.org/jira/browse/QPID-3592
>>
>> This one will afflicts the Java broker with a problem during continued
>> rollbacks/recovers by the client, as once they have rolled back
>> <prefetch size> messages they will simply recieve no more. This
>> existed prior to 0.13, but I think it is sufficiently simple and
>> compelling to warrant inclusion.
>>
>>
>> Regards,
>> Robbie
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message