Thanks Justin, they are all merged now. Robbie
On 11 November 2011 17:08, Justin Ross <[email protected]> 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:[email protected] >> >> > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
