Do you have failover and reconnect logic? It might not be a problem for you if you have this logic. Your client will keep trying to connect and once connected, will send the message. new connections are not super reliable (in my opinion). if the listening socket is busy i have seen new connections fail. since we retry, it is not a big deal... maybe in 10seconds the client will show up on the broker.
the best practice is to have a connection already and just send messages over it. why open a new connection everytime? also once established the persistence i think would work better, since you need to actually publish something for persistence to kick in. it just depends on what type of reliability you want. you could always debug your application further to see how long it is taking to do various tasks. but if you have reconnect logic already and you are not failing after you connect, then probably you are running OK. just depends on whether you want to do it the best way and invest that effort jaya_srini wrote: > > Thanks for the response, Steve! > > Our broker is not public and the clients are all internal applications and > not internet users. > > we intermittently altho frequently see this error when the client is > trying to publish a message. Our clients are both publishers and > subscribers. For every publish, the client creates a new connection, sends > the message and closes the connection. it receives the message on a > separate connection. > > Our clients also do DB intensive operations in parallel (not on the > ActiveMQ thread) but in separate threads. If for some reason , the client > is pegged doing the DB operations could this cause the client to not > respond in a timely manner to the broker and as a result we see these > timeout issues? > > thanks again! > jaya > > -- View this message in context: http://www.nabble.com/Wire-format-negotiation-timeout-tp17562104p20654762.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
