RE: Reactor receiver stuck when transport is broken

That’s right – my query is about Qpid Proton Reactor. I did implement onTransportError() – I believe, the problem is – when the transport is half-closed – onTransportError() handler is not being invoked by reactor for >15mins on that receiver. * Ideally, idle-timer should have attempted to

Re: Reactor receiver stuck when transport is broken

Hello, I imagine you are talking about Qpid Proton's reactor? If that is the case, have you implemented the "onError" as well? Some errors go there. Also, the reactor will always be running until you close the connection in one of the callbacks; are you doing so? void

Re: Qpid High Availability

Hi Alex, Thank you, After set-up of the 3 node cluster (I,e Quorum nodes), I can see cluster continues to operate after losing one node. Also I verified the message is reached to the new MASTER node. On Fri, Jul 14, 2017 at 5:40 PM, Oleksandr Rudyy wrote: > Hi Girish, > >

RE: Reactor receiver stuck when transport is broken

Hello Folks! Any help is much appreciated…. Sent from Mail for Windows 10 From: Garlapati Sreeram Kumar Sent: Monday, July 10, 2017 5:09 PM To: users@qpid.apache.org Subject: Reactor

Re: [Qpid JMS client] Asynchronous send JMS 2.0

On 14 July 2017 at 14:49, Timothy Bish wrote: > On 07/14/2017 09:34 AM, Vavricka wrote: >> >> Hi, >> >>qpid jms client version - 0.23.0 >>qpid c++ broker version - 0.34 >> >>I am unable to send messages asynchronously using the JMS 2.0 API. >> >>Connection

Re: [Qpid JMS client] Asynchronous send JMS 2.0

On 14/07/17 14:49, Timothy Bish wrote: The reason that the client is creating a new link on each send is that the message broker in question doesn't support anonymous relay links (at least it hasn't advertised to the client that it does) so the client must resort to creating a new link each

Re: [Qpid JMS client] Asynchronous send JMS 2.0

On 07/14/2017 09:34 AM, Vavricka wrote: Hi, qpid jms client version - 0.23.0 qpid c++ broker version - 0.34 I am unable to send messages asynchronously using the JMS 2.0 API. Connection string is same for JMS 1.1 and JMS 2.0 -

[Qpid JMS client] Asynchronous send JMS 2.0

Hi, qpid jms client version - 0.23.0 qpid c++ broker version - 0.34 I am unable to send messages asynchronously using the JMS 2.0 API. Connection string is same for JMS 1.1 and JMS 2.0 - "amqp://host:20405?jms.username=admin=admin=true=true=true" When I use JMS 1.1 API, it works ok.

Re: Dispatch Router throughput

On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote: Not yet, but I can certainly turn it on. No! I was checking it was off as the full logging can slow things down a lot (especially logging to a terminal). Is your test client available somewhere? I'm a bit puzzled as to what is going on and

Re: Dispatch Router throughput

Not yet, but I can certainly turn it on. Can you recommend log settings that will reveal the necessary information? Mit freundlichen Grüßen / Best regards Kai Hudalla Chief Software Architect Bosch Software Innovations GmbH Schöneberger Ufer 89-91 10785 Berlin GERMANY www.bosch-si.com

Re: Dispatch Router throughput

On 14/07/17 09:47, Hudalla Kai (INST/ECS4) wrote: We have been experimenting with different approaches: 1) Using a prefetch of 50 2) Using a prefetch of 1000 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially Interestingly, throughput seems to actually go

Re: Qpid High Availability

Hi Girish, HA cluster operates when the majority of nodes is available (when "Required Minimum Number Of Nodes" is set to DEFAULT). In 2-node cluster the majority is 2. Thus, when one node goes down, the cluster looses majority and cannot operate even when second node is Ok. It is implemented

Re: Qpid High Availability

Hi Alex, Thank you very much for your detailed email, now I'm able to send the message in the group. I had used the below URL with fail over settings, connectionfactory.qpidConnectionFactory=amqp://guest:guest@clientid

Re: Dispatch Router throughput

We have been experimenting with different approaches: 1) Using a prefetch of 50 2) Using a prefetch of 1000 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially Interestingly, throughput seems to actually go down the more credit we issue, i.e. option 1) yields

Re: Dispatch Router throughput

On 14/07/17 09:07, Hudalla Kai (INST/ECS4) wrote: Sadly, though, it doesn't at all match what we are experiencing using a vertx-proton based Java sender and consumer where we currently seem to not get above 2500 m/sec. I hope that either our test setup is completely wrong or that our usage of

unable to run qpidd as deamon on startup

hello i'm trying to run the qpidd on startup but it fails and I dont understand the reason can anyone help me on this? I'm running it on centos7 systemd the /var/log/messages says Jul 14 10:05:35 localhost systemd: Started An AMQP message broker daemon.. Jul 14 10:05:35 localhost systemd:

Re: Dispatch Router throughput

Hi Chuck, this is indeed very helpful and it is in the same ball park as I expected. Sadly, though, it doesn't at all match what we are experiencing using a vertx-proton based Java sender and consumer where we currently seem to not get above 2500 m/sec. I hope that either our test setup is