http://issues.apache.org/activemq/browse/SM-622
and created a tidier unit test.
cheers,
j.
On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Btw, in the mean time, you could just deactivate the transaction
log, which should do the trick.
Could you raise a JIRA for that and attach your test files,
it would be a good starting point.
On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> hiya,
>
> i was really only doing it so that my component could be deployed in
> SM without having to change the default servicemix.xml so it doesn't
> make sense for me to change JCAFlow (I'm assuming you would prefer to
> get a patch for jencks rather than JCAFlow?).
>
> I can send through all of the code that i was using to test with. It's
> not a great test case because it's basically a fully fledged component
> deployed into SM and then an integration test. Now that I know it's
> the transaction logger doing it, it should be possible to write a more
> self-contained testcase but i have a feeling my timescales are going
> to align with yours.
>
> very glad there's a solution out there.
> cheers,
> j.
>
> On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > I have had a chat about that with the main author of geronimo transaction
layer.
> > It seems that there is a missing piece of code inside jencks to wrap
> > the XAResource in a NamedXAResource.
> >
> > The missing piece looks like
> >
> > public MessageEndpoint createEndpoint(XAResource
> > adapterXAResource) throws UnavailableException {
> > NamedXAResource wrapper = adapterXAResource == null ? null :
> > new WrapperNamedXAResource(adapterXAResource, containerId);
> > return endpointFactory.getMessageEndpoint(wrapper);
> > }
> >
> > in the MessageEndpointFactory from jencks.
> > Has a hack, you could try to put that in the JCA flow somewhere.
> > Note that the containerId should be roughtly equivalent to the resource
manager
> > which supplies xids from XAResource.recover and should be the same across
> > restart. I guess using the JMS broker id should be fine.
> >
> > I'll try to give it more time this week, but if you want to try, please go.
> > You already have a working test case, so it would be easier for you.
> >
> > On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > Oddly enough, the code that would have made this work was added by
> > > jstrachan into transactionimpl and then removed to add the exception:
> > >
> > >
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java?view=log
> > >
> > > help!
> > >
> > > On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > Started debugging the geronimo-transaction code and found that the
> > > > reason that the rollback is called is because: an
> > > > IllegalStateException is being thrown:
> > > >
> > > > java.lang.IllegalStateException: Cannot log transactions unles
XAResources are n
> > > > amed! [EMAIL PROTECTED]
> > > > at
org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr
> > > > anch.getResourceName(TransactionImpl.java:658)
> > > > at
org.apache.geronimo.transaction.log.GeronimoHOWLLog.prepare(GeronimoH
> > > > OWLLog.java:229)
> > > > at
org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa
> > > > re(TransactionImpl.java:415)
> > > > at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa
> > > > ctionImpl.java:286)
> > > > at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit
> > > > (TransactionManagerImpl.java:143)
> > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > .complete(InheritableTransactionContext.java:196)
> > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > .commit(InheritableTransactionContext.java:146)
> > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionManager.co
> > > > mmit(GeronimoTransactionManager.java:81)
> > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionDelegate.c
> > > > ommit(GeronimoTransactionDelegate.java:51)
> > > > at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> > > > at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte
> > > > rDelivery(MessageEndpointProxy.java:125)
> > > > at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp
> > > > ointProxy.java:64)
> > > > at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI
> > > > mpl.java:214)
> > > > at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> > > > at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1
> > > > 63)
> > > > at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja
> > > > va:291)
> > > > at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown So
> > > > urce)
> > > > at java.lang.Thread.run(Thread.java:595)
> > > >
> > > > will continue the investigation...
> > > >
> > > > On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > hiya,
> > > > >
> > > > > JCAFlow is still not quite working for me. Here is some of the stuff
> > > > > I've done and what happened:
> > > > >
> > > > > I changed my test case to use the transactional behaviour (tm.begin(),
> > > > > tm.commit()) but i'm still getting the STATUS_NO_TRANSACTION
> > > > > exception.
> > > > >
> > > > > I took the JcaFlow test and modified it to try and replicate the
> > > > > behaviour only in a test case. The first thing that happened was that
> > > > > i got a TransportConnector NPE which looks to be fixed in a later
> > > > > version of activemq. I changed the test to directly create the
> > > > > activemq broker rather than use an activemq.xml file.
> > > > >
> > > > > I started using the EchoComponent that comes with servicemix in one
> > > > > container and a DefaultServiceMixClient in the other but go a
> > > > > "component is not the owner" from the EchoComponent trying to set a
> > > > > "Flow 'JCA' was specified but not able to handle exchange" because
> > > > > JCAFlow can't handle transacted synchronous exchanges. Wasn't
> > > > > explicitly creating a transaction. Tried setting
> > > > > autoEnlistInTransaction to false on both containers but didn't make a
> > > > > difference.
> > > > >
> > > > > Ah, figured it out. Wierd. TransformComponentSupport does this:
> > > > >
> > > > > boolean txSync = exchange.isTransacted() &&
> > > > > Boolean.TRUE.equals(exchange.getProperty(JbiConstants.SEND_SYNC));
> > > > >
> > > > > and then this:
> > > > >
> > > > > if (txSync) {
> > > > > getDeliveryChannel().sendSync(exchange);
> > > > >
> > > > > which means that it can't be used in JCA flows?
> > > > >
> > > > > Right. Wrote my own EchoComponent and sendSync works. But I'm still
> > > > > getting the STATUS_NO_TRANSACTION when I try and use the full blown
> > > > > component.
> > > > >
> > > > > will continue...
> > > > >
> > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > Have you tried starting transaction before sending the
> > > > > > jbi exchange ?
> > > > > >
> > > > > > tm.start();
> > > > > > client.sendSync(me);
> > > > > > client.done(me);
> > > > > > tm.commit();
> > > > > >
> > > > > > You can take a look at the junit tests for the EIP component.
> > > > > >
> > > > > >
> > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > Hmmm... just created a basic echo component (based on the mvn
> > > > > > > service-engine archetype) and called it using the JCA code from
the
> > > > > > > JcaTest case in servicemix-core and got the same error (using
both a
> > > > > > > DefaultServicemixClient and the SenderComponent).
> > > > > > >
> > > > > > > tried setting autoEnlistInTransaction="true" on both the client
> > > > > > > container and server container.
> > > > > > >
> > > > > > > hmmm... not sure of my next step...
> > > > > > >
> > > > > > > for reference, the client code is as follows:
> > > > > > >
> > > > > > > TransactionManagerFactoryBean tmcf = new
> > > > > > > TransactionManagerFactoryBean();
> > > > > > > tmcf.afterPropertiesSet();
> > > > > > > ExtendedTransactionManager etm =
(ExtendedTransactionManager)
> > > > > > > tmcf.getObject();
> > > > > > > TransactionContextManagerFactoryBean tcmfb = new
> > > > > > > TransactionContextManagerFactoryBean();
> > > > > > > tcmfb.setTransactionManager(etm);
> > > > > > > tcmfb.afterPropertiesSet();
> > > > > > > TransactionContextManager tcm =
(TransactionContextManager)
> > > > > > > tcmfb.getObject();
> > > > > > > GeronimoTransactionManagerFactoryBean gtmfb = new
> > > > > > > GeronimoTransactionManagerFactoryBean();
> > > > > > > gtmfb.setTransactionContextManager(tcm);
> > > > > > > gtmfb.afterPropertiesSet();
> > > > > > > TransactionManager tm = (TransactionManager)
gtmfb.getObject();
> > > > > > > tt = new TransactionTemplate(new
> > > > > > > JtaTransactionManager((UserTransaction) tm));
> > > > > > >
> > > > > > > JCAFlow senderFlow = new JCAFlow();
> > > > > > > senderFlow.setJmsURL("tcp://localhost:61616");
> > > > > > > senderFlow.setTransactionContextManager(tcm);
> > > > > > > senderContainer.setTransactionManager(tm);
> > > > > > > senderContainer.setEmbedded(true);
> > > > > > > senderContainer.setName("senderContainer");
> > > > > > > senderContainer.setFlow(senderFlow);
> > > > > > > senderContainer.setMonitorInstallationDirectory(false);
> > > > > > > senderContainer.init();
> > > > > > > senderContainer.start();
> > > > > > > senderContainer.setAutoEnlistInTransaction(true);
> > > > > > >
> > > > > > > DefaultServiceMixClient client;
> > > > > > > client = new
DefaultServiceMixClient(senderContainer);
> > > > > > > InOut inOut = client.createInOutExchange(new
> > > > > > > QName("http://org.echo/jbi";, "echo"), null, null);
> > > > > > > NormalizedMessage inMessage = inOut.createMessage();
> > > > > > > inMessage.setContent(new StringSource("<test/>"));
> > > > > > > inOut.setInMessage(inMessage);
> > > > > > > client.sendSync(inOut);
> > > > > > >
> > > > > > > server code is pretty much the same as the archetype except that i
> > > > > > > forced the endpoint in rather than deployed it as in MyLifeCycle:
> > > > > > >
> > > > > > > protected void doInit() throws Exception {
> > > > > > > super.doInit();
> > > > > > > su = new XBeanServiceUnit();
> > > > > > > su.setComponent(component);
> > > > > > > MyEndpoint myEndpoint = new MyEndpoint();
> > > > > > > myEndpoint.setServiceUnit(su);
> > > > > > > myEndpoint.setService(new QName("http://org.echo/jbi";,
"echo"));
> > > > > > > myEndpoint.setEndpoint("echo");
> > > > > > > myEndpoint.validate();
> > > > > > > su.addEndpoint(myEndpoint);
> > > > > > > component.getRegistry().registerServiceUnit(su);
> > > > > > > }
> > > > > > >
> > > > > > > protected void doStop() throws Exception {
> > > > > > > super.doStop();
> > > > > > > su.stop();
> > > > > > > }
> > > > > > >
> > > > > > > protected void doStart() throws Exception {
> > > > > > > super.doStart();
> > > > > > > su.start();
> > > > > > > }
> > > > > > >
> > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > hiya,
> > > > > > > >
> > > > > > > > I'll try and call a standard component and see if i get the same
> > > > > > > > problem, in which case i can at least isolate it to it being the
> > > > > > > > component rather than the configuration. will get back to you.
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > > j.
> > > > > > > >
> > > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > > hi Guillaume,
> > > > > > > > >
> > > > > > > > > The component is my own and is currently blissfully unaware
of the
> > > > > > > > > transaction (just moved from non transactional jms flow to
jca flow).
> > > > > > > > >
> > > > > > > > > cheers,
> > > > > > > > > j.
> > > > > > > > >
> > > > > > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > My first guess is that the component is doing something
wrong
> > > > > > > > > > with the transaction (suspend, commit, rollback).
> > > > > > > > > > The only operation allowed is to mark the transaction as
rollback only.
> > > > > > > > > > Which component receives the exchange ?
> > > > > > > > > >
> > > > > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > > ERROR - AbstractTransactionContext - Unable to roll
back transaction
> > > > > > > > > > > java.lang.IllegalStateException: Status is
STATUS_NO_TRANSACTION
> > > > > > > > > > > at
org.apache.geronimo.transaction.manager.TransactionImpl.rollback(Tran
> > > > > > > > > > > sactionImpl.java:438)
> > > > > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > > > > .rollbackAndThrow(InheritableTransactionContext.java:308)
> > > > > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > > > > .complete(InheritableTransactionContext.java:199)
> > > > > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > > > > .commit(InheritableTransactionContext.java:146)
> > > > > > > > > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionManager.co
> > > > > > > > > > > mmit(GeronimoTransactionManager.java:81)
> > > > > > > > > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionDelegate.c
> > > > > > > > > > > ommit(GeronimoTransactionDelegate.java:51)
> > > > > > > > > > > at
org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> > > > > > > > > > > at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte
> > > > > > > > > > > rDelivery(MessageEndpointProxy.java:125)
> > > > > > > > > > > at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp
> > > > > > > > > > > ointProxy.java:64)
> > > > > > > > > > > at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI
> > > > > > > > > > > mpl.java:214)
> > > > > > > > > > > at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> > > > > > > > > > > at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1
> > > > > > > > > > > 63)
> > > > > > > > > > > at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja
> > > > > > > > > > > va:291)
> > > > > > > > > > > at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown So
> > > > > > > > > > > urce)
> > > > > > > > > > >
> > > > > > > > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > > > Do you have the full stack trace please ?
> > > > > > > > > > > >
> > > > > > > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > > > > hiya,
> > > > > > > > > > > > >
> > > > > > > > > > > > > i'm getting a "Status is STATUS_NO_TRANSACTION"
exception from
> > > > > > > > > > > > > servicemix but I've just switched to using jcaFlow so
I'm not too
> > > > > > > > > > > > > surprised. any pointers of where to look for what
might be the issue?
> > > > > > > > > > > > >
> > > > > > > > > > > > > the setup is a webapp with an embedded servicemix
container calling a
> > > > > > > > > > > > > component on a standard servicemix container both
using jca flow. i
> > > > > > > > > > > > > suspect it's the configuration of the jca container
in the webapp
> > > > > > > > > > > > > that's not behaving because it's custom built but any
pointers would
> > > > > > > > > > > > > be awesome.
> > > > > > > > > > > > >
> > > > > > > > > > > > > cheers,
> > > > > > > > > > > > > j.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > Guillaume Nodet
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Cheers,
> > > > > > > > > > Guillaume Nodet
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
--
Cheers,
Guillaume Nodet
