Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I was finially able to get my tests to pass with insainly huge jobs, which would have failed for sure before. After I added more trace logging to JBossMQ SpySession and friends, it looks like one tx was ending, while the other was trying to add a message, but because of my misuse the session was improperly handed out to 2 seperate threads... well I can not be sure of that exactly, perhaps it was the sender. It would be nice if we could detect this and stop things early, but I am not sure how easy or difficult that would be to implement, nor am I sure where that logic should go. The redesign to only use the session and sender resources durring the life of one remote call really simplified things for me... so it is all for the better. I think I have run into this problem before, where I use the JMS RA more like a traditional JMS Session and forget completly that I should return this for each use to get the best resource sharing. Anyways, thanks for all of the insight. --jason On Friday 24 May 2002 05:56 am, David Jencks wrote: > I looked at the jmsra code a bit. You should be able to hold onto the > session over method calls (new feature w/ new jca impl) but not anything > you get from the session, such as the sender. The session may be > associated with different physical connections on each (SFSB) call, and the > sender will be tied to the physical connection it was originally created > from. > > david jencks > > On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: > > Or perhaps I am not using the JMS resource propertly within the bean... > > > > Should I be able to save a QueueSession and QueueSender as fields and use > > them > > over multipule calls inside of a SFSB? Or do I need to recreate the > > session > > and sender each time? > > > > If that is the case it rather sucks... what a pain... > > > > --jason > > > > On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > > After thinking about this somemore, and enabling thread info in > > > > server.log > > > > > I realize now that the timer is not an issue, there is never an > > > > instance > > > > > where the timer thread attempts to use the wrapper over the SFSB... the > > > work completes too fast. > > > > > > And due to the fact that I sync'd the wrapper methods it appears that > > > > this > > > > > problem happens simply because the invoke happened in a seperate > > > > thread. > > > > > Unfortunatly it does not really narrow the problem space to debug. The > > > > JMS > > > > > RA does not function with out a TX, it does not attempt to start one if > > > there isn't one already... so it just fails. > > > > > > Is it possible that there is something a miss with the bits which setup > > > > the > > > > > tx for the SFSB? Or would I see other problems when the SFSB > > > > commits... I > > > > > think this is the case, but I am not sure. > > > > > > If that is true, and the SFSB does have a TX, then it must be the JMS > > > > RA or > > > > > JBossMQ which is at fault... and I don't really know how to isolate > > > > which > > > > > it is at this point. If I don't use the JMS RA, then I have to > > > > implement > > > > > all of the XA stuff myself, which I am sure to mess up. > > > > > > Any clue on how I could narrow the problem space any? > > > > > > I am running the same test again with trace enabled for org.jboss.mq > > > > and > > > > > org.jboss.resource.adapter.jms. With the added log messages for the > > > > JMS RA > > > > > I might be able to see a problem... but who knows. > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > > If the only cause of this can be use by multiple threads, then > > > > updating > > > > > > the error message to indicate incorrect usage would be good. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > > > > > - Original Message - > > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > > > <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 23, 2002 8:18 PM > > > > Subject: R
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Hours later I give up and just fixed my app to connection and disconnect from the session for each method call... which actually simplifies things for me alot. Anyways... now I am getting this baby: java.rmi.ServerException: Application Error: tried to enter Stateful bean with different transaction context; nested exception is: java.rmi.RemoteException: Application Error: tried to enter Stateful bean with different transaction context at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:140) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.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(StatefulSessionContainer.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(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:117) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy25.send(Unknown Source) I am guess this is the exception that pops out when there is concurrent access to a SFSB... can someone confirm this for me. --jason On Friday 24 May 2002 05:56 am, David Jencks wrote: > I looked at the jmsra code a bit. You should be able to hold onto the > session over method calls (new feature w/ new jca impl) but not anything > you get from the session, such as the sender. The session may be > associated with different physical connections on each (SFSB) call, and the > sender will be tied to the physical connection it was originally created > from. > > david jencks > > On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: > > Or perhaps I am not using the JMS resource propertly within the bean... > > > > Should I be able to save a QueueSession and QueueSender as fields and use > > them > > over multipule calls inside of a SFSB? Or do I need to recreate the > > session > > and sender each time? > > > > If that is the case it rather sucks... what a pain... > > > > --jason > > > > On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > > After thinking about this somemore, and enabling thread info in > > > > server.log > > > > > I realize now that the timer is not an issue, there is never an > > > > instance > > > > > where the timer thread attempts to use the wrapper over the SFSB... the > > > work completes too fast. > > > > > > And due to the fact that I sync'd the wrapper methods it appears that > > > > this > > > > > problem happens simply because the invoke happened in a seperate > > > > thread. > > > > > Unfortunatly it does not really narrow the problem space to debug. The > > > > JMS > > > > > RA does not function with out a TX, it does not attempt to start one if > > > there isn't one already... so it just fails. > > > > > > Is it possible that there is something a miss with the bits which setup > > > > the > > > > > tx for the SFSB? Or would I see other problems when the SFSB > > > > commits... I > > > > > think this is the case, but I am not sure. > > > > > > If that is true, and the SFSB does have a TX, then it must be the JMS > > > > RA or > > > > > JBossMQ which is at fault... and I don't really know how to isolate > > > > which > > > > > it is at this point. If I don't use the JMS RA, then I have to > > > > implement > > > > > all of the XA stuff myself, which I am sure to mess up. > > > > > > Any clue on how I could narrow the problem space any? > > > > > > I am running the same test again with trace enabled for org.jboss.mq > > > > and > > > > > org.jboss.resource.adapter.jms. With the added log messages for the > > > > JMS RA > > > > > I might be able to see a problem... but who knows. > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > > If the
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
This is really strange... I end up with a null tx id (SpySession.currentTransactionId is null), so I updated my local copy of SpySession to limit access to currentTrasnactionId through a getter and setter, which appeared to limit the problem a little... though I only did it so I could get some logging going (as SpyXAResource and SpyMessageConsumer both had package protected access to the field. After running more iterations I was able to get this to fail. I hav yet to look at logs. The strange part is that I have 2 sperate vms each with a MDB listening for messages on the same remote queue (using oil il) and when this tx problem occurs, it occurs on both of them at approximatly the same time. Each listing node even has the same number of failures... which is very odd. Does anyong know if the tx methods which assign the xid should ever be null? I know that there are some explicit null's which I am going to replace with an unsetCurrentTransactionId() to be explicit, then throw an exception when setCurrentTransactionId(null) happens... as it appears to be invalid (unless I missed an changing one to use unset). I still have not changed my application to properly use the session and sender... as this is vastly more interesting... but I will have to get around to that eventually. --jason On Friday 24 May 2002 05:56 am, David Jencks wrote: > I looked at the jmsra code a bit. You should be able to hold onto the > session over method calls (new feature w/ new jca impl) but not anything > you get from the session, such as the sender. The session may be > associated with different physical connections on each (SFSB) call, and the > sender will be tied to the physical connection it was originally created > from. > > david jencks > > On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: > > Or perhaps I am not using the JMS resource propertly within the bean... > > > > Should I be able to save a QueueSession and QueueSender as fields and use > > them > > over multipule calls inside of a SFSB? Or do I need to recreate the > > session > > and sender each time? > > > > If that is the case it rather sucks... what a pain... > > > > --jason > > > > On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > > After thinking about this somemore, and enabling thread info in > > > > server.log > > > > > I realize now that the timer is not an issue, there is never an > > > > instance > > > > > where the timer thread attempts to use the wrapper over the SFSB... the > > > work completes too fast. > > > > > > And due to the fact that I sync'd the wrapper methods it appears that > > > > this > > > > > problem happens simply because the invoke happened in a seperate > > > > thread. > > > > > Unfortunatly it does not really narrow the problem space to debug. The > > > > JMS > > > > > RA does not function with out a TX, it does not attempt to start one if > > > there isn't one already... so it just fails. > > > > > > Is it possible that there is something a miss with the bits which setup > > > > the > > > > > tx for the SFSB? Or would I see other problems when the SFSB > > > > commits... I > > > > > think this is the case, but I am not sure. > > > > > > If that is true, and the SFSB does have a TX, then it must be the JMS > > > > RA or > > > > > JBossMQ which is at fault... and I don't really know how to isolate > > > > which > > > > > it is at this point. If I don't use the JMS RA, then I have to > > > > implement > > > > > all of the XA stuff myself, which I am sure to mess up. > > > > > > Any clue on how I could narrow the problem space any? > > > > > > I am running the same test again with trace enabled for org.jboss.mq > > > > and > > > > > org.jboss.resource.adapter.jms. With the added log messages for the > > > > JMS RA > > > > > I might be able to see a problem... but who knows. > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > > If the only cause of this can be use by multiple threads, then > > > > updating > > > > > > the error message to indicate incorrect usage would be good. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > > > > > -
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I think you are right... though it kinda sucks. I think there is something up with the current tx inside of SpySession, someone is setting it to null... could be due to my missuse, but I will find out soon enough. --jason On Friday 24 May 2002 05:54 am, Hiram Chirino wrote: > I think that would be safer. That will also allow the session to go back > into the session pool thus you will share your resources better. > > Regards, > Hiram > > From: Jason Dillon <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED], "Scott M Stark" > ><[EMAIL PROTECTED]> > >Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > >Date: Fri, 24 May 2002 00:41:03 -0700 > > > >Or perhaps I am not using the JMS resource propertly within the bean... > > > >Should I be able to save a QueueSession and QueueSender as fields and use > >them > >over multipule calls inside of a SFSB? Or do I need to recreate the > >session > >and sender each time? > > > >If that is the case it rather sucks... what a pain... > > > >--jason > > > >On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > > After thinking about this somemore, and enabling thread info in > > > >server.log > > > > > I realize now that the timer is not an issue, there is never an > > > instance where the timer thread attempts to use the wrapper over the > > > SFSB... the work completes too fast. > > > > > > And due to the fact that I sync'd the wrapper methods it appears that > > > >this > > > > > problem happens simply because the invoke happened in a seperate > > > thread. > > > > > > Unfortunatly it does not really narrow the problem space to debug. The > > > >JMS > > > > > RA does not function with out a TX, it does not attempt to start one if > > > there isn't one already... so it just fails. > > > > > > Is it possible that there is something a miss with the bits which setup > > > >the > > > > > tx for the SFSB? Or would I see other problems when the SFSB > > > commits... > > > >I > > > > > think this is the case, but I am not sure. > > > > > > If that is true, and the SFSB does have a TX, then it must be the JMS > > > RA > > > >or > > > > > JBossMQ which is at fault... and I don't really know how to isolate > > > >which > > > > > it is at this point. If I don't use the JMS RA, then I have to > > > >implement > > > > > all of the XA stuff myself, which I am sure to mess up. > > > > > > Any clue on how I could narrow the problem space any? > > > > > > I am running the same test again with trace enabled for org.jboss.mq > > > and org.jboss.resource.adapter.jms. With the added log messages for > > > the JMS > > > >RA > > > > > I might be able to see a problem... but who knows. > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > > If the only cause of this can be use by multiple threads, then > > > >updating > > > > > > the error message to indicate incorrect usage would be good. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > > > > > - Original Message - > > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > > > <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 23, 2002 8:18 PM > > > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > Does this mean we should not try to produce more meaningful error > > > > messages when this does happen... or just leave it as is? > > > > > > > > --jason > > > > > > > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > > > > I don't see sufficient justification to go beyond the spec here so > > > > > let's just leave it. > > > > > > > > > > > > > > > Scott Stark > > > > > Chief Technology Officer > > > > > JBoss Group, LLC > > > > > xxx
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I think that would be safer. That will also allow the session to go back into the session pool thus you will share your resources better. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED], "Scott M Stark" ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 00:41:03 -0700 > >Or perhaps I am not using the JMS resource propertly within the bean... > >Should I be able to save a QueueSession and QueueSender as fields and use >them >over multipule calls inside of a SFSB? Or do I need to recreate the >session >and sender each time? > >If that is the case it rather sucks... what a pain... > >--jason > > >On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > After thinking about this somemore, and enabling thread info in >server.log > > I realize now that the timer is not an issue, there is never an instance > > where the timer thread attempts to use the wrapper over the SFSB... the > > work completes too fast. > > > > And due to the fact that I sync'd the wrapper methods it appears that >this > > problem happens simply because the invoke happened in a seperate thread. > > > > Unfortunatly it does not really narrow the problem space to debug. The >JMS > > RA does not function with out a TX, it does not attempt to start one if > > there isn't one already... so it just fails. > > > > Is it possible that there is something a miss with the bits which setup >the > > tx for the SFSB? Or would I see other problems when the SFSB commits... >I > > think this is the case, but I am not sure. > > > > If that is true, and the SFSB does have a TX, then it must be the JMS RA >or > > JBossMQ which is at fault... and I don't really know how to isolate >which > > it is at this point. If I don't use the JMS RA, then I have to >implement > > all of the XA stuff myself, which I am sure to mess up. > > > > Any clue on how I could narrow the problem space any? > > > > I am running the same test again with trace enabled for org.jboss.mq and > > org.jboss.resource.adapter.jms. With the added log messages for the JMS >RA > > I might be able to see a problem... but who knows. > > > > --jason > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > If the only cause of this can be use by multiple threads, then >updating > > > the error message to indicate incorrect usage would be good. > > > > > > xxxxxxxxxxxx > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > - Original Message - > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > > <[EMAIL PROTECTED]> > > > Sent: Thursday, May 23, 2002 8:18 PM > > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > Does this mean we should not try to produce more meaningful error > > > messages when this does happen... or just leave it as is? > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > > > I don't see sufficient justification to go beyond the spec here so > > > > let's just leave it. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > xxxxxxxx > > > > - Original Message - > > > > From: "Hiram Chirino" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 23, 2002 7:45 PM > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > He who codes wins the vote. This issue does not bother me enough >to > > > > > > > > change > > > > > > > > > anything. > > > > > > > > > > Regards, > > > > > Hiram > > > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > > >Reply-To: [EMAIL PROTECTED] > > > > > >To: "'[EMAIL PROTECTED]'" > > > > > ><[EMAIL PROTECTED]> > > > > > >Subject: RE: [JBoss-dev] Seein
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I looked at the jmsra code a bit. You should be able to hold onto the session over method calls (new feature w/ new jca impl) but not anything you get from the session, such as the sender. The session may be associated with different physical connections on each (SFSB) call, and the sender will be tied to the physical connection it was originally created from. david jencks On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: > Or perhaps I am not using the JMS resource propertly within the bean... > > Should I be able to save a QueueSession and QueueSender as fields and use > them > over multipule calls inside of a SFSB? Or do I need to recreate the > session > and sender each time? > > If that is the case it rather sucks... what a pain... > > --jason > > > On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > > After thinking about this somemore, and enabling thread info in > server.log > > I realize now that the timer is not an issue, there is never an > instance > > where the timer thread attempts to use the wrapper over the SFSB... the > > work completes too fast. > > > > And due to the fact that I sync'd the wrapper methods it appears that > this > > problem happens simply because the invoke happened in a seperate > thread. > > > > Unfortunatly it does not really narrow the problem space to debug. The > JMS > > RA does not function with out a TX, it does not attempt to start one if > > there isn't one already... so it just fails. > > > > Is it possible that there is something a miss with the bits which setup > the > > tx for the SFSB? Or would I see other problems when the SFSB > commits... I > > think this is the case, but I am not sure. > > > > If that is true, and the SFSB does have a TX, then it must be the JMS > RA or > > JBossMQ which is at fault... and I don't really know how to isolate > which > > it is at this point. If I don't use the JMS RA, then I have to > implement > > all of the XA stuff myself, which I am sure to mess up. > > > > Any clue on how I could narrow the problem space any? > > > > I am running the same test again with trace enabled for org.jboss.mq > and > > org.jboss.resource.adapter.jms. With the added log messages for the > JMS RA > > I might be able to see a problem... but who knows. > > > > --jason > > > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > > If the only cause of this can be use by multiple threads, then > updating > > > the error message to indicate incorrect usage would be good. > > > > > > > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > - Original Message - > > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > > <[EMAIL PROTECTED]> > > > Sent: Thursday, May 23, 2002 8:18 PM > > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > Does this mean we should not try to produce more meaningful error > > > messages when this does happen... or just leave it as is? > > > > > > --jason > > > > > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > > > I don't see sufficient justification to go beyond the spec here so > > > > let's just leave it. > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > xxxx > > > > - Original Message - > > > > From: "Hiram Chirino" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 23, 2002 7:45 PM > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS > RA > > > > > > > > > He who codes wins the vote. This issue does not bother me enough > to > > > > > > > > change > > > > > > > > > anything. > > > > > > > > > > Regards, > > > > > Hiram > > > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > > >Reply-To: [EMAIL PROTECTED] > > > > > >To: "'[EMAIL PROTECTED]'" > > > > > ><[EMAIL PROTECTED]> > > > > > >Subject: RE: [J
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: > After thinking about this somemore, and enabling thread info in server.log > I realize now that the timer is not an issue, there is never an instance > where the timer thread attempts to use the wrapper over the SFSB... the > work completes too fast. > > And due to the fact that I sync'd the wrapper methods it appears that this > problem happens simply because the invoke happened in a seperate thread. > > Unfortunatly it does not really narrow the problem space to debug. The JMS > RA does not function with out a TX, it does not attempt to start one if > there isn't one already... so it just fails. > > Is it possible that there is something a miss with the bits which setup the > tx for the SFSB? Or would I see other problems when the SFSB commits... I > think this is the case, but I am not sure. > > If that is true, and the SFSB does have a TX, then it must be the JMS RA or > JBossMQ which is at fault... and I don't really know how to isolate which > it is at this point. If I don't use the JMS RA, then I have to implement > all of the XA stuff myself, which I am sure to mess up. > > Any clue on how I could narrow the problem space any? > > I am running the same test again with trace enabled for org.jboss.mq and > org.jboss.resource.adapter.jms. With the added log messages for the JMS RA > I might be able to see a problem... but who knows. > > --jason > > On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > > If the only cause of this can be use by multiple threads, then updating > > the error message to indicate incorrect usage would be good. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; "Scott M Stark" > > <[EMAIL PROTECTED]> > > Sent: Thursday, May 23, 2002 8:18 PM > > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > Does this mean we should not try to produce more meaningful error > > messages when this does happen... or just leave it as is? > > > > --jason > > > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > > I don't see sufficient justification to go beyond the spec here so > > > let's just leave it. > > > > > > xxxxxxxxxxxxxxxx > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > - Original Message - > > > From: "Hiram Chirino" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Thursday, May 23, 2002 7:45 PM > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > He who codes wins the vote. This issue does not bother me enough to > > > > > > change > > > > > > > anything. > > > > > > > > Regards, > > > > Hiram > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > >Reply-To: [EMAIL PROTECTED] > > > > >To: "'[EMAIL PROTECTED]'" > > > > ><[EMAIL PROTECTED]> > > > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > >Date: Fri, 24 May 2002 14:35:21 +1200 > > > > > > > > > >I understand the pros and cons, I am just saying what I feel. You > > > > > can outvote me if you wish. > > > > > > > > > >David > > > > > > > > > > > -Original Message- > > > > > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > > > > > Sent: Friday, May 24, 2002 2:14 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS > > > > > > RA > > > > > > > > > > > > > > > > > > > > > > > > Think about it this way... somebody creates a simple servlet > > > > > > that creates a
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: > If the only cause of this can be use by multiple threads, then updating > the error message to indicate incorrect usage would be good. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "Scott M Stark" > <[EMAIL PROTECTED]> > Sent: Thursday, May 23, 2002 8:18 PM > Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > Does this mean we should not try to produce more meaningful error messages > when this does happen... or just leave it as is? > > --jason > > On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > > I don't see sufficient justification to go beyond the spec here so > > let's just leave it. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxx > > ----- Original Message ----- > > From: "Hiram Chirino" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 23, 2002 7:45 PM > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > He who codes wins the vote. This issue does not bother me enough to > > > > change > > > > > anything. > > > > > > Regards, > > > Hiram > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > >Reply-To: [EMAIL PROTECTED] > > > >To: "'[EMAIL PROTECTED]'" > > > ><[EMAIL PROTECTED]> > > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > >Date: Fri, 24 May 2002 14:35:21 +1200 > > > > > > > >I understand the pros and cons, I am just saying what I feel. You can > > > >outvote me if you wish. > > > > > > > >David > > > > > > > > > -Original Message- > > > > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > > > > Sent: Friday, May 24, 2002 2:14 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS > > > > > RA > > > > > > > > > > > > > > > > > > > > Think about it this way... somebody creates a simple servlet > > > > > that creates a > > > > > unit of work by sending 2 messages and then commits the work. > > > > > Somebody that > > > > > does not know the spec to will might cache that session in a > > instance > > > > > > variable. If 2 requests come in at the same time, they will > > > > > screw each > > > > > other up seriously. The first request might commit his 2 > > > > > messages and some > > > > > of the messages the 2nd thread was creating. > > > > > > > > > > So the question is, should we try to make the session > > > > > thread-safe for the > > > > > power users out there that MIGHT know how stuff is working > > > > > under the covers. > > &g
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 8:18 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > I don't see sufficient justification to go beyond the spec here so > let's just leave it. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 23, 2002 7:45 PM > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > He who codes wins the vote. This issue does not bother me enough to > > change > > > anything. > > > > Regards, > > Hiram > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: "'[EMAIL PROTECTED]'" > > ><[EMAIL PROTECTED]> > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > >Date: Fri, 24 May 2002 14:35:21 +1200 > > > > > >I understand the pros and cons, I am just saying what I feel. You can > > >outvote me if you wish. > > > > > >David > > > > > > > -Original Message- > > > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, May 24, 2002 2:14 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > > > > > Think about it this way... somebody creates a simple servlet > > > > that creates a > > > > unit of work by sending 2 messages and then commits the work. > > > > Somebody that > > > > does not know the spec to will might cache that session in a instance > > > > variable. If 2 requests come in at the same time, they will > > > > screw each > > > > other up seriously. The first request might commit his 2 > > > > messages and some > > > > of the messages the 2nd thread was creating. > > > > > > > > So the question is, should we try to make the session > > > > thread-safe for the > > > > power users out there that MIGHT know how stuff is working > > > > under the covers. > > > > Or should we make the session check conncurent access better to let > > > > beginer user know when he has potentialy made a semantical error. > > > > > > > > Regards, > > > > Hiram > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > >Reply-To: [EMAIL PROTECTED] > > > > >To: "'[EMAIL PROTECTED]'" > > > > ><[EMAIL PROTECTED]> > > > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > > > > > > > >I hate to disagree with Scott and Hiram but I feel that just > > > > > > > > because the > > > > > > > > >spec says Sessions should only be used in 1 thread does not > > > > > > > > neccessarily > > > > > > > > >mean that we should restrict their usage as such. > > > > > > > > > >I know a Session only makes sense in the context of a single > > > > > > > > process, but > > > > > > > > >this might still entail the usage of a couple of different > > > > > > > > threads. I > > > > > > > > >don't > > > > >think we should place any restrictions on the usage of > > > > > > > > Sessions as long as > > > > > > > > >they work, and I believe making sendMessage() synchronized > > > > > > > > will do the > > > > > > > > >trick. > > > > > > > > > >This can be
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: > I don't see sufficient justification to go beyond the spec here so > let's just leave it. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Hiram Chirino" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 23, 2002 7:45 PM > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > He who codes wins the vote. This issue does not bother me enough to > > change > > > anything. > > > > Regards, > > Hiram > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: "'[EMAIL PROTECTED]'" > > ><[EMAIL PROTECTED]> > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > >Date: Fri, 24 May 2002 14:35:21 +1200 > > > > > >I understand the pros and cons, I am just saying what I feel. You can > > >outvote me if you wish. > > > > > >David > > > > > > > -Original Message- > > > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, May 24, 2002 2:14 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > > > > > Think about it this way... somebody creates a simple servlet > > > > that creates a > > > > unit of work by sending 2 messages and then commits the work. > > > > Somebody that > > > > does not know the spec to will might cache that session in a instance > > > > variable. If 2 requests come in at the same time, they will > > > > screw each > > > > other up seriously. The first request might commit his 2 > > > > messages and some > > > > of the messages the 2nd thread was creating. > > > > > > > > So the question is, should we try to make the session > > > > thread-safe for the > > > > power users out there that MIGHT know how stuff is working > > > > under the covers. > > > > Or should we make the session check conncurent access better to let > > > > beginer user know when he has potentialy made a semantical error. > > > > > > > > Regards, > > > > Hiram > > > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > > >Reply-To: [EMAIL PROTECTED] > > > > >To: "'[EMAIL PROTECTED]'" > > > > ><[EMAIL PROTECTED]> > > > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > > > > > > > >I hate to disagree with Scott and Hiram but I feel that just > > > > > > > > because the > > > > > > > > >spec says Sessions should only be used in 1 thread does not > > > > > > > > neccessarily > > > > > > > > >mean that we should restrict their usage as such. > > > > > > > > > >I know a Session only makes sense in the context of a single > > > > > > > > process, but > > > > > > > > >this might still entail the usage of a couple of different > > > > > > > > threads. I > > > > > > > > >don't > > > > >think we should place any restrictions on the usage of > > > > > > > > Sessions as long as > > > > > > > > >they work, and I believe making sendMessage() synchronized > > > > > > > > will do the > > > > > > > > >trick. > > > > > > > > > >This can be just one more area where JBoss goes "Beyond the > > > > > > > > Spec" but hey I > > > > > > > > >leave the final decision up to someone else. > > > > > > > > > >David. > > > > > > > > > >--- > > > > >Outgoing mail is certified Virus Free. > > > > >Checked by AVG anti-virus system (http://www.grisoft.com). > > > > >Version: 6.0.362 / Vi
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I don't see sufficient justification to go beyond the spec here so let's just leave it. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Hiram Chirino" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 7:45 PM Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > He who codes wins the vote. This issue does not bother me enough to change > anything. > > Regards, > Hiram > > >From: David Maplesden <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: "'[EMAIL PROTECTED]'" > ><[EMAIL PROTECTED]> > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > >Date: Fri, 24 May 2002 14:35:21 +1200 > > > >I understand the pros and cons, I am just saying what I feel. You can > >outvote me if you wish. > > > >David > > > > > -----Original Message- > > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, May 24, 2002 2:14 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > > > > > Think about it this way... somebody creates a simple servlet > > > that creates a > > > unit of work by sending 2 messages and then commits the work. > > > Somebody that > > > does not know the spec to will might cache that session in a instance > > > variable. If 2 requests come in at the same time, they will > > > screw each > > > other up seriously. The first request might commit his 2 > > > messages and some > > > of the messages the 2nd thread was creating. > > > > > > So the question is, should we try to make the session > > > thread-safe for the > > > power users out there that MIGHT know how stuff is working > > > under the covers. > > > Or should we make the session check conncurent access better to let > > > beginer user know when he has potentialy made a semantical error. > > > > > > Regards, > > > Hiram > > > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > > >Reply-To: [EMAIL PROTECTED] > > > >To: "'[EMAIL PROTECTED]'" > > > ><[EMAIL PROTECTED]> > > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > > > > > >I hate to disagree with Scott and Hiram but I feel that just > > > because the > > > >spec says Sessions should only be used in 1 thread does not > > > neccessarily > > > >mean that we should restrict their usage as such. > > > > > > > >I know a Session only makes sense in the context of a single > > > process, but > > > >this might still entail the usage of a couple of different > > > threads. I > > > >don't > > > >think we should place any restrictions on the usage of > > > Sessions as long as > > > >they work, and I believe making sendMessage() synchronized > > > will do the > > > >trick. > > > > > > > >This can be just one more area where JBoss goes "Beyond the > > > Spec" but hey I > > > >leave the final decision up to someone else. > > > > > > > >David. > > > > > > > >--- > > > >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 > > > > > > > > > >_ > >MSN Photos is the easiest way to share and print your photos: > >http://photos.msn.com/support/worldwide.aspx > > > > > >___ > > > &
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I just re-ran my tests with my wrapper object synchronized on all methods which call the SFSB and I still see invalid tx id exceptions. Which makes me think this isn't a problem with reentrance into the SFSB, but something with the JMS RA Connection/Session pooling. --jason On Thursday 23 May 2002 06:28 pm, Scott M Stark wrote: > > 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? > > Yes it should. We have a testcase for this, but how is the timer > interacting with the SFSB, through its remote/local interface? > > > 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. =( > > There can only be one thread active in a given bean instance. For session > beans and mdbs this is guarenteed since an instance is obtained for each > request. For stateful beans and entities its enforced by the container > interceptors. > If you can sketch the usage more clearly so a testcase can be created I > will do that. > > > 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? > > This should already be failing. > > 7.5.6 Serializing session bean methods > > ... > > Clients are not allowed to make concurrent calls to a stateful session > object. If a client-invoked business > > method is in progress on an instance when another client-invoked call, from > the same or different client, > > arrives at the same instance of a stateful session bean class, the > container may throw the > > java.rmi.RemoteException to the second client[4], if the client is a remote > client, or the > > javax.ejb.EJBException, if the client is a local client. This restriction > does not apply to a stateless > > session bean because the container routes each request to a different > instance of the session bean > > class. > > > > > And is there any reason why SpySession.sendMessage() should NOT be > > synchronized? > > Yes, Sessions are defined as single-threaded in the JMS spec. If your using > this inside of an EJB that should be the case. > > > > ___ > > 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
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
He who codes wins the vote. This issue does not bother me enough to change anything. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 14:35:21 +1200 > >I understand the pros and cons, I am just saying what I feel. You can >outvote me if you wish. > >David > > > -Original Message- > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 24, 2002 2:14 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > > > > > Think about it this way... somebody creates a simple servlet > > that creates a > > unit of work by sending 2 messages and then commits the work. > > Somebody that > > does not know the spec to will might cache that session in a instance > > variable. If 2 requests come in at the same time, they will > > screw each > > other up seriously. The first request might commit his 2 > > messages and some > > of the messages the 2nd thread was creating. > > > > So the question is, should we try to make the session > > thread-safe for the > > power users out there that MIGHT know how stuff is working > > under the covers. > > Or should we make the session check conncurent access better to let > > beginer user know when he has potentialy made a semantical error. > > > > Regards, > > Hiram > > > > >From: David Maplesden <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: "'[EMAIL PROTECTED]'" > > ><[EMAIL PROTECTED]> > > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > > > >I hate to disagree with Scott and Hiram but I feel that just > > because the > > >spec says Sessions should only be used in 1 thread does not > > neccessarily > > >mean that we should restrict their usage as such. > > > > > >I know a Session only makes sense in the context of a single > > process, but > > >this might still entail the usage of a couple of different > > threads. I > > >don't > > >think we should place any restrictions on the usage of > > Sessions as long as > > >they work, and I believe making sendMessage() synchronized > > will do the > > >trick. > > > > > >This can be just one more area where JBoss goes "Beyond the > > Spec" but hey I > > >leave the final decision up to someone else. > > > > > >David. > > > > > >--- > > >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 > > > > >_ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > > >___ > >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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
On Thursday 23 May 2002 07:24 pm, Scott M Stark wrote: > The last thing to clarify is are your JMS transactions spanning > multiple SFSB method calls? If they are you can be violating > the single-thread use of the session without multiple threads > being active in the SFSB because you could be commiting > from the wrong thread. No, the initial request comes in on a MDB with NotSupported and the SFSB is marked as Required. There is no other transactional context. --jason ___ 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
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I understand the pros and cons, I am just saying what I feel. You can outvote me if you wish. David > -Original Message- > From: Hiram Chirino [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 2:14 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > > > > Think about it this way... somebody creates a simple servlet > that creates a > unit of work by sending 2 messages and then commits the work. > Somebody that > does not know the spec to will might cache that session in a instance > variable. If 2 requests come in at the same time, they will > screw each > other up seriously. The first request might commit his 2 > messages and some > of the messages the 2nd thread was creating. > > So the question is, should we try to make the session > thread-safe for the > power users out there that MIGHT know how stuff is working > under the covers. > Or should we make the session check conncurent access better to let > beginer user know when he has potentialy made a semantical error. > > Regards, > Hiram > > >From: David Maplesden <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: "'[EMAIL PROTECTED]'" > ><[EMAIL PROTECTED]> > >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > >Date: Fri, 24 May 2002 13:36:43 +1200 > > > >I hate to disagree with Scott and Hiram but I feel that just > because the > >spec says Sessions should only be used in 1 thread does not > neccessarily > >mean that we should restrict their usage as such. > > > >I know a Session only makes sense in the context of a single > process, but > >this might still entail the usage of a couple of different > threads. I > >don't > >think we should place any restrictions on the usage of > Sessions as long as > >they work, and I believe making sendMessage() synchronized > will do the > >trick. > > > >This can be just one more area where JBoss goes "Beyond the > Spec" but hey I > >leave the final decision up to someone else. > > > >David. > > > >--- > >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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ 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
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Think about it this way... somebody creates a simple servlet that creates a unit of work by sending 2 messages and then commits the work. Somebody that does not know the spec to will might cache that session in a instance variable. If 2 requests come in at the same time, they will screw each other up seriously. The first request might commit his 2 messages and some of the messages the 2nd thread was creating. So the question is, should we try to make the session thread-safe for the power users out there that MIGHT know how stuff is working under the covers. Or should we make the session check conncurent access better to let beginer user know when he has potentialy made a semantical error. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 13:36:43 +1200 > >I hate to disagree with Scott and Hiram but I feel that just because the >spec says Sessions should only be used in 1 thread does not neccessarily >mean that we should restrict their usage as such. > >I know a Session only makes sense in the context of a single process, but >this might still entail the usage of a couple of different threads. I >don't >think we should place any restrictions on the usage of Sessions as long as >they work, and I believe making sendMessage() synchronized will do the >trick. > >This can be just one more area where JBoss goes "Beyond the Spec" but hey I >leave the final decision up to someone else. > >David. > >--- >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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
The last thing to clarify is are your JMS transactions spanning multiple SFSB method calls? If they are you can be violating the single-thread use of the session without multiple threads being active in the SFSB because you could be commiting from the wrong thread. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 6:49 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA > Yes it should. We have a testcase for this, but how is the timer > interacting with the SFSB, through its remote/local interface? I have a wrapper object that connects to the SFSB (home.create()) which the main thread uses to send JMS messages, which a timer also uses to send back periodic statistics on. Does each SFSB need its own thread or does it just need to be called synchronously? ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
> If anything SpySession.sendMessage() should try to detect the concurrent > access from 2 threads and throw an exception stating that the JMS spec is > being violated by the fact that 2 threads are trying to access a single > session object simulatiously. That was what I was leaning twords... any ideas on an easy way to implement that? Could the logic from the SFSB interceptor be used, or duplicated with the JBossMQ interceptors... or do they not line up like that? Or perhaps the code in the interceptor could be generalized into a helper, then used in both locations? --jason ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
> Yes it should. We have a testcase for this, but how is the timer > interacting with the SFSB, through its remote/local interface? I have a wrapper object that connects to the SFSB (home.create()) which the main thread uses to send JMS messages, which a timer also uses to send back periodic statistics on. Does each SFSB need its own thread or does it just need to be called synchronously? > There can only be one thread active in a given bean instance. For session > beans and mdbs this is guarenteed since an instance is obtained for each > request. For stateful beans and entities its enforced by the container > interceptors. Ok, this answers my question above. > If you can sketch the usage more clearly so a testcase can be created I > will do that. I will try... I have a SFSB with a reference to a Queue (and friends) using java:/JmsXA as the factory. This bean is wrapped in a POJO (to handle serialization and restoring the SFSB from HomeHandle). Then a thread is started, which starts up a timer (which is a member of the thread class impl... so each top-level thread has its own timer) which fires every 5 minutes. When it fires it sends a message with the wrapper. Then another object is created, which can start off multipule threads, doing work. When it finishes one of its threads calls back to a listener which uses the wrapper object to send a message. Once the above threads have joined, then a final message is sent back via the wrapper. So all in all there are 3+n threads all using the same wrapper object, which uses the same SFSB remote intf (haven't learned about local intf's yet). This will only happen every 200-300 top-level threads have been created... so I would guess that there is a race condition somewhere... making it difficult to make a test case. I am not seeing any exceptions related to concurrent access to the SFSB at all.. so perhaps the test case could simply be starting n threads using one SFSB and see what happens... > > And is there any reason why SpySession.sendMessage() should NOT be > > synchronized? > > Yes, Sessions are defined as single-threaded in the JMS spec. If your using > this inside of an EJB that should be the case. Perhaps this is a bug due to the Connection/Session pooling which the JMS RA does then? Meaning that the SFSB is not getting concurrently called, though it could be due to the timer (though syncing my wrapper object will tell). If multipule threads entering a SFSB will throw exceptions, then it is likly to be a JMS RA problem? --jason ___ 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
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I hate to disagree with Scott and Hiram but I feel that just because the spec says Sessions should only be used in 1 thread does not neccessarily mean that we should restrict their usage as such. I know a Session only makes sense in the context of a single process, but this might still entail the usage of a couple of different threads. I don't think we should place any restrictions on the usage of Sessions as long as they work, and I believe making sendMessage() synchronized will do the trick. This can be just one more area where JBoss goes "Beyond the Spec" but hey I leave the final decision up to someone else. David. --- 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
> 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 > > > >
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
yes. no sharing. JMS session are used to demarcate transactions. Having 2 threads demarcating transactions would not be good. Regards, Hiram >From: David Maplesden <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA >Date: Fri, 24 May 2002 13:14:04 +1200 > >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... > > > > -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 requ
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
>From: Jason Dillon <[EMAIL PROTECTED]> >... >And is there any reason why SpySession.sendMessage() should NOT be >synchronized? > If anything SpySession.sendMessage() should try to detect the concurrent access from 2 threads and throw an exception stating that the JMS spec is being violated by the fact that 2 threads are trying to access a single session object simulatiously. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
> 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? Yes it should. We have a testcase for this, but how is the timer interacting with the SFSB, through its remote/local interface? > 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. =( There can only be one thread active in a given bean instance. For session beans and mdbs this is guarenteed since an instance is obtained for each request. For stateful beans and entities its enforced by the container interceptors. If you can sketch the usage more clearly so a testcase can be created I will do that. > 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? This should already be failing. 7.5.6 Serializing session bean methods ... Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client[4], if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class. > And is there any reason why SpySession.sendMessage() should NOT be > synchronized? Yes, Sessions are defined as single-threaded in the JMS spec. If your using this inside of an EJB that should be the case. ___ 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
> 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 transac
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
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... > -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 > > > > > > > > > > > > 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 &g
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I'm not sure about best solution to the SFSB stuff. 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. 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 > > > > > > > > > > > > com.boldfish.does.worker.WorkerException: failed to send > > > message; - nested > > > throwable is: javax.jms.JMSException: Invalid transaction
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 > > > > > > > > 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)
RE: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Nothing like a cry for help to get me interested. >From a brief look at the source and from what I can remember from my work on this stuff the problem is in JBossMQ SpySession class. From what I can see the sendMessage method needs to be synchronized and I think that will solve your problem. What I guess is happening is that another thread is calling commit at the same time this thread is calling sendMessage and hence the currentTransactionID is invalid when it gets passed through to the XAResourceManager. 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. 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 > > > > 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.Tr
