Thanks John!
I've started implementing that solution.
Could anyone tell me why the QueueSender.close() hangs, when router is
down? I call it to be sure that messages has been rolledback (in
case there was some other reason of onException call) - anyway - I want
to close the sender before I start to trying to connect to new one -
and it hangs...
Or should I just allow GC to finalize the sender and not to close it
explicitly?
On Monday, July 02, 2001, Vago, John N wrote:
> We just implement the ExceptionListener interface and
> try to re-connect when OnException() is called.
> We have a many programs, that when(if! always up ;) ) the router goes
> down, they wait 30 sec, then re-try the connection.
> It works well, and is easily tested by killing the router and restarting it.
> -----Original Message-----
> From: Michal Jacykiewicz [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 10:31 AM
> To: [EMAIL PROTECTED]
> Subject: [developers] failsafe jms-client
> I would like to add some functionality to the swifmq JMS
> implementation by using wrapper classes that will re-connect to the
> jms-server in case of some connection failure (for example reboot of
> router). Currently, if the swiftmq-router is no longer available,
> jms-client will fail. I need to avoid this.
> Can I depend on string in JMSException like this one
> "com.swiftmq.tools.requestreply.TransportException: Connect
> ion closed" ?
> I need to recognize different reasons of failure - I think the only
> way to do this is to compare string in JMSException - right?
> Is there such list anywhere in documentation for swiftmq available?
------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers <your-email-address>
Archive: http://www.mail-archive.com/developers@mail.iit.de/
