I did not try the patch as it seemed like it would make matters worse. I had
to move on and ended up implementing something else for now. I will keep an
eye on 5.3 which will hopefully resolve this issue.
-Farshad
Gary Tully wrote:
>
> Eric,
> just in case you have not seen it, you may find
Thanks Gary, that is extremely helpful. Are there plans to address
this potential deficiency? You mentioned some improvement ideas, but
does a ticket exist yet to address them?
I'll probably take your ideas and try to at least put something
together that works for us, but since I'm very new to t
Eric,
just in case you have not seen it, you may find some of the detail in
the the following old thread relevant to your investigation.
http://www.nabble.com/Serious-dispatch-issue-tt23990060.html#a23996544
2009/10/8 Eric Van Dewoestine :
> Thanks for the link. Did you try applying that patch?
Thanks for the link. Did you try applying that patch? If so did it
resolve your issue?
I'll give the patch a shot, but the note in the ticket regarding
failures for large message counts and Joe's warnings make me a little
apprehensive. I'll update my findings as soon as I get a chance to
test it
Ah, that attribute isn't documented on the activemq site ;)
I tried that one out, but unfortunately I don't see any change in
behavior. I verified that the prefetchSize is indeed set to 1 by
examining the network connector attributes for both brokers via jmx.
Thank you so much for your help so f
Hi Eric,
I think you and I have run into the same problem. Please check below.
Farshad
http://www.nabble.com/Question-about-Queue-destinations-in-network-of-brokers-td25776018.html
Eric Van wrote:
>
> ActiveMQ 5.3.0_SNAPSHOT (Sep 8th according to the snapshots listing)
>
> I'm running into
Hi Eric,
sorry for being so quick in my reply - in the broker xml config set
the prefetchSize property on the network - e.g.
On 8 Oct 2009, at 17:16, Eric Van Dewoestine wrote:
I guess I'm not sure what setting you are referring to. I tried
setting a couple different prefetch
I guess I'm not sure what setting you are referring to. I tried
setting a couple different prefetch policies on the tcp connector like
so:
1st attempt:
2nd attempt:
But neither of them seemed to change the behavior. Are you referring
to another setting? Can you provide an example of the set
do you set the prefetchSize property on the network itself ? Setting
it on the consumers wouldn't make any difference
On 8 Oct 2009, at 15:39, Eric Van Dewoestine wrote:
I tried setting the prefetchSize to 1 for both consumers, but
unfortunately, that didn't resolve the issue. Messages still
I tried setting the prefetchSize to 1 for both consumers, but
unfortunately, that didn't resolve the issue. Messages still end up
stuck on B2 when C2 is stopped.
On Thu, Oct 08, 2009 at 09:33:06AM +0100, Rob Davies wrote:
> set the prefetchSize=1 on your network - to avoid orphaned messages on
>
set the prefetchSize=1 on your network - to avoid orphaned messages on
B2
On 7 Oct 2009, at 20:06, Eric Van Dewoestine wrote:
Hmm, that seems like a flawed approach if the broker it visited has
changed state and is now eligible to process those messages. How is
this type of fail over intende
Hmm, that seems like a flawed approach if the broker it visited has
changed state and is now eligible to process those messages. How is
this type of fail over intended to be handled with activemq? Is there
an alternate solution that I'm missing?
On Wed, Oct 07, 2009 at 11:43:49AM -0700, Joe Fern
I think that by design a message will not be forwarded to a broker that it
has already visited.
Joe
http://www.ttmsolutions.com
Eric Van wrote:
>
> ActiveMQ 5.3.0_SNAPSHOT (Sep 8th according to the snapshots listing)
>
> I'm running into an issue with the store and forward feature of
> acti
13 matches
Mail list logo
