> And another thing, I can't 100% remember because its been a while since I > read it but I think the JMS spec says that Sessions should not be shared > by multiple threads. Crazy in my opinion but there you go...
Right, which is where I screwed up. So, the question now is, should we put in some sanity checks so we can produce some meaningful exceptions when this happens? Perhaps a ThreadLocal which is checked on sendMessage() in the Session case... or does the spec only mean that one thread can call methods on a session at once, meaning that if there was synchronization here that multipule threads would be ok? Same goes for SFSBs... or EJB in general... really threading and EJB/JMS has always been vauge with respect to what the spec says. If we can descide what the specs mean and provide some sanity checks then it would help improve the debugability of JBoss. At this point my issue is probably resolved, but I am more concerend about others who might run into similar problems due to application design errors. --jason > > -----Original Message----- > > From: Jason Dillon [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 23, 2002 8:31 AM > > To: [EMAIL PROTECTED]; David Maplesden; > > '[EMAIL PROTECTED]' > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > Nothing like a cry for help to get me interested. > > > > =) > > > > > So you either need to patch SpySession sendMessage so that it is > > > synchronized or patch the client code (the code calling the > > > > JBossMQ stuff) > > > > > so that it doesn't have threads calling commit on the > > > > session at the same > > > > > time other threads are using the queueSender.send() method. > > > > I must admit > > > > > any client where the order of these two operations is > > > > indeterminate is in > > > > > dangerous territory as they won't know which transaction > > > > their message > > > > > sends are ending up in, which probably why the bug hasn't > > > > shown up before. > > > > > I guess the client code in this case is the JMS RA stuff > > > > (which I know > > > > > nothing about) so it might need investigating. > > > > So, this does indeed get interesting... my client code is > > calling a SFSB which > > has a JMS RA, which has the SpySession. > > > > I do have a timer thread sending back periodic stats with the > > same SFSB (my > > bad) which the main thread uses... but shouldn't the SFSB > > detect this and > > throw an exception about the concurent usage? > > > > Shit, my EJB has gotten rusty... only one thread should > > beable to use a SFSB > > at a time... or really one thread per bean in general > > right... I need to read > > the latest spec again. =( > > > > I can fix my client to sync, but I am wondering if there is > > something we can > > do to make the cause of this problem more obvious for others. > > > > So, for the spec experts out there, is there something that > > should be done wrt > > the SFSB in this case? > > > > And is there any reason why SpySession.sendMessage() should NOT be > > synchronized? > > > > Thanks David. > > > > --jason > > > > > David. > > > > > > > -----Original Message----- > > > > From: Jason Dillon [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, May 23, 2002 7:37 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > I spent the last week upgrading my service to JBoss3, > > > > which made the > > > > > > configuration much easier for me to managed (no more hacks in > > > > jboss.conf for > > > > extra classpaths and such), but I am still seeing an > > > > occasional "Invalid > > > > Invalid transaction id." when using the JMS RA and JBossMQ. > > > > > > > > I changed my model so that my client (invoked inside of a > > > > NotSupported MDB) > > > > uses a SFSB with a referece to java:/JmsXA RA, mostly to > > > > get around > > > > > > serialization issues, but whatever. > > > > > > > > A test sceneraio creates 1000 request messages, each of which > > > > will send back > > > > 1+n responses, where n could vary from 2-? depending on how > > > > long the request > > > > took to process. > > > > > > > > So lets assume that for each request that there are 3 > > > > responses, so there are > > > > 5000 messages, 1000 to a request queue and 4000 to a response > > > > queue. I am > > > > seeing an occasional problem sending responses back where > > > > several responses > > > > in a row will fail with this Invalid transaction id. > > > > > > > > Each request/response(s) cyle is exactly the same... so why > > > > could some have > > > > invalid tx id's and others have valid ones? > > > > > > > > Below is a trace from one of the exceptions, though I doubt > > > > it is of much use. > > > > Any idea what might be causing this? Is this likely to be a > > > > JMS RA problem > > > > or JBossMQ problem? > > > > > > > > Any insight would be helpful, I really need to track this > > > > problem down. > > > > > > > > --jason > > > > > > > > > > > > <snip> > > > > com.boldfish.does.worker.WorkerException: failed to send > > > > message; - nested > > > > throwable is: javax.jms.JMSException: Invalid transaction id. > > > > + nested throwable: > > > > javax.jms.JMSException: Invalid transaction id. > > > > at > > > > org.jboss.mq.SpyXAResourceManager.addMessage(SpyXAResourceMana > > > > ger.java:71) > > > > at > > > > org.jboss.mq.SpySession.sendMessage(SpySession.java:395) > > > > > > at > > > > org.jboss.mq.SpyQueueSender.internalSend(SpyQueueSender.java:118) > > > > at > > > > org.jboss.mq.SpyQueueSender.send(SpyQueueSender.java:68) > > > > > > at > > > > com.boldfish.ben.system.adapter.jms.ejb.QueueSenderAdapterEJB. > > > > send(QueueSenderAdapterEJB.java:340) > > > > at > > > > sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) > > > > at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > > > > odAccessorImpl.java:25) > > > > at java.lang.reflect.Method.invoke(Method.java:324) > > > > at > > > > org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.in > > > > voke(StatefulSessionContainer.java:823) > > > > at > > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInter > > > > ceptor.java:129) > > > > at > > > > org.jboss.resource.connectionmanager.CachedConnectionIntercept > > > > or.invoke(CachedConnectionInterceptor.java:147) > > > > at > > > > org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invok > > > > e(StatefulSessionInstanceInterceptor.java:266) > > > > at > > > > org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Abstrac > > > > tTxInterceptor.java:96) > > > > at > > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxI > > > > nterceptorCMT.java:167) > > > > at > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT > > > > .java:61) > > > > at > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) > > > > > > at > > > > org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionC > > > > ontainer.java:380) > > > > at org.jboss.ejb.Container.invoke(Container.java:705) > > > > at > > > > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) > > > > > > at > > > > org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) > > > > > > at > > > > org.jboss.invocation.InvokerInterceptor.invoke(InvokerIntercep > > > > tor.java:102) > > > > at > > > > org.jboss.proxy.TransactionInterceptor.invoke(TransactionInter > > > > ceptor.java:73) > > > > at > > > > org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor > > > > .java:76) > > > > at > > > > org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(Stateful > > > > SessionInterceptor.java:117) > > > > at > > > > org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) > > > > at $Proxy23.send(Unknown Source) > > > > </snip> > > > > > > > > _______________________________________________________________ > > > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > > August 25-28 in Las Vegas -- > > http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
