More testing indicates that the ">" by itself seems to be ok. It appears
that my test fails when the following is in the "activemq.xml" file:
If I remove those two lines, and keep:
then my tests run fine.
-
Stephen Vincent
--
View this message in context:
http://activemq
yes, you can achieve the requirement by setting up a combination of network and
master/slave brokers.
The slave can forward messages sent to the failed master broker to another
master brokers, not only
for the newly messages.
At 2013-01-29 19:57:04,"Matthias Vetter" wrote:
>The following s
Thanks for looking:
failover:(tcp://
daamq300.ie.i.net:61616?connectionTimeout=1&soTimeout=8000&wireFormat.tcpNoDelayEnabled=true,tcp://daamq304.ie.i.net:61616?connectionTimeout=1&soTimeout=8000&wireFormat.tcpNoDelayEnabled=true,tcp://daamq305.ie.i.net:61616?connectionTimeout=1&soTimeo
Can you post the code you're using?
On Wed, Jan 30, 2013 at 5:11 PM, pwalter wrote:
> I have a Producer and Consumer. The producer sets destination to some thing
> like: ABC.123.DDD.TEST and the consumer sets destination to:
> ABC.123.DDD.TEST and that works. But if consumer sets destination to
Please post your broker config and what URL you're using on the client
side. EOFException in the broker logs usually means the client didn't
disconnect properly
On Wed, Jan 30, 2013 at 5:11 PM, Mohit Anchlia wrote:
> With nio we often see this error even though all MQ servers are up and
> runnin
Still not sure if there is a problem. How long in between writes would you
say elapses?
Can you put a sample together showing the problem?
On Wed, Jan 30, 2013 at 5:07 PM, Mohit Anchlia wrote:
> We are using mule and activemq 5.7.0. Is there a workaround for this
> problem?
>
> On Wed, Jan 30, 2
aaah, interesting. okay, i'll try to find a solaris box and give it a shot
there.
On Wed, Jan 30, 2013 at 4:39 PM, Steve.V. wrote:
> Version 5.7.0
>
> If it matters, I am specifying the destination policy in the
> "conf/activemq.xml" file that is being read when the server is started.
>
> When
We are using mule and activemq 5.7.0. Is there a workaround for this
problem?
On Wed, Jan 30, 2013 at 2:59 PM, Christian Posta
wrote:
> There were some issues around NIO and stomp/mqtt that Tim resolved here:
>
> https://issues.apache.org/jira/browse/AMQ-4106
>
> But you'd have to tell more about
Version 5.7.0
If it matters, I am specifying the destination policy in the
"conf/activemq.xml" file that is being read when the server is started.
When server is running on Windows, I don't see the problem. However, when I
run the server on Solaris, I can reproduce the problem.
-
Stephe
It shouldn't. I gave it a try in the unit tests on trunk (changing line 86
and 87 to ">":
http://svn.apache.org/viewvc/activemq/trunk/activemq-unit-tests/src/test/java/org/apache/activemq/store/MessagePriorityTest.java?view=markup
What version are you using?
On Wed, Jan 30, 2013 at 1:46 PM, S
There were some issues around NIO and stomp/mqtt that Tim resolved here:
https://issues.apache.org/jira/browse/AMQ-4106
But you'd have to tell more about your transportConnectors to say whether
it's related.
Otherwise, if you can reproduce what you're seeing and attach to a JIRA
(preferably in a
I'm looking at the documentation for storing encrypted passwords in config
files (http://activemq.apache.org/encrypted-passwords.html) and need to work
around some… uh… questionable choices in the way it is implemented by
default. Some of this may just be my misunderstanding how it works (I hope
so
Regarding the ">" destination
wildcard(http://activemq.apache.org/wildcards.html), I see an example in
http://activemq.apache.org/how-can-i-support-priority-queues.html where is
shows the use of just ">" when setting a destination policy for all queues.
Specifically, the example shows:
Some
We are always writing and this happens when we are actively writing
successfully and then all of a sudden mq detects this to be a bad
connection.
On Wed, Jan 30, 2013 at 11:59 AM, Christian Posta wrote:
> There's usually a good reason for it. Means a transport didn't receive any
> data in a peri
There's usually a good reason for it. Means a transport didn't receive any
data in a period of time... Are you seeing it in the broker logs?
On Wed, Jan 30, 2013 at 12:05 PM, Mohit Anchlia wrote:
> We often see
>
> Channel was inactive for too long
>
> Our MQ and app is in same network and is re
what are you using for prefetch?
if you're using receiveNoWait() there is definitely a window where the
broker is still delivering to the session's prefetch. if you happen to call
receiveNoWait when the session still hasn't seen the message, then the
consumer will return null. this is one of those
Dear Distinguished Colleagues:
I am having a strange problem where I know my queue has pending
messages on it that should be immediatley available to a
consumer.receiveNoWait call.
However, more often than not those calls return null.
On the other hand, calling receive with a small timeout s
Yes, it cleanly disconnects and reconnects using the failover transport.
You should use rebalance when you have a proper network/cluster set up,
otherwise it won't do much.
On Tue, Jan 29, 2013 at 5:56 PM, Mohit Anchlia wrote:
> Thanks! Is there a downside of using rebalance?
>
> Also, does it c
18 matches
Mail list logo
