we don't have that commit yet. last merge from trunk was
PROTON-440: fix from hiram
git-svn-id:
https://svn.apache.org/repos/asf/qpid/proton/trunk@1531508
13f79535-47bb-0310-9956-ffa450edef68
maybe this trace of an unsuspecting client (recv) connecting to a broker
in 'hosed' state can
If this is with trunk I'm guessing you might be noticing a change in
reply-to behaviour from a recent fix:
https://issues.apache.org/jira/browse/PROTON-278
As you mention, previously an unset reply-to would get automatically filled
in with the messenger's name. This is no longer the case. That beh
All messengers are created with default constructor (uuid-based names).
The 'broker' messenger does a pn_messenger_subscribe("amqp://~0.0.0.0:8194")
All messages are constructed with address amqp://127.0.0.1:8194 and
leave reply_to unset (so it's set to amqp://$uuid)
Broker does application-lev
Can you post the exact addresses and routing configuration you're using and
which direction messages are flowing? I'd like to try to simulate this
using the example send/recv scripts.
My guess is that the issue may not be so much related to whether the
addresses are NULL or not but whether there a
