Another possibility is to use AMQ failover transport described here: http://activemq.apache.org/failover-transport-reference.html
We only have one broker, so my hope is that this would ok and the AMQ will just attempt connection again to the same broker. There are various parameters that control how many retries and delays before retries including back off. So our broker url would be like failover:(tcp:/bluej667:61620?decorations). **** This is client side only ****. We cant define this in the ducc.properties since the broker url is used to configure ducc's broker. The ducc common framework code can assemble this. The UIMA-AS can also wrap user provider broker url with failover:(..) if failover is missing. Comments? On Fri, Feb 7, 2014 at 10:58 AM, Jerry Cwiklik (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/UIMA-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Jerry Cwiklik updated UIMA-3605: > -------------------------------- > > Description: > It appears that under heavy network load UIMA-AS is getting "Wire format > negotiation timeout" Exception when opening a connection to a broker. > > The client side of AMQ is sending a frame containing its parameters to the > server (broker). It reconciles clients params against its own and sends a > reply back to the client. The reply apparently never reaches the client > causing the timer to pop (default=10secs) and an exception is thrown. > > Attempt to extend the client timeout via > wireFormat.maxInactivityDurationInitalDelay=60000 doesnt fix the problem. > One possible explanation is that either the client wire format frame is not > reaching the server or the server's reply doesnt reach the client. This may > be due to a lost TCP packet. > > Since the low level amq wire negotiation doesnt offer retry, the UIMA-AS > may need implement a higher level retry around the connection open() logic. > It should capture generic JMSException and check the associated description > for "wire format ..." problem. In such case, the connection should be > closed and reopened. > > > > was: > It appears that under heavy network load UIMA-AS is getting "Wire format > negotiation timeout" Exception when opening a connection to a broker. > > The client side of AMQ is sending a frame containing its parameters to the > server (broker). It reconciles clients params against its own and sends a > reply back to the client. The reply apparently never reaches the client > causing the timer to pop (default=10secs) and an exception is thrown. > > Attempt to extend the client timeout via > wireFormat.maxInactivityDurationInitalDelay=60000 doesnt fix the problem. > One possible explanation is that either the client wire format frame is not > reaching the server or the server's reply doesnt reach the client. This may > be due to a lost TCP packet. > > Since the low level amq wire negotiation doesnt offer retry, the UIMA-AS > may need implement a higher level retry around the connection open() logic. > It should capture generic JMSException and check if the associated > description for "wire format ..." problem. In such case, the connection > should be closed and reopened. > > > > > > UIMA-AS gets "Wire format negotiation timeout" on connection.open() > > ------------------------------------------------------------------- > > > > Key: UIMA-3605 > > URL: https://issues.apache.org/jira/browse/UIMA-3605 > > Project: UIMA > > Issue Type: Bug > > Components: Async Scaleout > > Affects Versions: 2.4.2AS > > Reporter: Jerry Cwiklik > > Assignee: Jerry Cwiklik > > Fix For: 2.5.0AS > > > > > > It appears that under heavy network load UIMA-AS is getting "Wire format > negotiation timeout" Exception when opening a connection to a broker. > > The client side of AMQ is sending a frame containing its parameters to > the server (broker). It reconciles clients params against its own and sends > a reply back to the client. The reply apparently never reaches the client > causing the timer to pop (default=10secs) and an exception is thrown. > > Attempt to extend the client timeout via > wireFormat.maxInactivityDurationInitalDelay=60000 doesnt fix the problem. > One possible explanation is that either the client wire format frame is not > reaching the server or the server's reply doesnt reach the client. This may > be due to a lost TCP packet. > > Since the low level amq wire negotiation doesnt offer retry, the UIMA-AS > may need implement a higher level retry around the connection open() logic. > It should capture generic JMSException and check the associated description > for "wire format ..." problem. In such case, the connection should be > closed and reopened. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) >
