Initially this is exactly what I thought of doing. But we need finer level of control. Dont want to be stuck in the AMQ send method until the broker becomes available. Instead the code will silently retry connection indefinitely similar to Spring Listener's waitUntilSuccessfull().
2009/10/29 Jörn Kottmann (JIRA) <[email protected]> > > [ > https://issues.apache.org/jira/browse/UIMA-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771483#action_12771483] > > Jörn Kottmann commented on UIMA-1643: > ------------------------------------- > > Isn't that the behavior you get when the broker URL is wrapped with > failover:() > e.g. failover:(tcp://broker:61616) ? > > > UIMA AS client does not recover correctly when the connection to a broker > fails > > > ------------------------------------------------------------------------------- > > > > Key: UIMA-1643 > > URL: https://issues.apache.org/jira/browse/UIMA-1643 > > Project: UIMA > > Issue Type: Bug > > Components: Async Scaleout > > Reporter: Jerry Cwiklik > > Priority: Blocker > > Fix For: 2.3AS > > > > > > When the connection to the broker is lost, the UIMA AS client does not > attempt to reconnect as it is done in the UIMA AS service. When the jms > send() fails due to a lost connection, the UIMA AS client notifies the > application but in addition should log a single message that the connection > was lost and enter a recovery loop attempting to reconnect at regular > intervals. Any failures during this recovery should be silently handled. If > the application does not want to recover from a bad connection it should > call stop() on the client API which will stop the recovery, cleanup > resources and terminate the UIMA AS client. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
