Re: Link handling after detach(close=false)
Gordon, by "it" you are referring to the consumer/receiver, correct? Kai Gordon Sim schrieb am Mo., 29. Jan. 2018, 21:30: > On 29/01/18 17:28, Marc Pellmann wrote: > > Hi, > > > > I work on the Eclipse Hono project, where we use the qpid router. > > > > In a specific situation, I am not sure about the expected behavior and > hope > > you can help me out. > > > > In our default/example setup there is a qpid router in front of a Artemis > > broker and a client, which opens a receiver link to qpid (and qpid > creates > > a link to Artemis for this address). > > > > Initially all works as expected and messages, wich are send to the > Artemis > > address are received by the receiver. > > > > When the broker is killed, the qpid sends a detach with closed=false (on > > this I would assume that also a detach with closed=false should be send > > back from the receiver). > > > > If now, the broker is started again, the receiver gets no attach frame > and > > does not receive messages. (It gets an attach and receive messages, if it > > is also restarted.) > > > > My expectation was, that qpid would establish the link with the broker > and > > send an attach frame to the receiver. > > > > Is the expected behavior from the receiver, that after a detach with > > closed=false it need to close and try to open until the Broker is > available > > again? > > It shouldn't have to close, but it will need to try to re-attach the link. > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: Link handling after detach(close=false)
On 29/01/18 17:28, Marc Pellmann wrote: Hi, I work on the Eclipse Hono project, where we use the qpid router. In a specific situation, I am not sure about the expected behavior and hope you can help me out. In our default/example setup there is a qpid router in front of a Artemis broker and a client, which opens a receiver link to qpid (and qpid creates a link to Artemis for this address). Initially all works as expected and messages, wich are send to the Artemis address are received by the receiver. When the broker is killed, the qpid sends a detach with closed=false (on this I would assume that also a detach with closed=false should be send back from the receiver). If now, the broker is started again, the receiver gets no attach frame and does not receive messages. (It gets an attach and receive messages, if it is also restarted.) My expectation was, that qpid would establish the link with the broker and send an attach frame to the receiver. Is the expected behavior from the receiver, that after a detach with closed=false it need to close and try to open until the Broker is available again? It shouldn't have to close, but it will need to try to re-attach the link. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
qpid journal files
Hi, I am using qpid-cpp-server-1.35 version and i see lot journal files in "/data/qls/p001/efp/2048k" dir and some files under "/data/qls/p001/efp/2048k/in_use" also i see symlinks under "/data/qls/jrnl2/*/*", can some one explain what are these different locations and what are the current serving file(s)? how to set limit on the number of those files and how to purge unused files with out stoping processes. Thanks, Ram
Link handling after detach(close=false)
Hi, I work on the Eclipse Hono project, where we use the qpid router. In a specific situation, I am not sure about the expected behavior and hope you can help me out. In our default/example setup there is a qpid router in front of a Artemis broker and a client, which opens a receiver link to qpid (and qpid creates a link to Artemis for this address). Initially all works as expected and messages, wich are send to the Artemis address are received by the receiver. When the broker is killed, the qpid sends a detach with closed=false (on this I would assume that also a detach with closed=false should be send back from the receiver). If now, the broker is started again, the receiver gets no attach frame and does not receive messages. (It gets an attach and receive messages, if it is also restarted.) My expectation was, that qpid would establish the link with the broker and send an attach frame to the receiver. Is the expected behavior from the receiver, that after a detach with closed=false it need to close and try to open until the Broker is available again? Marc
Re: [RESULT] [VOTE] Release Apache Qpid Proton 0.20.0
Correction, there were actually 7 binding +1 votes. I missed counting Ken's vote earlier as the mails subject had been altered in transit. Robbie On 29 January 2018 at 09:40, Robbie Gemmell wrote: > There were 6 binding +1 votes, and no other votes received. The vote has > passed. > > I will add the files to the dist release repo and create the final tag > shortly. The website will be updated after the release has had time to > sync to the mirrors. > > Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Java Broker performance
Hi Tomas, Thanks for feedback. I will merge the changes into 7.0.1. We will be looking into performance improvements for AMQP 1.0 later this year. Though, we do not have a date exactly when we will be doing this work. The changes we had implemented are tactical. They are small enough to be ported into 7.0.x branch. For the use cases exercised by your sample applications I cannot think about any Broker settings which would improve the performance farther. Hopefully the following work will increase the performance and resolve the Broker-J lagging behind the C++ broker. Kind Regards, Alex On 29 January 2018 at 09:40, Tomas Soltys wrote: > Hi Alex, > > The performance is way much better now and is acceptable for us. Thank you > very much for your effort. > > Do you know why the performance is still lagging behind the C++ broker? Is > it something that can be influenced by the broker settings? > > Thanks and regards, > Tomas > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[RESULT] [VOTE] Release Apache Qpid Proton 0.20.0
There were 6 binding +1 votes, and no other votes received. The vote has passed. I will add the files to the dist release repo and create the final tag shortly. The website will be updated after the release has had time to sync to the mirrors. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Java Broker performance
Hi Alex, The performance is way much better now and is acceptable for us. Thank you very much for your effort. Do you know why the performance is still lagging behind the C++ broker? Is it something that can be influenced by the broker settings? Thanks and regards, Tomas -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
