Thank you Alan, As suggested, we will reconnect when we receive transport closed or connection forced exceptions.
Adel Get Outlook for Android<https://aka.ms/ghei36> From: Alan Conway Sent: Thursday, March 30, 18:54 Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer To: [email protected] On Thu, 2017-03-30 at 07:51 +0000, Adel Boutros wrote: > Thank you Rob, > > > I actually got this exception while a proton client was trying to > connect to a broker shutting down. > > > From your answer, I conclude that if the below error is thrown, the > retry connection mechanism should kick in. > > > Do you know if there are other possible exceptions I could get when > contacting a broker shutting down gracefully? > > > Regards, > > Adel > > ________________________________ > From: Rob Godfrey > Sent: Wednesday, March 29, 2017 11:18:58 PM > To: [email protected] > Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer > > Hi Adel, > > That error would be coming from the Java Broker... what this normally > means > is that the Virtual Host inside the broker is not currently active > ... this > may just be something like sending the message before the broker is > completely started... Because each virtual host has its own lifecycle > and > can be stopped and started independently of the port listener, the > fact > that the port is up doesn't actually mean the virtual host has > finished > started. > > -- Rob > On Wed, 29 Mar 2017 at 21:23, Adel Boutros > wrote: > > > Thank you Alan, > > > > > > As discussed with Andrew offline, we will develop our own reconnect > > strategy as we need it to handle all possible scenarios, examples: > > > > * Failure while establishing connection > > > > * Failure while sending a message > > > > * Failure while receiving a message > > > > and by failure we mean any failure regarding a lost connection. > > > > > > While testing our work, we noticed very rarely we were receiving > > the below > > exception. Do you know what it is about and how we should handle > > it? > > > > > > amqp:connection:forced:amqp:connection:forced: > > org.apache.qpid.server.virtualhost.VirtualHostUnavailableException: > > Virtualhost state UNAVAILABLE prevents the message from being sent > > > > > > Regards, > > > > Adel > > > > ________________________________ > > From: Alan Conway > > Sent: Friday, March 24, 2017 2:47:56 PM > > To: [email protected] > > Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer > > > > On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote: > > > Hello, > > > > > > Bit of context: > > > I am trying to implement a connection retry mechanism using > > > proton. A > > > bit > > > similar to the failover Url in JMS... > > > > > > I discovered that we can set "reconnect" option in the > > > connection_options.reconnect(reconnect_timer). > > > > > > There are no clear documentation, how does this option behaves? > > > Does it try to reconnect only at connection start? and does it > > > try to > > > reconnect in the middle of an Amqp communication (after > > > sending/receiving > > > some messages)? > > > > > > On the other side, how to know that the max retries or dead line > > > timeout is > > > reached? > > > > > > > See include/proton/reconnect_timer.hpp for the things you can > > configure. This is still an "experimental" feature and could use > > some > > rounding out - your experience can be helpful with that. > > > > Currently this will reconnect on an unexpected disconnect - that is > > to > > say on_transport_closed() occurs before on_connection_closed() In short - transport closed and connection-forced are all you have to deal with, for now anyway. Long story: historically in C++ (and carried forward to proton) we only reconnect if the transport fails unexpectedly. The reasoning is, if you get a protocol error then you clearly haven't been disconnected, so no call for automatic re-connect. The AMQP spec does have a "connection-forced" error, and a reasonable interpretation of is "I'm disconnecting you on purpose but for reasons that might justify a reconnect attempt" Our C++ HA broker never used it because it is simpler and more robust to force a reconnect by just closing the socket rudely and letting nature take its course. However the Java broker does use it and it is standard AMQP, so proton will support it soon (and so should you...) It is also conceivable that the connection-forced error could carry additional information to be used in reconnecting, I'm not sure if it is in practice. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
