On Sun, Mar 18, 2018 at 9:14 AM, Rajesh Malla <mallara...@gmail.com> wrote:
> We have to use https only, because our server broker sits in cloud & > onpremises in another location. via some other url authenticating. this > scenario is working properly in <5.8.0 > of activemq however not working with 5.12.3 version. I mean, for some > hours it is working after that it is giving errors like attached : > error.txt <http://activemq.2283324.n4.nabble.com/file/t378915/error.txt> > OK, I won't push further on this. The concerns I've voiced about the limitations of the HTTP transport wouldn't cause these connections to fail, which implies that there's something else going on. The following content is in one of the stack traces you provided in that output: Caused by: java.io.IOException: Failed to perform GET on: https://URL Reason: null at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:33)[120:org.apache.activemq.activemq-osgi:5.12.3] at org.apache.activemq.transport.http.HttpClientTransport.run(HttpClientTransport.java:205)[120:org.apache.activemq.activemq-osgi:5.12.3] ... 1 more Caused by: java.io.EOFException at java.io.DataInputStream.readInt(Unknown Source)[:1.8.0_60] at org.apache.activemq.transport.util.TextWireFormat.unmarshal(TextWireFormat.java:52)[120:org.apache.activemq.activemq-osgi:5.12.3] at org.apache.activemq.transport.http.HttpClientTransport.run(HttpClientTransport.java:196)[120:org.apache.activemq.activemq-osgi:5.12.3] ... 1 more Is this the root cause of why your connections are already closed when trying to open sessions, etc.? If so, there's one of two possibilities: 1. The broker is experiencing errors that cause it to close the connection prematurely. What do you see in the broker logs? Everything you've provided so far has been from the consumer's logs. 2. The load balancer is experiencing behavior that cause it to terminate the connection prematurely, e.g. due to inactivity or other problems. If there's nothing in the broker's logs that indicates a problem, this would be the next place to dig into. Otherwise, I'd attach a debugger to the client and put a breakpoint in org.apache.activemq.jms.pool.PooledSession.close() and try to figure out who's calling it and why. > we are using service mix [ activemq 5.12.3 & camel 2.16.2 & spring 3.2 ]. > > one more question : when we are making route using camel we are seeing many > consumers are started. > for spring DMLC we are providing default cachel level CACHE_NONE. for one > route why it is creating nearly 8 to 9 consumers on same queue. because of > above errors each consumer is closed I think, finally nothing is working. > You'd need to give more information about your usage pattern for anyone to conclusively answer this question. One possibility is that the repeated failure to connect creates 8-9 consumers in succession, with all of them in a failed state. Another is that you're creating 8-9 DMLCs, either intentionally or due to retries from exception handling. Or maybe it's something else; I'm not an expert on the behavior of the DMLC, so if you feel that this question is relevant to the broader questions in this thread, you might want to pose it on a Spring forum or on StackOverflow to see if someone who knows the DMLC code well can shed some light on why it's doing what it's doing. > https option we cannot change it now, bcz of our designs, what is the main > reason we are not able to receive message ? > > also remove connection and create connection means, we are removing > component in camel and creating new route in camel on that queue. even if > we > restart client also wroking. BTW, have you read http://activemq.2283324.n4.nabble.com/Logentry-quot-Setup-of-JMS-message-listener-invoker-failed-for-destination-quot-td4676507.html and http://activemq.2283324.n4.nabble.com/ActiveMQ-Pooled-Session-td4698203.html? Both provide proposed solutions from other users, though in neither case did the OP respond to say whether the suggested changes had the desired effect, so I can't promise that they'll work for you (nor that they won't cause some problem). But if either one does work, we'd certainly like to know that. Tim
