> I'm not sure about best solution to the SFSB stuff. Nor i... =(
> There shouldn't be any problem synchronizing SpySession.sendMessage(), but > I can't guarantee it and since I don't have time to completely update my > CVS (last done over a month ago!) and test the change I'm not that keen to > do it myself. I will see how it behaves... in theory it should be ok, since a session is really only valid inside of one thread context... but then perhaps it should fail, rather than adapt? --jason > David. > > > -----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
