1 Reply Latest reply on Jan 15, 2008 6:00 PM by Hiram Chirino

    Failover transport timeout

    peterm2@iona.com Newbie

      Hi,

       

      Is there any option on the failover transport to have it fail completely within a specified period of time? Currently, it will just keep bouncing through the list of URIs if all are unreachable. I understand that one can specify a maximum number of retries. But I'm thinking of a scenario where the front-end client is a browser and the design of the system is such that a QoS requirement is to not hourglass in the browser. This enhances the user experience if the system can quickly come back with some canned error page when no brokers are available to accept the message. However, the failover transport should keep trying to establish a connection so that the system is ready when one or more of the brokers come back on-line.

       

      Thoughts?

        • 1. Re: Failover transport timeout
          Hiram Chirino Newbie

          Hi that's not currently supported.

           

          If I understand you correctly, if all brokers a down you want the producer.send() call to throw an exception so that the client GUI thread does not block and cause an hourglass condition.  But you still want the JMS connection to be valid.

           

          I'm guessing we could implement this as an optional feature.  Most JMS client assume that when a JMSException is thrown from a send() method the connection has died and they need to re-establish their connections.  This is the main reason we never did implement support for this.

           

          I'll add it to my todo list of features.  Thanks for the idea!

           

          Regards,

          Hiram

           

          pdmackinnon wrote:

          Hi,

           

          Is there any option on the failover transport to have it fail completely within a specified period of time? Currently, it will just keep bouncing through the list of URIs if all are unreachable. I understand that one can specify a maximum number of retries. But I'm thinking of a scenario where the front-end client is a browser and the design of the system is such that a QoS requirement is to not hourglass in the browser. This enhances the user experience if the system can quickly come back with some canned error page when no brokers are available to accept the message. However, the failover transport should keep trying to establish a connection so that the system is ready when one or more of the brokers come back on-line.

           

          Thoughts?