You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by ffrenchm <ff...@gmail.com> on 2009/06/01 15:18:05 UTC
Re: transactions with servicemix
Hello,
thank you for your answers ... Bellow some comments and ... other questions
:)
gnodet wrote:
>
> When using the JCA flow, the exchange is transformed into a JMS
> message sent. This is done inside the current transaction. The
> consequence is that the consumer component has to commit the
> transaction first, so that the provider component will be able to
> receive the exchange and process it. This leads to synchronous
> exchanges not being usable in this model. Same as in the JMS world:
> you can not use a transaction over a request / response in JMS.
>
Well ... I don't understand why it must be the consumer component which has
to commit the transaction :) Why the commit couldn't be done in the
sendSync() as it can be done at the send when producer component reply to
the consumer OK or ERROR ?
gnodet wrote:
>
> I don't see why it would fail. Do you create a new exchange from
> scratch and populate it the same way ?
> Also when using XA transactions in smx3, you need to set the flag
> autoEnlistInTransactions to true on the JBI container configuraiton.
> Maybe pasting your component relevant snippet would help.
>
The problem comes from my code (I did an ugly copy/past error), in fact it
works well. :)
gnodet wrote:
>
> the jms receive will be committed when you called send() again on the
> exchange so that it's sent back to the consumer.
>
That's good to know... Anyway in the case of my sample which is working well
now, that's mean we will have one transaction per exchange and so one commit
per answers and I've the impression that with servicemix 3 it's not possible
to commit after and only after I send the 3 answers of my 3 requests (IE :
one transaction unit for 3 exchange) ... Nevertheless I've the impression
this will be possible with servicemix 4. Am I false ?
After reading the JBI specification (Chapter 15, "Appendix : Use of
transactions") I didn't found this explanation (commit in the send) and it
seems to me that they explain something different : all the commit they are
talking about are coming from the initiator. Do you know where I can find
state diagram which could better explain the transactional operations
depending on the message exchange state ?
gnodet wrote:
>
> That's wrong. The JCA flow will convey DONE and ERROR exchanges too.
>
Yes you right, I read the DeliveryChannelImpl too quickly : my comment was
in fact for synchronous transaction and in the case of SEDA flow it make
sense to remove the transaction manager because there is no transactional
resources.
gnodet wrote:
>
> The model has changed because the JCA flow is way too verbose in terms
> of JMS exchanges: for a single JBI exchange (in/out), you end up with
> 3 JMS messages. Imagine if you have more than a few JBI endpoints
> involved, you end up with *lots* of JMS messages which have no value.
> In addition the smx3 transaction model does not scale well because if
> you want to avoid the JCA flow, you need to always use sendSync which
> leads to lots of threads being blocked.
>
This comments about JMS messages remind me another question I have which is
not really about transactions. I read in the JBI specification that a
request answer is defined like that (for InOnly exchange type but it's the
same for the others exchanges types) : InOnlyExchange + request +
DONE|ERROR... So I've the impressions that the entire request is sended in
the answer messages ? Is that right ? If yes why do we not use JMS message
id / correlation id ?
gnodet wrote:
>
> The purpose of the JCA flow was to provide transactions + distribution
> at the same time. In ServiceMix 4, you can do that in a better
> scalable way by using the new cluster engine, or using explicit JMS
> endpoints. You can control when/where the JBI exchanges go through
> the JMS layer, have more control over it and still have a transaction
> + distributed behavior.
> See http://servicemix.apache.org/nmr/13-clustering.html but I guess
> the doc needs to be enhanced a bit to explain what happen underneath
> the cluster engine.
>
When you say "using explicit JMS endpoints" do I must understand that
component will use the servicemix-jms component through the nmr for exemple
? Does that mean the transactions operations will be managed by the
servicemix-jms component and no more by the components (IE : we don't need
to get transaction manager in the JBI components) ?
About clustering and endpoint creation could you tell me if there will be an
enpoint parameter to explicitly tell which endpoint has to be clustered (IE
: to create JMS queue) ? Is it possible to use cluster manager without
transactions behavior (IE : like smx3 jms flow) ?
I plan to work on transaction with smx 4 so I think I'll have more questions
which will maybe help to enhance the clustering documentations. So wait and
see... :)
Thanks for all
--
View this message in context: http://www.nabble.com/transactions-with-servicemix-tp23765829p23814850.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: transactions with servicemix
Posted by bquenin <bq...@axway.com>.
mffrench wrote:
>
> When you say "using explicit JMS endpoints" do I must understand that
> component will use the servicemix-jms component through the nmr for
> exemple ? Does that mean the transactions operations will be managed by
> the servicemix-jms component and no more by the components (IE : we don't
> need to get transaction manager in the JBI components) ?
>
My understanding of transaction management between SMX3 and SMX4 is that:
- on SMX3, you have a "per flow" transaction, meaning that each exchange
between 2 components is transacted (resulting in an not so much effective
approach, from a performance standpoint),
- on SMX4, it seems it's a more global, "per orchestration" transaction,
where you plug transactional JBI components (such as the JMS one, or a
database one if it exists) at transaction boundaries. It's more like sync
points you set as alligator clips on an existing orchestration.
But, I'm not an expert at all and this need to be double confirmed by
someone who actually knows how it works =)
BQ.
--
View this message in context: http://www.nabble.com/transactions-with-servicemix-tp23765829p23816537.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: transactions with servicemix
Posted by Guillaume Nodet <gn...@gmail.com>.
2009/6/1 ffrenchm <ff...@gmail.com>:
>
> Hello,
>
> thank you for your answers ... Bellow some comments and ... other questions
> :)
>
>
> gnodet wrote:
>>
>> When using the JCA flow, the exchange is transformed into a JMS
>> message sent. This is done inside the current transaction. The
>> consequence is that the consumer component has to commit the
>> transaction first, so that the provider component will be able to
>> receive the exchange and process it. This leads to synchronous
>> exchanges not being usable in this model. Same as in the JMS world:
>> you can not use a transaction over a request / response in JMS.
>>
>
> Well ... I don't understand why it must be the consumer component which has
> to commit the transaction :) Why the commit couldn't be done in the
> sendSync() as it can be done at the send when producer component reply to
> the consumer OK or ERROR ?
>
If the transaction is not committed by the consumer, the provider will
never receive the message through the JCA flow because the JMS message
is enlisted in the transaction.
>
> gnodet wrote:
>>
>> I don't see why it would fail. Do you create a new exchange from
>> scratch and populate it the same way ?
>> Also when using XA transactions in smx3, you need to set the flag
>> autoEnlistInTransactions to true on the JBI container configuraiton.
>> Maybe pasting your component relevant snippet would help.
>>
>
> The problem comes from my code (I did an ugly copy/past error), in fact it
> works well. :)
>
>
> gnodet wrote:
>>
>> the jms receive will be committed when you called send() again on the
>> exchange so that it's sent back to the consumer.
>>
>
> That's good to know... Anyway in the case of my sample which is working well
> now, that's mean we will have one transaction per exchange and so one commit
> per answers and I've the impression that with servicemix 3 it's not possible
> to commit after and only after I send the 3 answers of my 3 requests (IE :
> one transaction unit for 3 exchange) ... Nevertheless I've the impression
> this will be possible with servicemix 4. Am I false ?
>
> After reading the JBI specification (Chapter 15, "Appendix : Use of
> transactions") I didn't found this explanation (commit in the send) and it
> seems to me that they explain something different : all the commit they are
> talking about are coming from the initiator. Do you know where I can find
> state diagram which could better explain the transactional operations
> depending on the message exchange state ?
It mainly depends if the consumer and provider components are in the
same VM. The ServiceMix 3 transactions processing is tied to the use
of flows.The following page will give you the needed informations:
http://servicemix.apache.org/transactions.html
So ServiceMix 3 takes into account multiple parameters: if the
exchange has been sent using send() or sendSync() and if the target
endpoint is remote of not. When both endpoints are in the same JBI
container, they can go though the SEDA flow which can support
sendSync() for transacted exchanges. In this case, the consumer will
create the transaction and commit it, so you can send multiple
exchanges in the same tranaction using sendSync(). Using send() in
ServiceMix 3 implies that the transaction has to be committed first so
that the exchange will reach the provider endpoint. In such case, it
has to go through the JCA flow.
In ServiceMix 4, things are a bit different, as send() has the same
semantic than sendSync() wrt transactions. So you can send multiple
exchanges asynchronously if the target component is in the same VM /
JBI container. This is closer to what the JBI specification talks
about.
> gnodet wrote:
>>
>> That's wrong. The JCA flow will convey DONE and ERROR exchanges too.
>>
>
> Yes you right, I read the DeliveryChannelImpl too quickly : my comment was
> in fact for synchronous transaction and in the case of SEDA flow it make
> sense to remove the transaction manager because there is no transactional
> resources.
>
>
> gnodet wrote:
>>
>> The model has changed because the JCA flow is way too verbose in terms
>> of JMS exchanges: for a single JBI exchange (in/out), you end up with
>> 3 JMS messages. Imagine if you have more than a few JBI endpoints
>> involved, you end up with *lots* of JMS messages which have no value.
>> In addition the smx3 transaction model does not scale well because if
>> you want to avoid the JCA flow, you need to always use sendSync which
>> leads to lots of threads being blocked.
>>
>
> This comments about JMS messages remind me another question I have which is
> not really about transactions. I read in the JBI specification that a
> request answer is defined like that (for InOnly exchange type but it's the
> same for the others exchanges types) : InOnlyExchange + request +
> DONE|ERROR... So I've the impressions that the entire request is sended in
> the answer messages ? Is that right ? If yes why do we not use JMS message
> id / correlation id ?
>
>
> gnodet wrote:
>>
>> The purpose of the JCA flow was to provide transactions + distribution
>> at the same time. In ServiceMix 4, you can do that in a better
>> scalable way by using the new cluster engine, or using explicit JMS
>> endpoints. You can control when/where the JBI exchanges go through
>> the JMS layer, have more control over it and still have a transaction
>> + distributed behavior.
>> See http://servicemix.apache.org/nmr/13-clustering.html but I guess
>> the doc needs to be enhanced a bit to explain what happen underneath
>> the cluster engine.
>>
>
> When you say "using explicit JMS endpoints" do I must understand that
> component will use the servicemix-jms component through the nmr for exemple
> ? Does that mean the transactions operations will be managed by the
> servicemix-jms component and no more by the components (IE : we don't need
> to get transaction manager in the JBI components) ?
> About clustering and endpoint creation could you tell me if there will be an
> enpoint parameter to explicitly tell which endpoint has to be clustered (IE
> : to create JMS queue) ? Is it possible to use cluster manager without
> transactions behavior (IE : like smx3 jms flow) ?
>
> I plan to work on transaction with smx 4 so I think I'll have more questions
> which will maybe help to enhance the clustering documentations. So wait and
> see... :)
>
> Thanks for all
>
> --
> View this message in context: http://www.nabble.com/transactions-with-servicemix-tp23765829p23814850.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: transactions with servicemix
Posted by ffrenchm <ff...@gmail.com>.
ffrenchm wrote:
>
>
>
> gnodet wrote:
>>
>> I don't see why it would fail. Do you create a new exchange from
>> scratch and populate it the same way ?
>> Also when using XA transactions in smx3, you need to set the flag
>> autoEnlistInTransactions to true on the JBI container configuraiton.
>> Maybe pasting your component relevant snippet would help.
>>
>
> The problem comes from my code (I did an ugly copy/past error), in fact it
> works well. :)
>
>
Uhm, maybe was I a little optimistic...
A little snapshot of my InOnly sender component:
> InOnly inOnlySend;
> InOnly inOnlySend2;
> InOnly inOnlySend3;
>
> NormalizedMessage inMsg;
> byte[] b = Message.getBytes();
>
> this.tm.begin();
> inOnlySend = exchangeFactory.createInOnlyExchange();
> inOnlySend.setEndpoint(senderComponentContext.getEndpoint(destQName,
> destNameEndpoint));
>
> inOnlySend2 = exchangeFactory.createInOnlyExchange();
> inOnlySend2.setEndpoint(senderComponentContext.getEndpoint(destQName,
> destNameEndpoint));
>
> inOnlySend3 = exchangeFactory.createInOnlyExchange();
> inOnlySend3.setEndpoint(senderComponentContext.getEndpoint(destQName,
> destNameEndpoint));
>
> inMsg = inOnlySend.createMessage();
> inMsg.setContent(new StreamSource(new ByteArrayInputStream(b)));
> inMsg.setProperty("sendDate", new Date());
> inOnlySend.setInMessage(inMsg);
>
> inMsg = inOnlySend2.createMessage();
> inMsg.setContent(new StreamSource(new ByteArrayInputStream(b)));
> inMsg.setProperty("sendDate", new Date());
> inOnlySend2.setInMessage(inMsg);
>
> inMsg = inOnlySend3.createMessage();
> inMsg.setContent(new StreamSource(new ByteArrayInputStream(b)));
> inMsg.setProperty("sendDate", new Date());
> inOnlySend3.setInMessage(inMsg);
>
> senderComponentContext.getDeliveryChannel().send(inOnlySend);
> senderComponentContext.getDeliveryChannel().send(inOnlySend2);
> senderComponentContext.getDeliveryChannel().send(inOnlySend3);
> this.tm.commit();
> senderComponentContext.getDeliveryChannel().accept();
> senderComponentContext.getDeliveryChannel().accept();
> senderComponentContext.getDeliveryChannel().accept();
>
A little snapshot of my InOnly receiver component:
> try {
> inOnly = (InOnly)
> receiverComponentContext.getDeliveryChannel().accept();
> inOnly2 = (InOnly)
> receiverComponentContext.getDeliveryChannel().accept();
> inOnly3 = (InOnly)
> receiverComponentContext.getDeliveryChannel().accept();
> inOnly.setStatus(ExchangeStatus.DONE);
> inOnly2.setStatus(ExchangeStatus.DONE);
> inOnly3.setStatus(ExchangeStatus.DONE);
>
> receiverComponentContext.getDeliveryChannel().send(inOnly);
> receiverComponentContext.getDeliveryChannel().send(inOnly2);
> receiverComponentContext.getDeliveryChannel().send(inOnly3);
>
> this.timeReceive = new
> Date().getTime();
> log.info("Exchange ended:" + this.timeReceive);
> end = true;
> } catch (Exception e) {
> if (!this.stopping)
> {
> log.error("RECEIVE ERROR");
> e.printStackTrace();
> }
> }
>
I run this two components in an embedded servicemix configured like this :
> private static JBIContainer createJBIContainer(Container container)
> throws XAException
> {
> File hotdeployDir = getDirectory(HOTDEPLOY_DIR);
> File repositoryDir = getDirectory(REPOSITORY_DIR);
>
> JBIContainer result = new JBIContainer();
> result.setName(container.getName());
> result.setEmbedded(container.isEmbedded());
> result.setPersistent(container.isPersistent());
> result.setMBeanServer(getMBeanServer());
> result.setCreateMBeanServer(false);
> result.setUseMBeanServer(true);
>
> result.getManagementContext().setNamingPort(container.getManagementPort());
> result.setInstallationDirPath(hotdeployDir.getPath());
> result.setDeploymentDirPath(hotdeployDir.getPath());
> result.setMonitorDeploymentDirectory(false);
> result.setMonitorInterval(1);
> result.setAutoEnlistInTransaction(true);
>
> SedaFlow sedaFlow = new SedaFlow();
> JMSFlow jmsFlow = new JMSFlow();
> jmsFlow.setJmsURL("vm://" + container.getName());
> JCAFlow jcaFlow = new JCAFlow();
> jcaFlow.setJmsURL("vm://" + container.getName());
>
> result.setFlows(new Flow[]{sedaFlow, jmsFlow, jcaFlow});
> result.setRootDir(repositoryDir.getPath());
> result.setCreateMBeanServer(false);
> result.setUseMBeanServer(true);
> result.setTransactionManager(new GeronimoPlatformTransactionManager());
> return result;
> }
>
When I start my embedded servicemix from command line there is no problem :
> 2009-06-01 18:48:23 [main ] INFO L435 BrokerService.start -
> Using Persistence Adapter: AMQPersistenceAdapter(./data/container)
> 2009-06-01 18:48:23 [main ] INFO L538 BrokerService.getBroker
> - ActiveMQ 5.1.0 JMS Message Broker (container) is starting
> 2009-06-01 18:48:23 [main ] INFO L539 BrokerService.getBroker
> - For help or more information please see: http://activemq.apache.org/
> 2009-06-01 18:48:23 [main ] INFO L168
> AMQPersistenceAdapter.start - AMQStore starting using directory:
> ./data/container
> 2009-06-01 18:48:23 [main ] INFO L475 KahaStore.initialize -
> Kaha Store using data directory ./data/container/kr-store/state
> 2009-06-01 18:48:23 [main ] INFO L226
> AMQPersistenceAdapter.start - Active data files: [1]
> 2009-06-01 18:48:24 [main ] INFO L475 KahaStore.initialize -
> Kaha Store using data directory ./data/container/kr-store/data
> 2009-06-01 18:48:24 [main ] INFO L72
> TransportServerThreadSupport.doStart - Listening for connections at:
> tcp://dekatonshir:55107
> 2009-06-01 18:48:24 [main ] INFO L252 TransportConnector.start
> - Connector tcp://dekatonshir:55107 Started
> 2009-06-01 18:48:24 [main ] INFO L208
> NetworkConnector.handleStart - Network Connector localhost Started
> 2009-06-01 18:48:24 [main ] INFO L463 BrokerService.start -
> ActiveMQ JMS Message Broker (container,
> ID:dekatonshir-39008-1243874903874-0:0) started
> 2009-06-01 18:48:24 [main ] WARN L94
> EndpointRegistry.getEndpointProcessors - Disabled endpoint processor
> 'org.apache.servicemix.jbi.framework.support.WSDL2Processor':
> java.lang.NoClassDefFoundError: org/apache/woden/WSDLReader
> 2009-06-01 18:48:24 [main ] INFO L598 JBIContainer.init -
> ServiceMix 3.3 JBI Container (container) is starting
> 2009-06-01 18:48:24 [main ] INFO L599 JBIContainer.init - For
> help or more information please see: http://servicemix.apache.org/
> 2009-06-01 18:48:24 [main ] INFO L172
> ConnectorServerFactoryBean.afterPropertiesSet - JMX connector server
> started: javax.management.remote.rmi.RMIConnectorServer@96ad7c
> 2009-06-01 18:48:24 [main ] INFO L192
> ConnectorServerFactoryBean.afterPropertiesSet - JMX connector available
> at: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
> 2009-06-01 18:48:24 [main ] INFO L252 TransportConnector.start
> - Connector vm://container Started
> 2009-06-01 18:48:24 [main ] INFO L191 ComponentMBeanImpl.init
> - Initializing component: #SubscriptionManager#
> 2009-06-01 18:48:25 [main ] INFO L690
> DeploymentService.buildState - Restoring service assemblies
> 2009-06-01 18:48:25 [main ] WARN L89 ClientFactory.start -
> Cound not start ClientFactory: javax.naming.NoInitialContextException:
> Need to specify class name in environment or system property, or as an
> applet parameter, or in an application resource file:
> java.naming.factory.initial
> 2009-06-01 18:48:25 [main ] INFO L363
> ComponentMBeanImpl.setInitialRunningState - Setting running state for
> Component: jbi-tx-receiver-component-sample to Started
> 2009-06-01 18:48:25 [main ] INFO L191 ComponentMBeanImpl.init
> - Initializing component: jbi-tx-receiver-component-sample
> 2009-06-01 18:48:25 [main ] INFO L363
> ComponentMBeanImpl.setInitialRunningState - Setting running state for
> Component: jbi-tx-sender-component-sample to Started
> 2009-06-01 18:48:25 [main ] INFO L191 ComponentMBeanImpl.init
> - Initializing component: jbi-tx-sender-component-sample
> 2009-06-01 18:48:25 [Thread-5 ] INFO L106
> JBISenderComponent.waitService - Service sample-receiver/ activated!
> 2009-06-01 18:48:25 [main ] INFO L674 JBIContainer.start -
> ServiceMix JBI Container (container) started
> 2009-06-01 18:48:25 [main ] INFO L305 Main.main - Container
> started
> 2009-06-01 18:48:25 [Timer-0 ] INFO L666
> AutoDeploymentService.monitorDirectory - Directory: hotdeploy: Archive
> changed: processing
> jbi-tx-receiver-component-sample-1.0-SNAPSHOT-installer.zip ...
> 2009-06-01 18:48:25 [Timer-0 ] INFO L214 ComponentMBeanImpl.start
> - Starting component: jbi-tx-receiver-component-sample
> 2009-06-01 18:48:25 [Timer-0 ] INFO L668
> AutoDeploymentService.monitorDirectory - Directory: hotdeploy: Finished
> installation of archive:
> jbi-tx-receiver-component-sample-1.0-SNAPSHOT-installer.zip
> 2009-06-01 18:48:25 [Thread-4 ] INFO L175 JBIReceiverComponent.run
> - Exchange ended:1243874905626
> 2009-06-01 18:48:30 [MQ ShutdownHook] INFO L475 BrokerService.stop -
> ActiveMQ Message Broker (container,
> ID:dekatonshir-39008-1243874903874-0:0) is shutting down
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L712 JBIContainer.shutDown -
> Shutting down ServiceMix JBI Container (container) stopped
> 2009-06-01 18:48:30 [MQ ShutdownHook] INFO L212
> NetworkConnector.handleStop - Network Connector localhost Stopped
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L758
> JBIContainer.shutdownRegistry - Waiting for complete shutdown of the
> components and service assemblies
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L761
> JBIContainer.shutdownRegistry - Components and service assemblies have
> been shut down
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L273 TransportConnector.stop
> - Connector vm://container Stopped
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L1004
> JBIContainer.deactivateComponent - Deactivating component
> #SubscriptionManager#
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L204
> ConnectorServerFactoryBean.destroy - Stopping JMX connector server:
> javax.management.remote.rmi.RMIConnectorServer@96ad7c
> 2009-06-01 18:48:30 [ix ShutdownHook] INFO L727 JBIContainer.shutDown -
> ServiceMix JBI Container (container) stopped
> 2009-06-01 18:48:32 [MQ ShutdownHook] INFO L273 TransportConnector.stop
> - Connector tcp://dekatonshir:55107 Stopped
> 2009-06-01 18:48:32 [MQ ShutdownHook] INFO L512 BrokerService.stop -
> ActiveMQ JMS Message Broker (container,
> ID:dekatonshir-39008-1243874903874-0:0) stopped
>
But when I try to start it from my eclipse for debugging purpose I always
get this exception :
> 2009-06-01 18:37:12 [Thread-6 ] ERROR L177 JBIReceiverComponent.run
> - RECEIVE ERROR
> javax.jbi.messaging.MessagingException: java.lang.IllegalStateException:
> Thread already associated with another transaction2009-06-01 18:37:12
> [Thread-6 ] ERROR L177 JBIReceiverComponent.run - RECEIVE ERROR
>
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:775)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:301)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:258)
> at
> samples.jbicomponent.tx.receiver.JBIReceiverComponent.run(JBIReceiverComponent.java:156)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Thread already associated with
> another transaction
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.resume(TransactionManagerImpl.java:171)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:772)
> ... 4 more
> javax.jbi.messaging.MessagingException: java.lang.IllegalStateException:
> Thread already associated with another transaction
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:775)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:301)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:258)
> at
> samples.jbicomponent.tx.receiver.JBIReceiverComponent.run(JBIReceiverComponent.java:155)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Thread already associated with
> another transaction
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.resume(TransactionManagerImpl.java:171)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:772)
> ... 4 more
> 2009-06-01 18:37:12 [nager#-thread-1] INFO L149
> ActiveMQEndpointWorker$1.run - Successfully established connection to
> broker [null]
> 2009-06-01 18:37:12 [Thread-6 ] ERROR L177 JBIReceiverComponent.run
> - RECEIVE ERROR
> javax.jbi.messaging.MessagingException: java.lang.IllegalStateException:
> Thread already associated with another transaction
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:775)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:301)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.accept(DeliveryChannelImpl.java:258)
> at
> samples.jbicomponent.tx.receiver.JBIReceiverComponent.run(JBIReceiverComponent.java:155)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalStateException: Thread already associated with
> another transaction
> at
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.resume(TransactionManagerImpl.java:171)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.resumeTx(DeliveryChannelImpl.java:772)
> ... 4 more
>
JBIReceiverComponent.java:156 is corresponding to this code :
inOnly2 = (InOnly) receiverComponentContext.getDeliveryChannel().accept();
I'm using geronimo-transaction-2.0.1.jar in the two cases...
Is there anybody who have an idea from where comes this problem ?
Thanks
--
View this message in context: http://www.nabble.com/transactions-with-servicemix-tp23765829p23818267.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.