Thank you for the information - it’s nice to have an explanation for the
behavior we’re seeing.
As far as I know, yes - you’ll need a JTA transaction manager if you have more
than one resource (in this case, ActiveMQ brokers) that you want to participate
in a transaction. This is where all the
Hmmm... not really sure about #2... or do I also need a JTA Tx manager for
working with multiple brokers?
On Tue, Feb 9, 2016 at 8:48 AM, Stephan Burkard wrote:
> Hi Quinn
>
> I found this blog post that explains some things we found out:
>
> http://tmielke.blogspot.ch/2012/03/camel-jms-with-t
Hi Quinn
I found this blog post that explains some things we found out:
http://tmielke.blogspot.ch/2012/03/camel-jms-with-transactions-lessons.html
=> See sections 2) and 3) for simple configuration without Tx manager
=> See section 7) for Tx manager with transacted = false
In that blog post t
Good to hear ;-)
Yeah - I meant camel-sjms - I think autocorrect got me on that one - sorry. I
like the way camel-sjms does it’s internal pooling - I don’t need to create
pooled connection factories anymore. You can also just add “transacted=true”
in the URI and you’re using JMS Session trans
Oh, our messages overlapped...
Your questions:
"... doing this queue to queue work using one or two ActiveMQ brokers?"
=> One broker
"... you may want to try camel-sims"
=> I guess you mean Camel sJms, that's the closest match I found in the
list of Camel components on GitHub :-) Never heard (ok
Thank You Stephan - that really helps.
I ran the project as-is and saw the failure in the “standard” setup on the
first run - much easier for me ;-)
Then I change transacted to false, and I’ve run it 5-times and it’s succeeded
(i.e. not lost messages ).
Have you been able to make it drop messa
Hi Stephan -
I have a keen interest in this one because my customers rely very heavily on NO
MESSAGE LOSS - period (they are mostly Healthcare Providers).
I was comparing configurations again, and I came up with one more difference -
can you try setting transacted=false in the “standard” test?
Hi Quinn
I don't think that you need to match exactly my broker version. I had first
discovered this issue on ActiveMQ 5.9.0 standard edition. I guess that
simply every broker version suffers from this. I really don't think it is
an ActiveMQ problem. It is according to Redhat a Spring JMS problem.
Stephan -
I’ll get a broker running and try to match your version - I think I can get it
from one of my customers whose running Fuse 6.2.
While I do that - have you considered trying to reproduce this using an
embedded broker that the test could control? It would make it much easier to
reprod
Hi Quinn
I just tested the POM changes you posted and the second run failed (without
failover-URL). I then tested with the failover-URL and the third attempt
failed.
The latter is no big surprise since I discovered the problem during
failover tests in a master-slave-config. I then reduced the set
I tested this with a 5.9.0 broker and I am seeing messages dropped with the
TxText, but I still have to use the failover URL or the test just stops after
the broker is restarted.
I don’t have a 5.9.1 broker to test with, so I don’t know if that would help,
but the next oldest broker I have is 5
I still can’t make either test drop messages between the input and the output
queue with the POM changes I sent, but I did find one difference between what
you’ve done and what I normally do that changes the output I’m seeing - I
always use a failover URL
My test broker is v 5.10.1 as well -
It is strange - I’m trying to compare what you have in the “standard” version
to what I did before. We tested our configs pretty heavily under all sorts of
strange conditions to verify we weren’t looking messages, but we were using
newer versions of Camel and ActiveMQ.
So we’re on the same pag
Hi Quinn
The "standard" version is the big mystery. As I stated in my first post, a
Redhat engineer analysed a similar project (with less book-keeping and
logging stuff) and his conclusion was that as soon as a transaction manager
is explicitly defined, Spring JMS Template (that is used by Camel u
I’m still going through the project, but the first couple of things that jump
out at me are you have two Spring versions - the one you explicitly put in your
POM (3.2.8.RELEASE) and the one pulled in by camel-spring (3.2.11.RELEASE).
Also, camel-spring should be included in the POM since you’re
Yes, same broker. There is only one ActiveMQ connection config in the
project.
On Wed, Feb 3, 2016 at 8:00 PM, Quinn Stevenson wrote:
> Are both the source and destination queues hosted by the same ActiveMQ
> broker?
>
>
>
> > On Feb 3, 2016, at 8:21 AM, Stephan Burkard wrote:
> >
> > Hi
> >
Are both the source and destination queues hosted by the same ActiveMQ broker?
> On Feb 3, 2016, at 8:21 AM, Stephan Burkard wrote:
>
> Hi
>
> I have built a small Maven project (attached) to demonstrate a JMS
> transaction problem in Camel routes under certain load conditions. In fact I
>
17 matches
Mail list logo
