Hi Anouchka,
I assume what is happening in the dispatch router case is that the
message does in fact go back to AVAILABLE state, but since the
connection between the router and broker is still up (and there is still
credit for transfer), the message is immediately re-sent to the router
where
Hello,
I am sending messages to a broker with client acknowledge mode and checking
the different states of the messages. I realized that when a consumer
receives a message, it sets the message state to ACQUIRED and when you
close the consumer without acknowledging it, it releases the message and
Thank you Ganesh.
In that case, I will stick to using qdstat for the moment.
Regards,
Adel
From: Ganesh Murthy
Sent: Wednesday, February 22, 2017 5:12:23 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Dispatch] Manage Dispatch router
- Original Message -
> From: "Adel Boutros"
> To: users@qpid.apache.org
> Sent: Wednesday, February 22, 2017 10:58:42 AM
> Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
>
> Hello,
>
>
> One more issue: I am trying to replicate a "qdstat -a"
Hello,
One more issue: I am trying to replicate a "qdstat -a" to get the statistics of
the addresses.
It seems the 'name' and 'identity' fields returned are always prefixed by some
weird combinations "L" or "M0" or "L$", etc. Is this expected?
Output
--
attributeNames:
Hi Alan,
Thanks for the reply. I've created a JIRA ticket as requested.
https://issues.apache.org/jira/browse/PROTON-1415
J.
Jeremy Gooch http://goochgooch.co.uk
From: Alan Conway
To: Jeremy Gooch ; "users@qpid.apache.org"
Hello guys,
My basic JMS API is almost ready. I will share it with you soon to have your
feedback.
However, I tried one last thing by getting a random queue name and using it as
management reply queue to allow multiple configuration sessions simultaneously
but it didn't work.
//This