You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2011/11/11 17:39:57 UTC
Requests for inclusion in 0.14
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
Re: Requests for inclusion in 0.14
Posted by Robbie Gemmell <ro...@gmail.com>.
Thanks Justin, they are all merged now.
Robbie
On 11 November 2011 17:08, Justin Ross <ju...@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
Re: Requests for inclusion in 0.14
Posted by Justin Ross <ju...@redhat.com>.
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