:1058)[77:org.springframework.jms:3.0.5.RELEASE]
> > > at
> > >
> >
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)[77:org.springframework.jms:3.0.5.RELEASE]
> >
ies you use ? Or the features ?
> >
> >
> > Arnaud Deprez
> >
> > please don't print unless you really need to
> >
> >
> > -Original Message-
> > From: DEPREZ Arnaud AWL-IT
> > Sent: jeudi 19 avril 2012 14:24
> > To: users@c
d Deprez
>
> please don't print unless you really need to
>
>
> -Original Message-
> From: DEPREZ Arnaud AWL-IT
> Sent: jeudi 19 avril 2012 14:24
> To: users@camel.apache.org
> Subject: RE: OSGI Transaction Propagation to Camel Route
>
> Hi Chris,
>
> Concernin
gt;>
> >>
> >> Arnaud Deprez
> >>
> >> please don't print unless you really need to
> >>
> >>
> >> -Original Message-
> >> From: DEPREZ Arnaud AWL-IT
> >> Sent: jeudi 19 avril 2012 14:24
> >> T
Or the features ?
>>
>>
>> Arnaud Deprez
>>
>> please don't print unless you really need to
>>
>>
>> -Original Message-----
>> From: DEPREZ Arnaud AWL-IT
>> Sent: jeudi 19 avril 2012 14:24
>> To: users@camel.apache.org
&
;at java.lang.Thread.run(Thread.java:619)[:1.6.0_14]
>
>
> Arnaud Deprez
>
> please don't print unless you really need to
>
> -Original Message-
> From: Chris Geer [mailto:ch...@cxtsoftware.com]
> Sent: mercredi 18 avril 2012 18:43
> To: users@camel.apach
list of dependencies you use ? Or the features ?
Arnaud Deprez
please don't print unless you really need to
-Original Message-
From: DEPREZ Arnaud AWL-IT
Sent: jeudi 19 avril 2012 14:24
To: users@camel.apache.org
Subject: RE: OSGI Transaction Propagation to Camel Route
Hi
18:43
To: users@camel.apache.org
Subject: Re: OSGI Transaction Propagation to Camel Route
After an upgrade to 5.6-SNAPSHOT everything works as expected. I'm still
curious about my last question though :)
Thank you all for your help.
Chris
On Tue, Apr 17, 2012 at 6:28 PM, Chris Geer wrote:
After an upgrade to 5.6-SNAPSHOT everything works as expected. I'm still
curious about my last question though :)
Thank you all for your help.
Chris
On Tue, Apr 17, 2012 at 6:28 PM, Chris Geer wrote:
> Thanks Raul, that issue does look like the problem I'm seeing on the
> success case. I'll tr
Thanks Raul, that issue does look like the problem I'm seeing on the
success case. I'll try and upgrade to 5.6-SNAPSHOT tomorrow and see if that
resolves the issue.
I now see that I need to have a XA Connection Factory and XA Connection
Pool for Camel to be able to integrate with a XA transaction.
Also, see https://issues.apache.org/jira/browse/AMQ-3251.
I think the fix was backported to a release of Fuse ESB 4.4.1, that's
why we don't experience it in the example.
You may want to try with a Fuse ESB release if using an AMQ snapshot
is not an option for you.
Regards,
Raul.
On 18 Apr 2012
I noticed you are using PROPAGATION_MANDATORY, which will throw an
exception if a transaction doesn't already exist. Could that justify
the exception you see when isolating only Camel? Can you try with
PROPAGATION_REQUIRED instead?
The sample I pointed you to works with no changes. In fact, you ma
Hi Chris!
I will give it a try tomorrow. I have to work on my presentation for
CamelOne [1] which will also cover transactions in Camel...
[1] http://camelone.com
Best,
Christian
On Tue, Apr 17, 2012 at 11:27 PM, Chris Geer wrote:
> Christian,
>
> I assume only have txMgr or jmsTransactionMan
Christian,
I assume only have txMgr or jmsTransactionManager, not both? I would love
to do that but camel only seems to support a Spring
PlatformTransactionManager and ActiveMQ expects a
javax.transaction.TransactionManager. Under the covers, as I understand
Aries, it is a single object that imple
The only place I'm not using an already XA aware connection factory is in
the API side, which is working perfectly because I'm manually enlisting the
Session.
On the camel side, I used your example exactly as you can see in my
blueprint file and everything depends on XA aware activemq objects. Jus
Could you try using only one transaction manager?
Best,
Christian
On Tue, Apr 17, 2012 at 10:48 PM, Raul Kripalani wrote:
> It looks like you may not be using an XA-aware Pooled Connection Factory :D
>
> See
> http://activemq.apache.org/maven/5.5.0/activemq-pool/apidocs/org/apache/activemq/pool/
It looks like you may not be using an XA-aware Pooled Connection Factory :D
See
http://activemq.apache.org/maven/5.5.0/activemq-pool/apidocs/org/apache/activemq/pool/XaPooledConnectionFactory.html
It may look catchy, but all the layers of the stack need to be
XA-aware, as XA requires a different
Raul,
Thanks for the information. I tried what you said and I think it did have
some success with rolling back the transaction but it causes significant
errors to be thrown during a success case. As I've written a sample to
debug this issue I wanted you to have my latest code so we can be
referenc
I noticed several things in your config.
1) the JMS config should be inside the 'configuration' property of the
ActiveMQComponent:
2) the 'transacted' property should be false as above, because you don't
want the component to man
Raul,
I gave that a shot but it actually made the problem worse.
ProducerTemplate.requestBodyAndHeader uses an InOut exchange pattern but
since I'm not sending responses it always fails (regardless of transaction)
with a timeout saying it didn't get a response. It also send the message to
the topi
Hi Chris!
Transaction Managers bind transactions to threads, and a possible cause for
your transaction getting lost is that your route is being called
asynchronously from another thread.
This is because you are using ProducerTemplate.send...().
Can you replace this with ProducerTemplate.requestB
Claus,
I'm still struggling with this so I've put together a quick sample project
that shows the problem. It consists of an OSGI component that runs under a
transaction and posts two JMS messages (one with Camel and one with JMS
APIs) then rolls back the transactions. I would hope to see both mess
On Thu, Apr 5, 2012 at 5:57 PM, Chris Geer wrote:
> Claus,
>
> I realize that but I can't explain what I'm seeing. Here is an additional
> piece of info, here is debug log for the sending of the message. As you can
> see, the transaction fields are all null but I don't know if that is normal
> or
Claus,
I realize that but I can't explain what I'm seeing. Here is an additional
piece of info, here is debug log for the sending of the message. As you can
see, the transaction fields are all null but I don't know if that is normal
or a symptom of the problem.
08:51:22,906 | DEBUG | erations/add
On Thu, Apr 5, 2012 at 4:59 PM, Chris Geer wrote:
> Christian,
>
> I have that book and that is what I used for a lot of my reference. In
> fact, they only major difference between his source and mine is he is using
> Atomikos as the transaction manager and I'm using aries. I am referencing
> an e
Christian,
I have that book and that is what I used for a lot of my reference. In
fact, they only major difference between his source and mine is he is using
Atomikos as the transaction manager and I'm using aries. I am referencing
an existing PlatformTransactionManager instead of creating a
JtaTr
There is some webinars about transactions with Camel, AMQ and
ServiceMix, running in the OSGi world and uses XA as well.
There should be some sample code as well.
The TX should be the 2nd part of the webinar series. You can find the
webinars here:
http://fusesource.com/resources/video-archived-web
Stefan,
I removed the wireTap line completely and it didn't make any difference.
Chris
On Thu, Apr 5, 2012 at 1:00 AM, Stefan Burkard wrote:
> Can you try to swap the two lines camel:transacted and camel:wireTap?
> There must not be any element between the "transacted" and the "from".
>
> Stef
Chris,
may be the source code of Claus book "Camel in Action" is helpful for you
[1].
Could you als share your datasource configuration with us? It was not in
your post...
[1]
http://code.google.com/p/camelinaction/source/browse/trunk/chapter9/xa/src/test/resources/spring-context.xml
Best,
Chris
Can you try to swap the two lines camel:transacted and camel:wireTap?
There must not be any element between the "transacted" and the "from".
Stefan
On Thu, Apr 5, 2012 at 07:13, Chris Geer wrote:
> We are building an application using ServiceMix (CXF, Camel, Karaf...) and
> we've run into an is
30 matches
Mail list logo
