activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Camel generating message with correlationid=null and tmp-queue null
Date Mon, 19 Mar 2018 05:41:12 GMT
On Sun, Mar 18, 2018 at 9:14 AM, Rajesh Malla <> 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 <>

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

Caused by: Failed to perform GET on: https://URL
Reason: null
	at org.apache.activemq.util.IOExceptionSupport.create([120:org.apache.activemq.activemq-osgi:5.12.3]
	... 1 more
Caused by:
	at Source)[:1.8.0_60]
	at org.apache.activemq.transport.util.TextWireFormat.unmarshal([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
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message