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 behaviour was unintentional as there are times when you legitimately want the reply-to to be left unset. The intended behaviour was to expand "~" at the beginning of an address to the messenger's name. That is now how trunk behaves, so if you set your reply-to's to "~" then your problem might go away, although your question is still an interesting one as I believe if you wished you could intentionally set up competing receivers using explicit non-uuid addresses that collide. --Rafael On Thu, Oct 24, 2013 at 2:49 PM, Bozo Dragojevic <[email protected]> wrote: > 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-level routing of messages > a publisher sends a special 'register' message > replies are constructed using stored 'reply_to' address from incoming > message > forwarded messages are constructed using stored 'reply_to' address from > incoming 'registration' messages > > Messenger routing facility is not used in any way. > All Messengers are running in async mode (broker and client library share > the same 'event loop code'). > We're using outgoing trackers, mostly for the 'buffered' check > All incoming messages are accepted as soon as they are processed. > All outgoing messages are settled as soon as they are not buffered anymore > > maybe it'd be possible to simulate the situation by commenting out the > pni_pump_out() in pn_messenger_put(), that, or at least checking if sender > link address really has anything to do with > the address calculated in pn_messenger_put() > > Bozzo > > > On 24. 10. 13 20:25, Rafael Schloming wrote: > >> 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 are multiple receivers >> competing for the same messages. >> >> --Rafael >> >> >> On Thu, Oct 24, 2013 at 11:52 AM, Bozo Dragojevic<[email protected]>** >> wrote: >> >> Hi! >>> >>> Chasing down a weird behavior... >>> >>> looking at messengers pni_pump_out() and how it's used from >>> pn_messenger_endpoints() >>> >>> link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE); >>> while (link) { >>> if (pn_link_is_sender(link)) { >>> pni_pump_out(messenger, pn_terminus_get_address(pn_**** >>> link_target(link)), >>> >>> link); >>> >>> >>> is it really fair to assume that target address is always expected to be >>> non NULL? >>> >>> >>> I've added a bit of debug code to pn_messenger_endpoints() so it reads: >>> >>> link = pn_link_head(conn, PN_LOCAL_ACTIVE | PN_REMOTE_ACTIVE); >>> while (link) { >>> if (pn_link_is_sender(link)) { >>> static int addrnull, addrok; >>> const char *address = pn_terminus_get_address(pn_** >>> >>> link_target(link)); >>> if (!address) { >>> addrnull++; >>> } else { >>> addrok++; >>> } >>> fprintf(stderr, "links with null address: %d links with ok address >>> %d\n", >>> addrnull, addrok); >>> pni_pump_out(messenger, address, link); >>> >>> >>> and I never see 'addrok' change from 0 >>> >>> >>> when pni_pump_out is called with address==NULL: >>> >>> int pni_pump_out(pn_messenger_t *messenger, const char *address, >>> pn_link_t >>> *sender) >>> { >>> pni_entry_t *entry = pni_store_get(messenger->****outgoing, address); >>> >>> if (!entry) return 0; >>> >>> pni_store_get cheerfuly returns first message on the list >>> >>> >>> end effect is that random clients start receiving messages not directed >>> at >>> them. >>> >>> >>> For some inexplicable reason is mostly works out while there are just two >>> clients >>> connected to the messenger and we're not pushing it really hard. Still >>> trying to come >>> up with a simple test-case. >>> >>> Can anyone shed some light how the addressing on the link level is >>> supposed to work in mesenger? >>> >>> Bozzo >>> >>> >
