Re: multicast without consumers

On Thu, Oct 31, 2019 at 2:07 PM Gordon Sim wrote: > On 31/10/2019 5:38 pm, Ted Ross wrote: > > I think the choice that we would consider making configurable > > would be: Release all multicast deliveries for which there is no > consumer > > (the present behavior); or Withhold credit for sender

Re: multicast without consumers

On 31/10/2019 5:38 pm, Ted Ross wrote: I think the choice that we would consider making configurable would be: Release all multicast deliveries for which there is no consumer (the present behavior); or Withhold credit for sender links on multicast addresses for which there is no consumer.

Re: multicast without consumers

On 31/10/2019 5:31 pm, Ted Ross wrote: On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell wrote: If so, is it possible to configure the old behaviour, for folks that actually wanted that? Perhaps. Does anyone want it? It _would_ prevent the looping behavior. But it would do so by dropping

Re: multicast without consumers

On Thu, Oct 31, 2019 at 1:31 PM Ted Ross wrote: > > > On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell > wrote: > >> With the below, are you saying that previously the router would always >> immediately accept an unsettled message sent to a multicast address, >> and then either send it on

Re: multicast without consumers

On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell wrote: > With the below, are you saying that previously the router would always > immediately accept an unsettled message sent to a multicast address, > and then either send it on (pre-settled) or drop it if there was > nowhere to direct it Yes.

Re: [Broker-J] How to get unacknowledged messages?

Update: For some reason the operation getMessageInfo escaped my attention. Still interested in this question: > [ Sub-question: Does the count in queueDepthMessages include > unacknowledgedMessages? It seems to. ] And pointers to the code in the Web UI that shows the messages in the

[Broker-J] How to get unacknowledged messages?

I am trying to get the current messages in a queue. To do this I am using the JMS API Queue browsing mechanism: final Destination queue = …; final Connection con; final Session session; final QueueBrowser browser; con = connectionFactory.createConnection(); con.start(); session =

Re: Outdated Python package python-qpid-proton on PyPI

Ah! I *knew* I forgot *something*! I've uploaded 0.29.0 packages to Pypi now - sorry about that. On Thu, Oct 31, 2019 at 8:02 AM Leonardo Medici wrote: > Hi folks, > I came here from the python-qpid-proton package page on PyPI < > https://pypi.org/project/python-qpid-proton/>. > The current

Outdated Python package python-qpid-proton on PyPI

Hi folks, I came here from the python-qpid-proton package page on PyPI . The current hosted version is 0.28, according to your site the latest version should be 0.29. Is the package outdated or I’m missing something?

Re: multicast without consumers

With the below, are you saying that previously the router would always immediately accept an unsettled message sent to a multicast address, and then either send it on (pre-settled) or drop it if there was nowhere to direct itbut in the latter case, now it would release it instead? If so, is it

Re: multicast without consumers

Hello Ganesh, In fact, we tested dispatch version 1.9.0 and it doesn't have this ping pong behavior between the dispatch and the broker. As you mentioned, it is due to DISPATCH-1266. So it solves our problem. As a workaround, we can upgrade to it. "Unfortunately DISPATCH-1423 did not make it