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 <[email protected]> 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 <[email protected]> > 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() > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
