A bit of a heads-up, when using a a Request/Reply pattern, *don't* use temp
queues. Temp queues (and temp topics) are severely broken in the ActiveMQ
5.4.x and 5.5.x versions. They will only work for a short time before the
broker uses up whatever resources, and then it will kick your client off
I tried addding transport connector , It was able to deploy in weblogic
but not in jetty , as adding activemq-optional dependency whihc in trun
depends on jetty is causing issues, please advice me for development we use
jetty and how to get http transport work in jetty ?
--
View this mes
On Wed, 2012-03-07 at 14:26 +0100, Knut Aksnes-NOR wrote:
> Will a JMSReplyTo property created by a Java sender be made available and be
> usable as a NMSReplyTo attribute by a .NET client using NMS with the ActiveMQ
> provider?
>
> We need to use the Request Reply EIP pattern from Camel agains
Will a JMSReplyTo property created by a Java sender be made available and be
usable as a NMSReplyTo attribute by a .NET client using NMS with the ActiveMQ
provider?
We need to use the Request Reply EIP pattern from Camel against a component we
intend to write in .NET (Mostly due to the availabi
I think I found a bug in the the bin/activemq script. It's simple to
fix, and looks like someone was just trying to be too careful. :)
When trying to determine the Active MQ installation dir, it does this:
saveddir=`pwd`
...then later it does this:
cd "$saveddir"
In my case, I call the scrip
have a look at the tests: I think this one is a good match;
http://svn.apache.org/viewvc/activemq/trunk/activemq-optional/src/test/java/org/apache/activemq/bugs/AMQ2764Test.java?view=markup
It validates a network between two brokers over http
See the xml configuration for one of the brokers, it i
