On Tue, Mar 13, 2018 at 6:52 PM, Rajesh Malla <mallara...@gmail.com> wrote:
> when we are looking into Server broker, it has many temperary queues around > more than 2000. So we have removed one network peer. > A->B > B->A > now, after some hours tmp-queues are around 2 digits only. we have applied > below patch : > https://issues.apache.org/jira/browse/AMQ-6262 > > still after some hours client is not able to re-establish connection. I > have > questions like below > > 1) InactivityMonitor each time close connection, if this is the case who is > again re-establishing connection ? > Is your client using a failover transport? If so, it's the failover transport that's re-establishing the connection. > 2) after some hours our client is not able to re-establish connection. on > client side we are seeing different errors > > 2018-03-13 18:12:24,091 386450649 [ActiveMQ Connection Executor: HTTP > Reader > https:URL] ( CustomisedPooledConnectionFactory:114) WARN - Connection > error occurred for https:URL: Cannot send, channel has already failed: > https:URL > > > (org.apache.servicemix.bundles.spring-jms:org. > springframework.jms.listener.DefaultMessageListenerContainer:909) > ERROR - Could not refresh JMS Connection for destination 'queue' - > retrying > in 20000 ms. Cause: The JMS connection has failed: Channel was inactive (no > connection attempt made) for too (>60000) long: https://URL > > 2018-03-13 13:25:16,292 369222850 [Camel (camel-4) thread #378 - > TemporaryQueueReplyManager[ ]] > (org.apache.servicemix.bundles.spring-jms:org. > springframework.jms.listener.DefaultMessageListenerContainer:909) > ERROR - Could not refresh JMS Connection for destination 'temporary' - > retrying in 5000 ms. Cause: The JMS connection has failed: Channel was > inactive (no connection attempt made) for too (>60000) long: https://URL > I see you're using the https transport. Does it work if you connect with the tcp transport instead? It's possible that there's some bug in the https transport, so if you find that clients can connect with tcp but not with https, that would be useful information to know.. > from client side when we are again manually removing and setting connection > Please define the terms "removing connection" and "setting connection," because those phrases don't mean anything to me. > then it is working for sometime and after that it is not working. > > our scenario is simple A->B n/w mesh with one client. Please suggest any, > I'm never going to recommend that you use the http/https transports, so... My suggestion is that you ditch them and use the tcp transport (i.e. the OpenWire protocol). HTTP without websockets is a sub-optimal way to consume JMS messages because it interacts poorly with non-durable topic subscribers (it'll only establish a subscription for as long as the connection is open), so I'd recommend you switch to tcp. The http/https transports are, to my mind, only useful when you're working in a non-Java environment (which clearly you're not, since you're using Camel), so I don't see a reason you should be using them. > let us know if we want to provide any other information. >
