Re: [JBoss-dev] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK
> This class is generated by XDoclet. Do you have any idea why it is > not generated by XDoclet ? Nope... I am still getting used to XDoclet... had a painful time trying to get merge files to work a few days ago (unsuccessfully). --jason > Thanx - Andy > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 23, 2002 9:19 PM > Subject: [JBoss-dev] HEAD jboss/testsuite missing: > org.jboss.test.foedeployer.ejb.interfaces.SecretPK > > > which is making it difficult to compile the testsuite ;) > > > > > > compile-classes-only: > > [mkdir] Created dir: > > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > > [javac] Compiling 728 source files to > > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeploye >r > > /ejb/simple/SecretBean.java:14: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeploye >r > > /ejb/simple/SecretBean.java:91: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: class > > org.jboss.test.foedeployer.ejb.simple.SecretBean > > > [javac]public SecretPK ejbCreate( String secretKey, String > > secret ) > > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foed >e > > ployer/ejb/interfaces/SecretLocalHome.java:11: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foed >e > > ployer/ejb/interfaces/SecretLocal.java:11: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foed >e > > ployer/ejb/interfaces/SecretHome.java:11: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foed >e > > ployer/ejb/interfaces/Secret.java:11: > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > > > > > --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 ___ 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] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK
Hehe, I just didn't build it with -Djavac.excludes='org/jboss/test/foedeployer/**' Thanks though. --jason On Thursday 23 May 2002 10:02 pm, David Jencks wrote: > It's a string. I'll check in the fix. Annoying. > > david > > On 2002.05.24 00:19:44 -0400 Jason Dillon wrote: > > which is making it difficult to compile the testsuite ;) > > > > > > compile-classes-only: > > [mkdir] Created dir: > > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > > [javac] Compiling 728 source files to > > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeplo > >yer/ejb/simple/SecretBean.java:14: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeplo > >yer/ejb/simple/SecretBean.java:91: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: class > > org.jboss.test.foedeployer.ejb.simple.SecretBean [javac]public > > SecretPK ejbCreate( String secretKey, String secret ) > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/fo > >edeployer/ejb/interfaces/SecretLocalHome.java:11: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/fo > >edeployer/ejb/interfaces/SecretLocal.java:11: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/fo > >edeployer/ejb/interfaces/SecretHome.java:11: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > [javac] > > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/fo > >edeployer/ejb/interfaces/Secret.java:11: > > > > cannot resolve symbol > > [javac] symbol : class SecretPK > > [javac] location: package interfaces > > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > > [javac] ^ > > > > > > --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 > > ___ > > 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] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK
Hi Jason This class is generated by XDoclet. Do you have any idea why it is not generated by XDoclet ? Thanx - Andy - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 9:19 PM Subject: [JBoss-dev] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK > which is making it difficult to compile the testsuite ;) > > > compile-classes-only: > [mkdir] Created dir: > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > [javac] Compiling 728 source files to > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer /ejb/simple/SecretBean.java:14: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer /ejb/simple/SecretBean.java:91: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: class org.jboss.test.foedeployer.ejb.simple.SecretBean > [javac]public SecretPK ejbCreate( String secretKey, String secret ) > [javac] ^ > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foede ployer/ejb/interfaces/SecretLocalHome.java:11: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foede ployer/ejb/interfaces/SecretLocal.java:11: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foede ployer/ejb/interfaces/SecretHome.java:11: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foede ployer/ejb/interfaces/Secret.java:11: > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > > > --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 > > ___ 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] Will con.getBeanMetaData().getEjbName() be unique across all beans in a VM?
This is not unique across all beans in a vm, only within the ejb-jar. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 9:44 PM Subject: [JBoss-dev] Will con.getBeanMetaData().getEjbName() be unique across all beans in a VM? I am wondering if this is the case, if an EJB's name will be unique across all other bean's deployed in the vm... or if the name only has to be unique inside of a ejb-jar deployment. The current file-based SFSBPM uses the bean's name to determine the directory to store session state files. If it is not unique then two SFSB beans with the same name could collide here... or rather when the second bean container is started, the PM will erase any state files in the storage directory, which means that any passivated beans from the first container are now screwed. The fix is easy, but I am not sure if it is needed. Anyone know? --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 ___ 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] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK
It's a string. I'll check in the fix. Annoying. david On 2002.05.24 00:19:44 -0400 Jason Dillon wrote: > which is making it difficult to compile the testsuite ;) > > > compile-classes-only: > [mkdir] Created dir: > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > [javac] Compiling 728 source files to > /home/jason/ws/jboss/jboss-all/testsuite/output/classes > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:14: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:91: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: class org.jboss.test.foedeployer.ejb.simple.SecretBean > [javac]public SecretPK ejbCreate( String secretKey, String secret > ) > [javac] ^ > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocalHome.java:11: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocal.java:11: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretHome.java:11: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > [javac] > >/home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/Secret.java:11: > > cannot resolve symbol > [javac] symbol : class SecretPK > [javac] location: package interfaces > [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; > [javac] ^ > > > --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 > > ___ 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
[JBoss-dev] Will con.getBeanMetaData().getEjbName() be unique across all beans in a VM?
I am wondering if this is the case, if an EJB's name will be unique across all other bean's deployed in the vm... or if the name only has to be unique inside of a ejb-jar deployment. The current file-based SFSBPM uses the bean's name to determine the directory to store session state files. If it is not unique then two SFSB beans with the same name could collide here... or rather when the second bean container is started, the PM will erase any state files in the storage directory, which means that any passivated beans from the first container are now screwed. The fix is easy, but I am not sure if it is needed. Anyone know? --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
[JBoss-dev] HEAD jboss/testsuite missing: org.jboss.test.foedeployer.ejb.interfaces.SecretPK
which is making it difficult to compile the testsuite ;) compile-classes-only: [mkdir] Created dir: /home/jason/ws/jboss/jboss-all/testsuite/output/classes [javac] Compiling 728 source files to /home/jason/ws/jboss/jboss-all/testsuite/output/classes [javac] /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:14: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: package interfaces [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [javac] ^ [javac] /home/jason/ws/jboss/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:91: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: class org.jboss.test.foedeployer.ejb.simple.SecretBean [javac]public SecretPK ejbCreate( String secretKey, String secret ) [javac] ^ [javac] /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocalHome.java:11: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: package interfaces [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [javac] ^ [javac] /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocal.java:11: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: package interfaces [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [javac] ^ [javac] /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretHome.java:11: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: package interfaces [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [javac] ^ [javac] /home/jason/ws/jboss/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/Secret.java:11: cannot resolve symbol [javac] symbol : class SecretPK [javac] location: package interfaces [javac] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [javac] ^ --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] Need to create service with its UCL
No, because we currently seperate the creation of the DeploymentInfo from the creation of its UCL. I'll leave the DeploymentInfo as is for now. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 8:15 PM Subject: Re: [JBoss-dev] Need to create service with its UCL > I think I need to think about this some more... couldn't we make > DeploymentInfo extend UCL instead of having a reference to it? Anyway, I > think the need to have DeploymentInfo an mbean is not all that pressing, I > will worry about it later. > > david jencks > > On 2002.05.23 22:55:15 -0400 Scott M Stark wrote: > > No, unfortunately not because the JMX server just casts the > > mbean for the class loader into a ClassLoader instance. I can > > make the DeploymentInfo an MBean that exposes the UCL > > for one stop shopping while I'm mucking around in here, but > > the UCL mbean for the service still needs to be registered > > independently. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "David Jencks" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 23, 2002 7:39 PM > > Subject: Re: [JBoss-dev] Need to create service with its UCL > > > > > > > The UCL are in almost 1-1 correspondence with DeploymentInfo, which > > also > > > needs to be an mbean IMO for various reasons. Is there some way we > > could > > > make both into the same mbean? > > > > > > david jencks > > > > > > On 2002.05.23 22:10:01 -0400 Scott M Stark wrote: > > > > Right now services have no mechanism to uniquely load resources > > > > located in their sar because the UCL of the sar is not specified > > > > as the loader in the JMX createMBean call. To do this the UCLs > > > > would have to be made MBeans as that is what is required by > > > > the createMBean call signature. It seems like an unnecessary > > > > number of mbeans, but only the service UCLs would actually > > > > need to be registered. Any feedback before I do this? > > > > > > > > > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > > > > > > > > > > > > > ___ > > > > > > > > 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 > > > > > > > > > ___ > > > > 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 > ___ 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 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 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 Conf
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 / 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 > > > > > > > >
Re: [JBoss-dev] Need to create service with its UCL
I think I need to think about this some more... couldn't we make DeploymentInfo extend UCL instead of having a reference to it? Anyway, I think the need to have DeploymentInfo an mbean is not all that pressing, I will worry about it later. david jencks On 2002.05.23 22:55:15 -0400 Scott M Stark wrote: > No, unfortunately not because the JMX server just casts the > mbean for the class loader into a ClassLoader instance. I can > make the DeploymentInfo an MBean that exposes the UCL > for one stop shopping while I'm mucking around in here, but > the UCL mbean for the service still needs to be registered > independently. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 23, 2002 7:39 PM > Subject: Re: [JBoss-dev] Need to create service with its UCL > > > > The UCL are in almost 1-1 correspondence with DeploymentInfo, which > also > > needs to be an mbean IMO for various reasons. Is there some way we > could > > make both into the same mbean? > > > > david jencks > > > > On 2002.05.23 22:10:01 -0400 Scott M Stark wrote: > > > Right now services have no mechanism to uniquely load resources > > > located in their sar because the UCL of the sar is not specified > > > as the loader in the JMX createMBean call. To do this the UCLs > > > would have to be made MBeans as that is what is required by > > > the createMBean call signature. It seems like an unnecessary > > > number of mbeans, but only the service UCLs would actually > > > need to be registered. Any feedback before I do this? > > > > > > > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > > > > > > > ___ > > > > > > 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 > > > > > ___ > > 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] Log4jService.start() vs. Log4jService.create()
OK, now I finally read the subject. This should be fine. Sorry for the noise. david On 2002.05.23 22:44:10 -0400 Jason Dillon wrote: > > create() of what??? > > start() currently creates and starts the thread which handles detection > of > changes in the log4j.xml file (or whatever it is configured to use) and > reconfiguring Log4j. > > Since we call create() on everything before start(), customized logging > (such > as logging to server.log), will not be enabled until everything has been > created, thus some logs are lost. > > > create methods aren't supposed to reference anything outside the > current > > mbean, there is no reason to suppose it is there. > > I think we are safe here, it only talks to Log4j, which it is control of. > > > Is this going to involve using an mbean before it has gone through the > > start lifecycle event? If so, is there some other way to get the > effect > > you want? > > No, should not. No thing really uses Log4jService... except users who > need to > reconfigure or change logging levels on the fly. > > --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 > > ___ 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
[JBoss-dev] [ jboss-Bugs-506914 ] Problem with Increased Memory ocupation
Bugs item #506914, was opened at 2002-01-22 06:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=506914&group_id=22866 Category: JBossMQ Group: v2.4 (stable) >Status: Pending Resolution: None Priority: 5 Submitted By: Cesar Hernandez Fuente (chfuente) Assigned to: Andreas Schaefer (schaefera) Summary: Problem with Increased Memory ocupation Initial Comment: A publisher connect and disconnect each time that want to put a message into a topic. Each time that this operation is acompliesed cosumes few kbytes of memory and the memory allocated isn´t released once the publisher is disconnected, so the memory cosume increases and increases ... and .. until the system crash. thanks. -- >Comment By: Hiram Chirino (chirino) Date: 2002-05-23 22:00 Message: Logged In: YES user_id=175851 2.4.5 included many memory fixes. Could you validate that it has fixed your problems??? -- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-06 13:59 Message: Logged In: NO Hi, I am tracking similar problems with memory leaks. We are publishing messages across JBoss and it doesn't seem to be freeing the messages once they are used. Here are the top 20 SITES in the profiler AFTER all clients had disconnected and I'd waited an hour for any timeouts to throw the stuff away. BTW this is after sending 13621 messages. If you want the whole thing I can gladly mail extra infos. percent live alloc'ed stack class rank self accumbytes objs bytes objs trace name 1 67.03% 67.03% 29855784 13621 34440064 15713 18474 [B 2 3.18% 70.21% 1416584 13621 1634152 15713 18471 org.jboss.mq.SpyObjectMessage 3 2.95% 73.16% 1315392 27404 2489040 51855 13605 [C 4 2.46% 75.63% 1097928 13694 1448696 18078 13601 [C 5 2.21% 77.84% 984744 41031 1245072 51878 13602 java.lang.String 6 1.71% 79.55% 762776 13621 883624 15779 17371 java.util.Hashtable$Entry 7 1.71% 81.26% 762776 13621 1000776 17871 17368 [C 8 1.22% 82.49% 544840 13621 628520 15713 18473 java.util.Hashtable 9 1.18% 83.66% 5243041 5243041 9394 [B 10 0.98% 84.64% 435808 13619 437088 13659 18551 java.util.TreeMap$Entry 11 0.73% 85.38% 326904 13621 378696 15779 17369 java.lang.String 12 0.73% 86.11% 326904 13621 378696 15779 17366 org.jboss.mq.SpyQueue 13 0.34% 86.45% 150144 1019 150144 1019 329 [B 14 0.33% 86.77% 145688 2587 145912 2589 140 [C 15 0.25% 87.03% 113496 2413 292376 6694 2728 [C 16 0.25% 87.28% 110128 830 10190120 6989069 [C 17 0.24% 87.51% 106288 16 3214944 1019 269 [B 18 0.20% 87.72%91272 769 379592 2655 2224 [C 19 0.18% 87.90%81536 945 81536 945 132 [C -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=506914&group_id=22866 ___ 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
[JBoss-dev] [ jboss-Bugs-501820 ] Inconsistent behavior for non-tx queues
Bugs item #501820, was opened at 2002-01-10 09:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501820&group_id=22866 Category: JBossMQ Group: v2.4 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Corby (corby) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent behavior for non-tx queues Initial Comment: I have observed this problem in JBoss 2.4.4-Catalina, running on Windows 2000. I have an MDB that receives messages from a queue, Q1, for messages. It attempts to process the message, and this processing involves numerous database writes. If something goes wrong with the processing, then I wish to rollback my database updates, and copy the message into a second queue, Q2. I never want to rollback operations on Q1 or Q2. So I declare my database to be a managed resource for my MDB, but I do not declare Q1 or Q2 to be managed resources. And I use a non-XA connection factory to retrieve my queue connections. When my MDB uses bean-managed transactions, it behaves exactly as I expect. That is, committing or rolling back the transaction will determine whether or not writes occur to the database, but it has no effect on whether a message is pulled out of Q1 or sent into Q2. But when my MDB uses container-managed transactions, the behavior is inconsistent. Committing the transaction causes it to behave as expected. But if I call setRollbackOnly() on the MessageDrivenContext, it rolls back the datasource AND Q1, but not Q2. (Of course, this causes the message to infinitely redeliver, process with error, and successfully forward on to Q2). I think this is a bug, and that the bean should not rollback Q1 when it is CMT, just like it doesn't when it is BMT. -- >Comment By: Hiram Chirino (chirino) Date: 2002-05-23 21:56 Message: Logged In: YES user_id=175851 If you use a container-managed transactions the message delivery is part of the transaction that you are rolling back. Declaring Q1 or Q2 ot be managed or non-managed resources has no effect. The Connection that puts a message to Q2 is obviously not an JCA RA obtainted connection since it's transaction was not elisted with the Transaction Manager. All the behavior you have described is conforment to the EJB spec. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=501820&group_id=22866 ___ 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 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 > > > > > >___ > > > >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
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] Need to create service with its UCL
No, unfortunately not because the JMX server just casts the mbean for the class loader into a ClassLoader instance. I can make the DeploymentInfo an MBean that exposes the UCL for one stop shopping while I'm mucking around in here, but the UCL mbean for the service still needs to be registered independently. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 7:39 PM Subject: Re: [JBoss-dev] Need to create service with its UCL > The UCL are in almost 1-1 correspondence with DeploymentInfo, which also > needs to be an mbean IMO for various reasons. Is there some way we could > make both into the same mbean? > > david jencks > > On 2002.05.23 22:10:01 -0400 Scott M Stark wrote: > > Right now services have no mechanism to uniquely load resources > > located in their sar because the UCL of the sar is not specified > > as the loader in the JMX createMBean call. To do this the UCLs > > would have to be made MBeans as that is what is required by > > the createMBean call signature. It seems like an unnecessary > > number of mbeans, but only the service UCLs would actually > > need to be registered. Any feedback before I do this? > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > > > ___ > > > > 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 > ___ 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] Log4jService.start() vs. Log4jService.create()
> create() of what??? start() currently creates and starts the thread which handles detection of changes in the log4j.xml file (or whatever it is configured to use) and reconfiguring Log4j. Since we call create() on everything before start(), customized logging (such as logging to server.log), will not be enabled until everything has been created, thus some logs are lost. > create methods aren't supposed to reference anything outside the current > mbean, there is no reason to suppose it is there. I think we are safe here, it only talks to Log4j, which it is control of. > Is this going to involve using an mbean before it has gone through the > start lifecycle event? If so, is there some other way to get the effect > you want? No, should not. No thing really uses Log4jService... except users who need to reconfigure or change logging levels on the fly. --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] Log4jService.start() vs. Log4jService.create()
Log4jService has no references to other mbeans. It was doing this in the low level preRegister callback before so its safe. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 7:33 PM Subject: Re: [JBoss-dev] Log4jService.start() vs. Log4jService.create() > create() of what??? > > create methods aren't supposed to reference anything outside the current > mbean, there is no reason to suppose it is there. > > Is this going to involve using an mbean before it has gone through the > start lifecycle event? If so, is there some other way to get the effect > you want? > > david jencks > > > On 2002.05.23 22:01:20 -0400 Jason Dillon wrote: > > Should we move the config thread into create() so it will startup and > > re-config the logging system as specifided by log4j.xml so that we get > > persisted logs sooner? > > > > --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 > > > > > > ___ > > 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] Need to create service with its UCL
The UCL are in almost 1-1 correspondence with DeploymentInfo, which also needs to be an mbean IMO for various reasons. Is there some way we could make both into the same mbean? david jencks On 2002.05.23 22:10:01 -0400 Scott M Stark wrote: > Right now services have no mechanism to uniquely load resources > located in their sar because the UCL of the sar is not specified > as the loader in the JMX createMBean call. To do this the UCLs > would have to be made MBeans as that is what is required by > the createMBean call signature. It seems like an unnecessary > number of mbeans, but only the service UCLs would actually > need to be registered. Any feedback before I do this? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > ___ > > 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
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] JMS related; not sure if this is a problem, but it is odd...
It's ok. The message was being displayed before the message was added. >From: Jason Dillon <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: "'[EMAIL PROTECTED]'" ><[EMAIL PROTECTED]> >Subject: [JBoss-dev] JMS related; not sure if this is a problem, but it is >odd... >Date: Thu, 23 May 2002 19:10:48 -0700 > >I enabled DEBUG for org.jboss.mq, and I see logs like: > >Andy, a message just got queued in >org.jboss.mq.server.PersistentQueue@c7e8a7, >queue size is: 0 > >I have not even looked at the code, but after you add something to a queue, >the size should be > 0 right? > >--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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ 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] StatefulSessionPersistenceManager.createSession()
createID on the SFSBPM 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 7:30 PM Subject: Re: [JBoss-dev] StatefulSessionPersistenceManager.createSession() I would like to fix this... so either let the container make the unique key and let the PM translate as needed, or expose a createID on the SFSBPM interface... any preferences? --jason On Thursday 23 May 2002 12:04 am, Scott M Stark wrote: > The container would then have to know how to create unique > session keys for the store which is something it should not have > to know how to do. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 21, 2002 7:44 PM > Subject: [JBoss-dev] StatefulSessionPersistenceManager.createSession() > > > Any reason why this method defined in the PM interface? > > The one instance of StatefulSessionPersistenceManager > (StatefulSessionFilPersistenceManager) does not really do anything file > specific... and I can not really see why any other impl which have to do > anything specific on creation here either... unless that is I am missing > something. > > Am I? Or does it make more sence to move createSession() into the > container impl, so the pm impl can be freed from this seeminly unrelated > burden? > > --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 > > > > ___ > > 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 ___ 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] Log4jService.start() vs. Log4jService.create()
create() of what??? create methods aren't supposed to reference anything outside the current mbean, there is no reason to suppose it is there. Is this going to involve using an mbean before it has gone through the start lifecycle event? If so, is there some other way to get the effect you want? david jencks On 2002.05.23 22:01:20 -0400 Jason Dillon wrote: > Should we move the config thread into create() so it will startup and > re-config the logging system as specifided by log4j.xml so that we get > persisted logs sooner? > > --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 > > ___ 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] StatefulSessionPersistenceManager.createSession()
I would like to fix this... so either let the container make the unique key and let the PM translate as needed, or expose a createID on the SFSBPM interface... any preferences? --jason On Thursday 23 May 2002 12:04 am, Scott M Stark wrote: > The container would then have to know how to create unique > session keys for the store which is something it should not have > to know how to do. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 21, 2002 7:44 PM > Subject: [JBoss-dev] StatefulSessionPersistenceManager.createSession() > > > Any reason why this method defined in the PM interface? > > The one instance of StatefulSessionPersistenceManager > (StatefulSessionFilPersistenceManager) does not really do anything file > specific... and I can not really see why any other impl which have to do > anything specific on creation here either... unless that is I am missing > something. > > Am I? Or does it make more sence to move createSession() into the > container impl, so the pm impl can be freed from this seeminly unrelated > burden? > > --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 > > > > ___ > > 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] Log4jService.start() vs. Log4jService.create()
Yes, log4j.properties. Looking it it closer it is consistent. Its just
the line wrapping from the MainDeployer suddenly changing to
single lines that threw me off.
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Scott M Stark"
<[EMAIL PROTECTED]>
Sent: Thursday, May 23, 2002 7:18 PM
Subject: Re: [JBoss-dev] Log4jService.start() vs. Log4jService.create()
log4j.properties you mean ;)
I did not realize they were not in sync...
Branch_3_0 shows system/src/resources/log4j.properties and
server/src/etc/conf/default/log4j.xml both use:
%d{ABSOLUTE} %-5p [%c{1}] %m%n
Where do you see them differ?
--jason
On Thursday 23 May 2002 07:11 pm, Scott M Stark wrote:
> Yes, that would help. It would also help to get the jndi.properties
> console format in synch with the log4j.xml as currently it seems
> to be discontinous when the reconfig occurs.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 23, 2002 7:01 PM
> Subject: [JBoss-dev] Log4jService.start() vs. Log4jService.create()
>
>
> Should we move the config thread into create() so it will startup and
> re-config the logging system as specifided by log4j.xml so that we get
> persisted logs sooner?
>
> --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
>
>
>
> ___
>
> 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
___
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] Log4jService.start() vs. Log4jService.create()
log4j.properties you mean ;)
I did not realize they were not in sync...
Branch_3_0 shows system/src/resources/log4j.properties and
server/src/etc/conf/default/log4j.xml both use:
%d{ABSOLUTE} %-5p [%c{1}] %m%n
Where do you see them differ?
--jason
On Thursday 23 May 2002 07:11 pm, Scott M Stark wrote:
> Yes, that would help. It would also help to get the jndi.properties
> console format in synch with the log4j.xml as currently it seems
> to be discontinous when the reconfig occurs.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 23, 2002 7:01 PM
> Subject: [JBoss-dev] Log4jService.start() vs. Log4jService.create()
>
>
> Should we move the config thread into create() so it will startup and
> re-config the logging system as specifided by log4j.xml so that we get
> persisted logs sooner?
>
> --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
>
>
>
> ___
>
> 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] Need to create service with its UCL
I don't think number of MBeans should be an issue... we will just get more and more. The only downside is that until we have a better GUI to nav these it will be messy. --jason On Thursday 23 May 2002 07:10 pm, Scott M Stark wrote: > Right now services have no mechanism to uniquely load resources > located in their sar because the UCL of the sar is not specified > as the loader in the JMX createMBean call. To do this the UCLs > would have to be made MBeans as that is what is required by > the createMBean call signature. It seems like an unnecessary > number of mbeans, but only the service UCLs would actually > need to be registered. Any feedback before I do this? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > ___ > > 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
[JBoss-dev] JMS related; not sure if this is a problem, but it is odd...
I enabled DEBUG for org.jboss.mq, and I see logs like: Andy, a message just got queued in org.jboss.mq.server.PersistentQueue@c7e8a7, queue size is: 0 I have not even looked at the code, but after you add something to a queue, the size should be > 0 right? --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] Log4jService.start() vs. Log4jService.create()
Yes, that would help. It would also help to get the jndi.properties console format in synch with the log4j.xml as currently it seems to be discontinous when the reconfig occurs. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 7:01 PM Subject: [JBoss-dev] Log4jService.start() vs. Log4jService.create() Should we move the config thread into create() so it will startup and re-config the logging system as specifided by log4j.xml so that we get persisted logs sooner? --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 ___ 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
[JBoss-dev] Need to create service with its UCL
Right now services have no mechanism to uniquely load resources located in their sar because the UCL of the sar is not specified as the loader in the JMX createMBean call. To do this the UCLs would have to be made MBeans as that is what is required by the createMBean call signature. It seems like an unnecessary number of mbeans, but only the service UCLs would actually need to be registered. Any feedback before I do this? Scott Stark Chief Technology Officer JBoss Group, LLC ___ 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
[JBoss-dev] Log4jService.start() vs. Log4jService.create()
Should we move the config thread into create() so it will startup and re-config the logging system as specifided by log4j.xml so that we get persisted logs sooner? --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
> 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
[JBoss-dev] [ jboss-Bugs-559018 ] CMR table column name wrong
Bugs item #559018, was opened at 2002-05-22 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559018&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Vincent Zhao (vincentzhao) Assigned to: Nobody/Anonymous (nobody) Summary: CMR table column name wrong Initial Comment: In your "cmp-example", the jbosscmp-jdbc.xml file, it reads: lineitem-belongsto- order ordernumber ORDER_NUMBER It seems in the LINE_ITEM table, it should has a column named "ORDER_NUMBER", but in fact it is named "order". -- Comment By: Johnny Zhou (johnnyzhou) Date: 2002-05-24 09:32 Message: Logged In: YES user_id=551174 This will cause user cannot specify the foreign key column name. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559018&group_id=22866 ___ 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 > > > > 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 dow
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 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 > > > >
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 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.
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 > > > 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$Co
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 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.i
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
Re: [JBoss-dev] Task#51309, Xdoclet2WebService
What section is it in, or what is the url to the task. --jason On Thursday 23 May 2002 04:57 pm, Frederick N. Brier wrote: > How do I get assigned a task? I'm trying to take a swag at #51309. Thank > you. > > Fred. > > > ___ > > 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
[JBoss-dev] Task#51309, Xdoclet2WebService
How do I get assigned a task? I'm trying to take a swag at #51309. Thank you. Fred. ___ 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
[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(SpyXAResourceManager.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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:823) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:266) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) 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 $Proxy23.send(Unknown Source) ___ 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
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [jmxdoclet] Generating output for 'org.jboss.test.jmx.mbean.TestMBClassLoader' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/tools/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. compile-proxycompiler-bean-sources: [execmodules] Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Running [xdoclet] Running [xdoclet] Running [xdoclet] Running [xdoclet] Running [xdoclet] Running compile-classes-only: [javac] Compiling 16 source files to /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/classes [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:14: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: package interfaces [execmodules] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/src/main/org/jboss/test/foedeployer/ejb/simple/SecretBean.java:91: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: class org.jboss.test.foedeployer.ejb.simple.SecretBean [execmodules]public SecretPK ejbCreate( String secretKey, String secret ) [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocalHome.java:11: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: package interfaces [execmodules] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretLocal.java:11: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: package interfaces [execmodules] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/SecretHome.java:11: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: package interfaces [execmodules] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/output/gen-src/org/jboss/test/foedeployer/ejb/interfaces/Secret.java:11: cannot resolve symbol [execmodules] symbol : class SecretPK [execmodules] location: package interfaces [execmodules] import org.jboss.test.foedeployer.ejb.interfaces.SecretPK; [execmodules] ^ [execmodules] 6 errors BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/testsuite/build.xml:761: Compile failed, messages should have been provided. Total time: 1 minute 13 seconds ___ 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
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 24-May-2002
Number of tests run: 737 Successful tests: 576 Errors:155 Failures: 6 [time of test: 23 May 2002 0:44 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20010626 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20010626/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ 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] EJBObject.remove() on a removed SFSB
So is there an easy solution to this? I was thinking that my problem could be resolved in an interceptor, where if any call comes through on an EJBObject after EJBObject.remove() has been called then a java.rmi.NoSuchObjectException could be thrown. Or perhaps there is also something like this implemented for application methods, and only the remove() method needs to be special cased. It should be easy to add the NSOE to the container bits to handle the EJBObject.remove() case though. --jason On Wednesday 22 May 2002 11:59 pm, Sacha Labourey wrote: > I spoke about it two days ago with Bill and I think we have different > problems with remove methods. > > Take the home.remove call on EB: This is transformed in a remote.remove > call *inside* the client proxy (trick)! This has two problems: > - anyone implementing server side interceptors won't be able to intercept > this call has a home invocation and will not be able to differentiate > home.remove calls from remote.remote calls. > - when the pk no more exists, home.remove(pk) should simply raise an > NoSuchObjectException. That is absolutely not the case right now. Right > now: - the transaction is rollbacked!!! > - the excetpion is wrapped in a TransactionRollbackedException! > > to test this behaviour, simply add something like this for a test: > myHome.remove (1); > myHome.remove (1); > > Depending if a bean with pk=1 existed, either the first or the second call > will abruptly fail. > > I've seen that no test covers this case in the testsuite. > > IMHO, the client proxy shouldn't reinterpret the home.remove(pk) in > remote.remove(). > > Cheers, > > > Sacha > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Scott M Stark > > Envoyé : jeudi, 23 mai 2002 08:57 > > À : [EMAIL PROTECTED] > > Objet : Re: [JBoss-dev] EJBObject.remove() on a removed SFSB > > > > > > There should be a java.rmi.NoSuchObjectException: > > > > When the client calls remove on the home or component interface to remove > > the session > > object, the container issues ejbRemove() on the bean instance. > > This ends the > > life of the session > > bean instance and the associated session object. Any subsequent attempt > > by its client to > > invoke the session object causes the java.rmi.NoSuchObjectException to be > > thrown > > if the client is a remote client, or the > > javax.ejb.NoSuchObjectLocalException if > > the client is a local client. (The java.rmi.NoSuchObjectException is a > > subclass of > > the java.rmi.RemoteException; the javax.ejb.NoSuchObjectLocalException > > is a subclass of the javax.ejb.EJBException). The ejbRemove() method > > cannot be called when the instance is participating in a transaction. An > > attempt to remove a > > session object while the object is in a transaction will cause > > the container > > to throw the > > javax.ejb.RemoveException to the client. Note that a container can also > > invoke the > > ejbRemove() method on the instance without a client call to remove the > > session object > > after the lifetime of the EJB object has expired. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, May 21, 2002 7:35 PM > > Subject: [JBoss-dev] EJBObject.remove() on a removed SFSB > > > > > > Should calling EJBObject.remove() on a SFSB which has been removed > > already throw an exception or should the request be silently ignored? > > > > I was running into a problem which was due to one of my > > finializers removing > > a > > SFSB, which I had previously removed and forgot to null. Currently when > > this > > happens an erronious activation exception is thrown, since there > > is no state > > file for the bean (having been removed already). > > > > I think it would be a good idea to throw a meaningful exception in > > StatefulSessionContainer.remove() to indicate the illegal state... unless > > the > > spec says we should ignore this. I have not checked the spec. > > The Javadoc > > for EJBObject.remove() does not provide any insight either. > > > > Does anyone know what the behavior should be, exception or non-exception? > > And > > if it is an exception what flavor? > > > > --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 ___ Don't miss the 2002 Sprint PCS Application Developer
Re: [JBoss-dev] StatefulSessionPersistenceManager.createSession()
The container can create a unique key, then the PM can tranlsate it as needed/if needed. Or the PM could expose a createID() instead of createSession(), letting the container do the rest of the work. --jason On Thursday 23 May 2002 12:04 am, Scott M Stark wrote: > The container would then have to know how to create unique > session keys for the store which is something it should not have > to know how to do. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 21, 2002 7:44 PM > Subject: [JBoss-dev] StatefulSessionPersistenceManager.createSession() > > > Any reason why this method defined in the PM interface? > > The one instance of StatefulSessionPersistenceManager > (StatefulSessionFilPersistenceManager) does not really do anything file > specific... and I can not really see why any other impl which have to do > anything specific on creation here either... unless that is I am missing > something. > > Am I? Or does it make more sence to move createSession() into the > container impl, so the pm impl can be freed from this seeminly unrelated > burden? > > --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 > > > > ___ > > 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-May-2002
Number of tests run: 593
Successful tests: 593
Errors:0
Failures: 0
[time of test: 23 May 2002 12:28 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
HURRAY - everything worked!
Thanks for all your effort - we really do love you!
___
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: RE: [JBoss-dev] Open-Source Fight Flares At Pentagon
I suppose they must be using data from that new study that shows that security through obscurity actually works...ha ha > > From: "Mike Finn" <[EMAIL PROTECTED]> > Date: 2002/05/23 Thu PM 02:14:21 EDT > To: <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]> > Subject: RE: [JBoss-dev] Open-Source Fight Flares At Pentagon > > They are so cute when they try to convince the world their platforms are > more secure > > I thought I'd share my favorites: > > "I've never seen a systematic study that showed open source to be more > secure," said Dorothy Denning, a professor of computer science at Georgetown > University who specializes in information warfare. > --- Is there a systematic study that says they were less secure??? What a > bozo statement. > > "Microsoft's push is a new front in a long-running company assault on the > open-source movement, which company officials have called "a cancer" and > un-American." > un-American? In the sense that "American" means anything MS profits from, I > guess. > a Cancer? No wonder I feel dirty. I liken those f&%^#ing macro viruses more > to a cancer than anything else. > > "Microsoft also said open-source software is inherently less secure because > the code is available for the world to examine for flaws, making it possible > for hackers or criminals to exploit them. Proprietary software, the company > argued, is more secure because of its closed nature." > > Hmm. If they say it, it must be true. Just more FUD-rhetoric. Nevermind > that there are (I would argue) FAR more well-meaning folks testing OSS > software than ill-meaning ones. > > #mike > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Thursday, May 23, 2002 1:45 PM > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: [JBoss-dev] Open-Source Fight Flares At Pentagon > > > Microsoft tries to squelch Open Source at the pentagon, but apparently many > at the pentagon are seeing the light. > > http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html > > > > > ___ > > 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 > ___ 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-user] RE: [JBoss-dev] Open-Source Fight Flares At Pentagon
Mike Finn wrote:
>
> "Microsoft also said open-source software is inherently less secure because
> the code is available for the world to examine for flaws, making it possible
> for hackers or criminals to exploit them. Proprietary software, the company
> argued, is more secure because of its closed nature."
>
Umm, yah, that's why it took until NT4 for them to fix that neat little
LanManager hash issue - where the password hash sent over the LAN was
cleartext equivalent.
I wonder if Microsoft's developers really believe that it's that hard to
reverse engineer weak algorythms. Apparently 'more secure' is equivalent
to "I can't tell if there are any backdoors because I don't have the
source." Maybe, "It must be more secure: I can't verify that it's
mathematically correct!"
The same principal is why science done by hermits in mountain hideaways
has been so much more influential to modern technology than science done
openly in an environment where peer review and reproduction of
experimental results is critical to acceptance.
pfah! First they take bad engineering ("Windows won't run without
Internet Explorer") and use it as an excuse for monopolistic practices,
and then they take bad security practices ("If we tell them how it
works, they'll break it") and try to make it a virtue!
Hrm... Here's the loaded question for Microsoft's talking heads: "If
open source security is so bad, why did you use kerberos under Windows
2000?"
OK, back to work.
-danch
___
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] Open-Source Fight Flares At Pentagon
They are so cute when they try to convince the world their platforms are more secure I thought I'd share my favorites: "I've never seen a systematic study that showed open source to be more secure," said Dorothy Denning, a professor of computer science at Georgetown University who specializes in information warfare. --- Is there a systematic study that says they were less secure??? What a bozo statement. "Microsoft's push is a new front in a long-running company assault on the open-source movement, which company officials have called "a cancer" and un-American." un-American? In the sense that "American" means anything MS profits from, I guess. a Cancer? No wonder I feel dirty. I liken those f&%^#ing macro viruses more to a cancer than anything else. "Microsoft also said open-source software is inherently less secure because the code is available for the world to examine for flaws, making it possible for hackers or criminals to exploit them. Proprietary software, the company argued, is more secure because of its closed nature." Hmm. If they say it, it must be true. Just more FUD-rhetoric. Nevermind that there are (I would argue) FAR more well-meaning folks testing OSS software than ill-meaning ones. #mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Thursday, May 23, 2002 1:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [JBoss-dev] Open-Source Fight Flares At Pentagon Microsoft tries to squelch Open Source at the pentagon, but apparently many at the pentagon are seeing the light. http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html ___ 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] Re: [JBoss-user] Open-Source Fight Flares At Pentagon
Hi Geeks I funny to see that the more M$ is bitching about open-source the more people notice open-source and at starting to evaluate it. Most people, I think, realized that M$ with its history of buggy and un- secure software is not reliable or at least giving the impression of the need for a backup if M$ application fails. M$ started a trend (killing competitors with free software) which is going to hurt, maybe kill themself because open-source is not only free but also increase trust by providing the code. So, hopefully, M$ is going on with this smear campain and we can take advantage out of it. Have fun - Andy ___ 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
[JBoss-dev] Re: [JBoss-user] Open-Source Fight Flares At Pentagon
Don't the DOD and State Department already use JBoss? -dain Scott M Stark wrote: > Microsoft tries to squelch Open Source at the pentagon, but apparently many > at the pentagon are seeing the light. > > http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html > > > > > ___ > > 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-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ 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
[JBoss-dev] Open-Source Fight Flares At Pentagon
Microsoft tries to squelch Open Source at the pentagon, but apparently many at the pentagon are seeing the light. http://www.washingtonpost.com/wp-dyn/articles/A60050-2002May22.html ___ 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: RE: [JBoss-dev] CD SUBSCRIPTION
> right... > > it costs $1000 per year, The CD subscription is a very good idea! That's a really good business model. RH, Suse, all the Linux distributors are getting their main revenue stream out of CD subscriptions (at least Suse). However, you must face the mass market. $1000 is just too much. Strip the support and all the uninteresting stuff out of the CD. A good installer, binaries, sources, and most importantly the docs. That's it for $100/year, each quarter a CD. You will make millions of $$$. Don't marry it with the community. It's a good JBossGroup business model. Just spend 20% in the community pod. * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=16231 ___ 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
[JBoss-dev] [ jboss-Bugs-559628 ] Incorrectly throwing RollbackException
Bugs item #559628, was opened at 2002-05-23 08:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559628&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Michael Hussey (mhussey) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrectly throwing RollbackException Initial Comment: Using bean managed persistence, and container managed transactions, if the ejbStore method of an entity bean fails by throwing an EJBException, a javax.transaction.RollbackException is thrown instead of a javax.transaction.TransactionRolledBackException. This is a problem because the client will not be able to get a nested exception to find the original problem. For example, in our case, our EJBException wraps an exception describing which unique constraint was violated. The user needs that nested exception to modify his/her entry on the screen to successfully update the object. Weblogic throws its own exception in this case which extends RollbackException and has methods to obtain the nested exception. They also should be throwing TransactionRolledBackException for portability, but at least their solution is useable in the current form. I'm using jboss 2.4.4 windows 2000 ejb 2.0 dtd commit option A for the entity. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=559628&group_id=22866 ___ 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] Foe-Deployer Release I
On Wed, May 22, 2002 at 06:19:07PM -0700, Andreas Schaefer wrote: > Hi Geeks > > Alex Loubyansky wrote the WebLogic Convertor this > weekend and I incorporated it today. It already contains > support for other application servers (see Convertor). That was fast. Well done on getting something like this working so quickly! Cheers, Simon -- `The situation is completely under control. All of them were killed.' --- Alim Razim, for the Northern Alliance, demonstrating fine command of traditional Afghan prisoner control techniques. ___ 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-May-2002
Number of tests run: 593
Successful tests: 593
Errors:0
Failures: 0
[time of test: 23 May 2002 1:21 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
HURRAY - everything worked!
Thanks for all your effort - we really do love you!
___
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] Why is this being dumped out?
Ok, a bad local config must have been that case because after a clean build and check of the jndi.properties the test is running fine with the cluster present. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Sacha Labourey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 12:41 AM Subject: RE: [JBoss-dev] Why is this being dumped out? > > I'm running the default configuration so I doubt it unless the presence > > of a cluster dictates this. This totally screwed up the testsuite run. > > It could also happen if your client JNDI config is wrong (host not > resolvable, etc.). In this case, if no JNDI service is found, a multicast > discovery packet is sent to find an available JBoss HA-JNDI instance. If > found, you will receive a HA-JNDI proxy, hence the message. > > Cheers, > > > Sacha ___ 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] Why is this being dumped out?
> I'm running the default configuration so I doubt it unless the presence > of a cluster dictates this. This totally screwed up the testsuite run. It could also happen if your client JNDI config is wrong (host not resolvable, etc.). In this case, if no JNDI service is found, a multicast discovery packet is sent to find an available JBoss HA-JNDI instance. If found, you will receive a HA-JNDI proxy, hence the message. Cheers, Sacha ___ 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] Why is this being dumped out?
I'm running the default configuration so I doubt it unless the presence of a cluster dictates this. This totally screwed up the testsuite run. - Original Message - From: "Sacha Labourey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 12:24 AM Subject: RE: [JBoss-dev] Why is this being dumped out? > It seems to indicate that you are not using JNDI on port 1099 but HA-JNDI on > port 1100. > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Scott M Stark > > Envoyé : jeudi, 23 mai 2002 09:20 > > À : [EMAIL PROTECTED] > > Objet : [JBoss-dev] Why is this being dumped out? > > > > > > I have 3.0 server running on my w2k box and by osx box started > > up its nightly testsuite run. Suddenly is start seeing these errors > > being dumped out on the w2k box: > ___ 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] Why is this being dumped out?
It seems to indicate that you are not using JNDI on port 1099 but HA-JNDI on port 1100. > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Scott M Stark > Envoyé : jeudi, 23 mai 2002 09:20 > À : [EMAIL PROTECTED] > Objet : [JBoss-dev] Why is this being dumped out? > > > I have 3.0 server running on my w2k box and by osx box started > up its nightly testsuite run. Suddenly is start seeing these errors > being dumped out on the w2k box: ___ 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-May-2002
Number of tests run: 551
Successful tests: 247
Errors:303
Failures: 1
[time of test: 23 May 2002 0:15 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
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
