Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Thursday, May 23, 2002 8:18 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: I don't see sufficient justification to go beyond the spec here so let's just leave it. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Thursday, May 23, 2002 8:18 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: I don't see sufficient justification to go beyond the spec here so let's just leave it. 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
[JBoss-dev] Deployers lifecycle/logging question
Hello,
I am now testing FoeDeployer and have a question that, probably, affects
behaviour of other deployers too.
Suppose we have deployment units in the deploy dir waiting for the
deployer. And the deployer is at last deployed. I expect the following
sequence of calls on the deployer: createService(), startService and
then start to deploy utnits waiting for the deployer (done in
MainDeployer.addDeployer()). The code proves it but logging doesn't.
Here is the log:
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
is waiting for an appropriate deployer.
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Created ServiceModule:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Creating
INFO [org.jboss.varia.deployment.FoeDeployer] Created
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Creating
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Created
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=FoeDeployer, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=Convertor,type=WebLogic, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Starting
INFO [org.jboss.deployment.MainDeployer] Adding deployer:
org.jboss.varia.deployment.FoeDeployer@e8606c
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
DEBUG [org.jboss.varia.deployment.FoeDeployer] create(), got info:
org.jboss.deployment.DeploymentInfo@ee07486d{
url=file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
}
DEBUG [org.jboss.varia.deployment.FoeDeployer] undeploying document
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.varia.deployment.FoeDeployer] Started
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Starting
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Started
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.jar
...
So, the log says that waiting for the deployer units
(wlar-examples.wlar) are deployed before the deployer (FoeDeployer) is
actually started. And WebLogicConverter isn't started at all by the
time of successful deployment of wlar.
In FoeDeployer super.startService() is the last line in method
startService(). And converters (WebLogicConverter) are invoked in
FoeDeployer.create() method.
Could someone clarify it, please? Is it just logging?
--
Best regards,
Alex Loubyansky
___
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] Deployers lifecycle/logging question
Hi Alex!
Does log4j guarantee to display the log messages in the order they
timely occured ?
With the old logging that wasn't the case (it was NOT guaranteed). It do
not know for log4j.
Just a thought,
Tobias
Alex Loubyansky wrote:
Hello,
I am now testing FoeDeployer and have a question that, probably, affects
behaviour of other deployers too.
Suppose we have deployment units in the deploy dir waiting for the
deployer. And the deployer is at last deployed. I expect the following
sequence of calls on the deployer: createService(), startService and
then start to deploy utnits waiting for the deployer (done in
MainDeployer.addDeployer()). The code proves it but logging doesn't.
Here is the log:
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
is waiting for an appropriate deployer.
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Created ServiceModule:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Creating
INFO [org.jboss.varia.deployment.FoeDeployer] Created
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Creating
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Created
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=FoeDeployer, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=Convertor,type=WebLogic, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Starting
INFO [org.jboss.deployment.MainDeployer] Adding deployer:
org.jboss.varia.deployment.FoeDeployer@e8606c
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
DEBUG [org.jboss.varia.deployment.FoeDeployer] create(), got info:
org.jboss.deployment.DeploymentInfo@ee07486d{
url=file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
}
DEBUG [org.jboss.varia.deployment.FoeDeployer] undeploying document
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.varia.deployment.FoeDeployer] Started
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Starting
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Started
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.jar
...
So, the log says that waiting for the deployer units
(wlar-examples.wlar) are deployed before the deployer (FoeDeployer) is
actually started. And WebLogicConverter isn't started at all by the
time of successful deployment of wlar.
In FoeDeployer super.startService() is the last line in method
startService(). And converters (WebLogicConverter) are invoked in
FoeDeployer.create() method.
Could someone clarify it, please? Is it just logging?
--
Best regards,
Alex Loubyansky
___
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[2]: [JBoss-dev] Deployers lifecycle/logging question
Hello Tobias,
good question. I'd like to know too.
Friday, May 24, 2002, 1:55:26 PM, you wrote:
TF Hi Alex!
TF Does log4j guarantee to display the log messages in the order they
TF timely occured ?
TF With the old logging that wasn't the case (it was NOT guaranteed). It do
TF not know for log4j.
TF Just a thought,
TF Tobias
TF Alex Loubyansky wrote:
Hello,
I am now testing FoeDeployer and have a question that, probably, affects
behaviour of other deployers too.
Suppose we have deployment units in the deploy dir waiting for the
deployer. And the deployer is at last deployed. I expect the following
sequence of calls on the deployer: createService(), startService and
then start to deploy utnits waiting for the deployer (done in
MainDeployer.addDeployer()). The code proves it but logging doesn't.
Here is the log:
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
is waiting for an appropriate
deployer.
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Created ServiceModule:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Creating
INFO [org.jboss.varia.deployment.FoeDeployer] Created
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Creating
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Created
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=FoeDeployer, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=Convertor,type=WebLogic, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Starting
INFO [org.jboss.deployment.MainDeployer] Adding deployer:
org.jboss.varia.deployment.FoeDeployer@e8606c
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
DEBUG [org.jboss.varia.deployment.FoeDeployer] create(), got info:
org.jboss.deployment.DeploymentInfo@ee07486d{
url=file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
}
DEBUG [org.jboss.varia.deployment.FoeDeployer] undeploying document
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.varia.deployment.FoeDeployer] Started
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Starting
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Started
INFO [org.jboss.deployment.MainDeployer] Successfully completed deployment of
package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.jar
...
So, the log says that waiting for the deployer units
(wlar-examples.wlar) are deployed before the deployer (FoeDeployer) is
actually started. And WebLogicConverter isn't started at all by the
time of successful deployment of wlar.
In FoeDeployer super.startService() is the last line in method
startService(). And converters (WebLogicConverter) are invoked in
FoeDeployer.create() method.
Could someone clarify it, please? Is it just logging?
--
Best regards,
Alex Loubyansky
___
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 looked at the jmsra code a bit. You should be able to hold onto the session over method calls (new feature w/ new jca impl) but not anything you get from the session, such as the sender. The session may be associated with different physical connections on each (SFSB) call, and the sender will be tied to the physical connection it was originally created from. david jencks On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Thursday, May 23, 2002 8:18 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: I don't see sufficient justification to go beyond the spec here so let's just leave it. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA
I think that would be safer. That will also allow the session to go back into the session pool thus you will share your resources better. Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], Scott M Stark [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Date: Fri, 24 May 2002 00:41:03 -0700 Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. 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
[JBoss-dev] Crap! Classloader problems again
I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am deploying an ear file. The two threads are below. I noticed that Simon updated the classloader code , does this fix it? Is it only on the 3.1 branch? CCRAPoll prio=5 tid=0x88adcf8 nid=0x20e waiting for monitor entry [0xbb5fe000..0xbb5ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) - waiting to lock 43ae7128 (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:228) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:183) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:265) - locked 43e366b8 (a org.jboss.mx.loading.UnifiedClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked 43e366b8 (a org.jboss.mx.loading.UnifiedClassLoader) at com.candata.gateway.CCRAAbstract.getEncryption(Unknown Source) at com.candata.gateway.CCRAAbstract.recvMsg(Unknown Source) at com.candata.gateway.CCRAPoll.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) main prio=5 tid=0x80a5d18 nid=0x1e1 waiting for monitor entry [0xbe7fd000..0xbe7ffad8] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) - waiting to lock 43e366b8 (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:228) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:183) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:265) - locked 43ae7128 (a org.jboss.mx.loading.UnifiedClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked 43ae7128 (a org.jboss.mx.loading.UnifiedClassLoader) at org.jboss.deployment.EARDeployer.init(EARDeployer.java:194) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:570) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:515) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:465) - locked 43b837a8 (a java.util.Collections$SynchronizedList) - locked 43b831c8 (a org.jboss.deployment.scanner.URLDeploymentScanner) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) - locked 43a36fd8 (a org.jboss.system.ServiceController) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:276) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:692) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:527) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216)
RE: [JBoss-dev] Crap! Classloader problems again
Hi, I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am deploying an ear file. The two threads are below. I noticed that Simon updated the classloader code , does this fix it? Is it only on the 3.1 branch? It is supposed to fix it, for now is in 3.1, but unfortunately I'm not yet done. I discovered 1 minute ago that there is still a problem :( Simon ___ 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] JBoss in a multi developers environment
Scott, Does the 'server name' (server identity) need to be part of the getPort request, if it is spec'd in the svc bind mbean config? if the server name was set on the mbean, then the port maps could be keyed off that (in addition to service name). So, the request for getport could assume the 'curent' server name for the port lookup. Or am I missing something? (been known to happen) #mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, May 20, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment // The service JMX name String jmxName; // The virtualHost the service wants to bind to which may be null String virtualHost; // The name of the JBoss service instance to support always giving an // instance the same values String serverName; I'm lost. What is this? Can you give an example? Its what I have been referring to as the starksm and dsundstrom config instances. Say we setup two JBoss instances of main.jboss.org. As Dan is saying, I don't want to have to change my configuration to connect to my instance each time the server is restarted. So when Jason configures my instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamestarksm/ServerName /mbean while for your instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamedsundstrom/ServerName /mbean Now there can be a static configuration for our instances for which the client ports, address in use is invariant across instance restarts. // The default port int port; // The default interface InetAddress bindAddr; Of these values, would the ServiceBindingManager only be allowed to change virtualHost, port, and bindAddr? Yes. BTW, do you actually like this idea Scott? Yes, its a definite improvement over what we have. In the future I would like to see this integrated with a client side naming service but as I said that is another layer. ___ 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] Deployers lifecycle/logging question
From your description below I think FoeDeployer depends on
WebLogicConverter. If you explicitly state this dependency with a depends
tag the deployment system will create WLC before FD and start WLC before
FD. If FD is designed to accept lots of converters you can use a
depends-list element.
How does FD know about WLC now? I'd recommend using an ObjectName and
calling through the mbean server.
If you want to allow dynamically adding converters you will have to make FD
keep a list of undeployables that it tries to deploy whenever a new
converter is registered. I don't think I recommend this.
david jencks
On 2002.05.24 06:04:11 -0400 Alex Loubyansky wrote:
Hello,
I am now testing FoeDeployer and have a question that, probably, affects
behaviour of other deployers too.
Suppose we have deployment units in the deploy dir waiting for the
deployer. And the deployer is at last deployed. I expect the following
sequence of calls on the deployer: createService(), startService and
then start to deploy utnits waiting for the deployer (done in
MainDeployer.addDeployer()). The code proves it but logging doesn't.
Here is the log:
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
is waiting for an appropriate deployer.
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Created ServiceModule:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Creating
INFO [org.jboss.varia.deployment.FoeDeployer] Created
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Creating
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Created
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=FoeDeployer, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.deployment.SARDeployer] Create MBean, name:
jboss:service=Convertor,type=WebLogic, SAR Module:
jboss.management.single:J2EEServer=Single,j2eeType=ServiceModule,name=foe-deployer.sar
INFO [org.jboss.varia.deployment.FoeDeployer] Starting
INFO [org.jboss.deployment.MainDeployer] Adding deployer:
org.jboss.varia.deployment.FoeDeployer@e8606c
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
DEBUG [org.jboss.varia.deployment.FoeDeployer] create(), got info:
org.jboss.deployment.DeploymentInfo@ee07486d{
url=file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
}
DEBUG [org.jboss.varia.deployment.FoeDeployer] undeploying document
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.deployment.MainDeployer] Successfully completed
deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.wlar
INFO [org.jboss.varia.deployment.FoeDeployer] Started
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Starting
INFO [org.jboss.varia.deployment.convertor.WebLogicConvertor] Started
INFO [org.jboss.deployment.MainDeployer] Successfully completed
deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/foe-deployer.sar
INFO [org.jboss.deployment.MainDeployer] Starting deployment of package:
file:/C:/CVSROOT/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/wlar-examples.jar
...
So, the log says that waiting for the deployer units
(wlar-examples.wlar) are deployed before the deployer (FoeDeployer) is
actually started. And WebLogicConverter isn't started at all by the
time of successful deployment of wlar.
In FoeDeployer super.startService() is the last line in method
startService(). And converters (WebLogicConverter) are invoked in
FoeDeployer.create() method.
Could someone clarify it, please? Is it just logging?
--
Best regards,
Alex Loubyansky
___
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
RE: [JBoss-dev] Crap! Classloader problems again
Ok. Let me know when you are done. I will test it On Fri, 2002-05-24 at 09:08, Bordet, Simone wrote: Hi, I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am deploying an ear file. The two threads are below. I noticed that Simon updated the classloader code , does this fix it? Is it only on the 3.1 branch? It is supposed to fix it, for now is in 3.1, but unfortunately I'm not yet done. I discovered 1 minute ago that there is still a problem :( Simon ___ 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[2]: [JBoss-dev] Deployers lifecycle/logging question
Hello David, I asked that because I found it strange that the deployer not being started already deploys some units, if the log is right. So, the log is like: [FoeDeployer] Starting [MainDeployer] Adding deployer: [MainDeployer] Starting deployment of package: waitinig unit [FoeDeployer] create() ... [FoeDeployer] Started when I expected it like this: [FoeDeployer] Starting [FoeDeployer] Started [MainDeployer] Adding deployer: [MainDeployer] Starting deployment of package: waitinig unit [FoeDeployer] create() ... Am I wrong? Friday, May 24, 2002, 4:20:33 PM, you wrote: DJ From your description below I think FoeDeployer depends on DJ WebLogicConverter. If you explicitly state this dependency with a depends DJ tag the deployment system will create WLC before FD and start WLC before DJ FD. If FD is designed to accept lots of converters you can use a DJ depends-list element. DJ How does FD know about WLC now? I'd recommend using an ObjectName and DJ calling through the mbean server. DJ If you want to allow dynamically adding converters you will have to make FD DJ keep a list of undeployables that it tries to deploy whenever a new DJ converter is registered. I don't think I recommend this. DJ david jencks -- Best regards, Alex Loubyansky ___ 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[2]: [JBoss-dev] Deployers lifecycle/logging question
Hello David, Friday, May 24, 2002, 4:20:33 PM, you wrote: DJ From your description below I think FoeDeployer depends on DJ WebLogicConverter. If you explicitly state this dependency with a depends DJ tag the deployment system will create WLC before FD and start WLC before DJ FD. If FD is designed to accept lots of converters you can use a DJ depends-list element. No. WebLogicConvertor depends on FoeDeployer. And it's expressed with a depends element. In the architecture as it is exists for now I think it's the right choice. Because WLC has a deployer's name and in startService() it's added to it's deployer (FD) which contains the list of convertors. DJ How does FD know about WLC now? I'd recommend using an ObjectName and DJ calling through the mbean server. Actually, already answered. It's done this way. DJ If you want to allow dynamically adding converters you will have to make FD DJ keep a list of undeployables that it tries to deploy whenever a new DJ converter is registered. I don't think I recommend this. Do you have other remarks? Please, let me know. I am becoming crazy of it but feel have to learn more :) alex ___ 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[3]: [JBoss-dev] Deployers lifecycle/logging question
Hello Alex, I've got it. [FoeDeployer] Starting - the beginning of the method FoeDeployer.startService() [FoeDeployer] Started - the end of it. But it looks messy in case of deploying (actually any) deployer when there are waiting deployable units. alex Friday, May 24, 2002, 4:53:33 PM, you wrote: AL Hello David, AL I asked that because I found it strange that the deployer not being AL started already deploys some units, if the log is right. So, the log AL is like: AL [FoeDeployer] Starting AL [MainDeployer] Adding deployer: AL [MainDeployer] Starting deployment of package: waitinig unit AL [FoeDeployer] create() AL ... AL [FoeDeployer] Started AL when I expected it like this: AL [FoeDeployer] Starting AL [FoeDeployer] Started AL [MainDeployer] Adding deployer: AL [MainDeployer] Starting deployment of package: waitinig unit AL [FoeDeployer] create() AL ... AL Am I wrong? AL Friday, May 24, 2002, 4:20:33 PM, you wrote: DJ From your description below I think FoeDeployer depends on DJ WebLogicConverter. If you explicitly state this dependency with a depends DJ tag the deployment system will create WLC before FD and start WLC before DJ FD. If FD is designed to accept lots of converters you can use a DJ depends-list element. DJ How does FD know about WLC now? I'd recommend using an ObjectName and DJ calling through the mbean server. DJ If you want to allow dynamically adding converters you will have to make FD DJ keep a list of undeployables that it tries to deploy whenever a new DJ converter is registered. I don't think I recommend this. DJ david jencks -- Best regards, Alex Loubyansky ___ 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[2]: [JBoss-dev] Deployers lifecycle/logging question
The FoeDeployer should register with MainDeployer as the last thing it does in startService(), when it is in fact usable. So at least you should move super.startService() to the end. I just looked at the code and think that a simpler design would be to simply have the WLC be a SubDeployer. You can make a common superclass with utility methods all the foe deployers will need. Otherwise you will have to either give foedeployer a list of all the converters it will get, which is kind of silly, or implement another layer of waiting behavior in FoeDeployer, which is even sillier. As far as I can tell from a quick glance, FoeDeployer doesn't do anything that couldn't be done at least as well in a superclass of WLC. Also I thought some of the file manipulation methods were already in SubDeployerSupport?? I havne't looked at it for a while though. thanks david jencks On 2002.05.24 09:53:33 -0400 Alex Loubyansky wrote: Hello David, I asked that because I found it strange that the deployer not being started already deploys some units, if the log is right. So, the log is like: [FoeDeployer] Starting [MainDeployer] Adding deployer: [MainDeployer] Starting deployment of package: waitinig unit [FoeDeployer] create() ... [FoeDeployer] Started when I expected it like this: [FoeDeployer] Starting [FoeDeployer] Started [MainDeployer] Adding deployer: [MainDeployer] Starting deployment of package: waitinig unit [FoeDeployer] create() ... Am I wrong? Friday, May 24, 2002, 4:20:33 PM, you wrote: DJ From your description below I think FoeDeployer depends on DJ WebLogicConverter. If you explicitly state this dependency with a depends DJ tag the deployment system will create WLC before FD and start WLC before DJ FD. If FD is designed to accept lots of converters you can use a DJ depends-list element. DJ How does FD know about WLC now? I'd recommend using an ObjectName and DJ calling through the mbean server. DJ If you want to allow dynamically adding converters you will have to make FD DJ keep a list of undeployables that it tries to deploy whenever a new DJ converter is registered. I don't think I recommend this. DJ david jencks -- Best regards, Alex Loubyansky ___ 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[2]: [JBoss-dev] Deployers lifecycle/logging question
On 2002.05.24 10:02:08 -0400 Alex Loubyansky wrote: Hello David, Friday, May 24, 2002, 4:20:33 PM, you wrote: DJ From your description below I think FoeDeployer depends on DJ WebLogicConverter. If you explicitly state this dependency with a depends DJ tag the deployment system will create WLC before FD and start WLC before DJ FD. If FD is designed to accept lots of converters you can use a DJ depends-list element. No. WebLogicConvertor depends on FoeDeployer. And it's expressed with a depends element. In the architecture as it is exists for now I think it's the right choice. Because WLC has a deployer's name and in startService() it's added to it's deployer (FD) which contains the list of convertors. OK, this means FoeDeployer is started before WLC, guaranteed. If you want this design then you will have to make foedeployer keep a list of undeployables and check any time a new converter is registered. As I indicated in another message I think you should eliminate foedeployer and just have converters. DJ How does FD know about WLC now? I'd recommend using an ObjectName and DJ calling through the mbean server. Actually, already answered. It's done this way. DJ If you want to allow dynamically adding converters you will have to make FD DJ keep a list of undeployables that it tries to deploy whenever a new DJ converter is registered. I don't think I recommend this. Do you have other remarks? Please, let me know. I am becoming crazy of it but feel have to learn more :) alex ___ 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[4]: [JBoss-dev] Deployers lifecycle/logging question
Hello David, Friday, May 24, 2002, 5:17:19 PM, you wrote: DJ The FoeDeployer should register with MainDeployer as the last thing it does DJ in startService(), when it is in fact usable. So at least you should move DJ super.startService() to the end. Yes, it even caused problem determining correct tmp directory. I've corrected it and sent to Andreas. That's our working scheme for now :) DJ I just looked at the code and think that a simpler design would be to DJ simply have the WLC be a SubDeployer. You can make a common superclass DJ with utility methods all the foe deployers will need. Otherwise you will DJ have to either give foedeployer a list of all the converters it will get, DJ which is kind of silly, or implement another layer of waiting behavior in DJ FoeDeployer, which is even sillier. As far as I can tell from a quick DJ glance, FoeDeployer doesn't do anything that couldn't be done at least as DJ well in a superclass of WLC. Also I thought some of the file manipulation DJ methods were already in SubDeployerSupport?? I havne't looked at it for a DJ while though. I've got your idea. It's another aproach than Andreas' one is. For now the idea is to create a manager for convertors to add and remove them on the fly. But your idea doesn't exclude this in any way, as I see. Maybe Andreas will write something on it. I just retold his idea. alex ___ 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 think it is a good idea. I vote for it. There were some notes in one my emails on the 20th with a suggested approach. On the DeploymentInfo, I think David is correct about eventually wanting the DeploymentInfo as an MBean. A friend of mine comparing Weblogic and JBoss, was miffed at the lack of a pretty interface for showing all the deployed applications. On the UI issue, Jason is also correct. Eventually we will have to make the JMBean interface more usable. For now, I don't think there will be that many and we could stick them in a separate Domain so they are off to the side. I have some ideas for using a tree control for the UI which I can put in a separate email. Fred. At 10:10 PM 5/23/2002, you 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] Need to create service with its UCL
On 2002.05.24 11:31:46 -0400 Frederick N. Brier wrote: I think it is a good idea. I vote for it. There were some notes in one my emails on the 20th with a suggested approach. On the DeploymentInfo, I think David is correct about eventually wanting the DeploymentInfo as an MBean. A friend of mine comparing Weblogic and JBoss, was miffed at the lack of a pretty interface for showing all the deployed applications. How about jsr-77? david jencks On the UI issue, Jason is also correct. Eventually we will have to make the JMBean interface more usable. For now, I don't think there will be that many and we could stick them in a separate Domain so they are off to the side. I have some ideas for using a tree control for the UI which I can put in a separate email. Fred. At 10:10 PM 5/23/2002, you 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
[JBoss-dev] MBean viewer ideas
This is in regards to the MBean viewer on port 8082. Instead of using an HTML interface, what if we made it a SOAP interface with a Java Client? This could tie into JAAS security and limit access. I wrote a similar GUI on another Java project. I don't want to cause anyone nausea, but the UI was similar to Microsoft Management Console (MMC). Further, the MBean or SessionBean that was acting as the SOAP service could act as a broker for the same SOAP service running on every JBoss server in the cluster. For those not familiar with it, the MMC has a tree control in a pane to the left and the right pane is defined based on the tree node selected on the left side. The tree child nodes at each level are configurable, both by attributes such as hostname, domain(JMX), service, name, and type or fixed expressions or value lists. So the default which would look similar to now would be by domain name attribute which would yield nodes such as DefaultDomain, JMImplementation, or jboss.deployment. You could also have multiple configurations to look at your beans differently. For instance, if you had an MBean showing number of transactions per second, the tree could show that MBean service at the top node and then all the hostnames underneath it. So you could easily flick from node to note looking for bottlenecks. Of course, with all of the data as XML, you easily design new node/panel handlers that could display charts, graphs, aggregate tables of performance data, etc. One could even have the GUI plug into the MMC and become part of the standard Microsoft operating environment tee hee hee. We could also have the nodes extend into the attributes of an MBean. For instance, the Jetty MBean has a DeployedApplications attribute which is a java.util.Iterator which can't be displayed. Wouldn't it be nice to be able to have a table possibly with hyper-links to related MBeans? Another idea is how to provide better context help for the MBean viewer. This idea uses XDoclet to generate an XML file that could be bundled in the .jar containing the class files for the MBean. It would strip the JavaDoc from the class and data members from the MBean class. Instead of having a dialog pop up and say MBean Attribute you have a description of what it is, as well as the MBean itself. This information would be retrieved by the MBean Viewer SOAP service and provided to the GUI. Thoughts? Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ 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] MBean viewer ideas
There is already an ejb exposing the mbean server, thus providing security, and a project to create a servlet based viewer. Exposing something via jboss.net seems like a good idea also. Are you interested in working with the guys on the improved viewer? I think the discussion is on the jmx forum. In regards to your wish for more info in the mbean viewer, there is already an xdoclet task to create xmbean descriptors including lots if info about the mbean from the markup, and I even made it so xmbeans can be deployed from *-service.xml. The remaining step here is to convert all the mbeans to be xmbeans. I haven't had time to look recently, but the last time I looked the xmbean implementation was not complete enough. Something related is used to generate the jmx-api docs that were in rc2 but I think may not have made it into rc3. david jencks On 2002.05.24 12:23:11 -0400 Frederick N. Brier wrote: This is in regards to the MBean viewer on port 8082. Instead of using an HTML interface, what if we made it a SOAP interface with a Java Client? This could tie into JAAS security and limit access. I wrote a similar GUI on another Java project. I don't want to cause anyone nausea, but the UI was similar to Microsoft Management Console (MMC). Further, the MBean or SessionBean that was acting as the SOAP service could act as a broker for the same SOAP service running on every JBoss server in the cluster. For those not familiar with it, the MMC has a tree control in a pane to the left and the right pane is defined based on the tree node selected on the left side. The tree child nodes at each level are configurable, both by attributes such as hostname, domain(JMX), service, name, and type or fixed expressions or value lists. So the default which would look similar to now would be by domain name attribute which would yield nodes such as DefaultDomain, JMImplementation, or jboss.deployment. You could also have multiple configurations to look at your beans differently. For instance, if you had an MBean showing number of transactions per second, the tree could show that MBean service at the top node and then all the hostnames underneath it. So you could easily flick from node to note looking for bottlenecks. Of course, with all of the data as XML, you easily design new node/panel handlers that could display charts, graphs, aggregate tables of performance data, etc. One could even have the GUI plug into the MMC and become part of the standard Microsoft operating environment tee hee hee. We could also have the nodes extend into the attributes of an MBean. For instance, the Jetty MBean has a DeployedApplications attribute which is a java.util.Iterator which can't be displayed. Wouldn't it be nice to be able to have a table possibly with hyper-links to related MBeans? Another idea is how to provide better context help for the MBean viewer. This idea uses XDoclet to generate an XML file that could be bundled in the .jar containing the class files for the MBean. It would strip the JavaDoc from the class and data members from the MBean class. Instead of having a dialog pop up and say MBean Attribute you have a description of what it is, as well as the MBean itself. This information would be retrieved by the MBean Viewer SOAP service and provided to the GUI. Thoughts? Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ 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: Re[2]: [JBoss-dev] Deployers lifecycle/logging question
Hi David The FoeDeployer should register with MainDeployer as the last thing it does in startService(), when it is in fact usable. So at least you should move super.startService() to the end. Done. I just looked at the code and think that a simpler design would be to simply have the WLC be a SubDeployer. You can make a common superclass with utility methods all the foe deployers will need. Maybe that is the way to go. I think before we make that decision we have to decide on how the Convetor is chosen to deploy/convert because I don't like the idea of the .wlar extension. This was just a wor-around to go on now. Otherwise you will have to either give foedeployer a list of all the converters it will get, which is kind of silly, or implement another layer of waiting behavior in FoeDeployer, which is even sillier. As far as I can tell from a quick glance, FoeDeployer doesn't do anything that couldn't be done at least as well in a superclass of WLC. Agreed. Also I thought some of the file manipulation methods were already in SubDeployerSupport?? I havne't looked at it for a while though. I didn't found any. 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] [ jboss-Bugs-516953 ] setRollbackOnly() in sfsb behaviour
Bugs item #516953, was opened at 2002-02-13 13:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=516953group_id=22866 Category: None Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Chris Harris (charris) Assigned to: Nobody/Anonymous (nobody) Summary: setRollbackOnly() in sfsb behaviour Initial Comment: JBoss 2.4.3, JDK1.3.1 on Win2000. The attached file contains a simple sfsb with a single method that calls EJBContext.setRollbackOnly(). Two consecutive calls to this method from an ordinary java client result in the following exception propagated back to the client: = java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackExceptio n: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans javax.transaction.TransactionRolledbackException: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_ Stub.invoke(Unknown Source) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo keContainer(GenericProxy.java:357) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionPr oxy.invoke(StatefulSessionProxy.java:136) at $Proxy1.error(Unknown Source) at com.lombardrisk.trading.test.StatefulTestBeanTest.main (StatefulTestBeanTest.java:24) == On the server, this exception is preceded by: === [StatefulSessionEnterpriseContext] locked 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) [StatefulSessionEnterpriseContext] locked 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465)
Re: [JBoss-dev] Need to create service with its UCL
I was trying to back track and read the messages on jsr-77. My apologies, I had never heard of it, so I am playing catch up. There seems to be a never ending stream of APIs. I just skimmed the JavaOne Presentation 1717 and looked at the http://java.sun.com/j2ee/tools/management/ web page for the reference implementation. Was Sun writing the GUI or was Andreas? What is Emma? Fred. At 11:47 AM 5/24/2002, you wrote: How about jsr-77? david jencks ___ 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-516953 ] setRollbackOnly() in sfsb behaviour
Bugs item #516953, was opened at 2002-02-13 05:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=516953group_id=22866 Category: None Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Chris Harris (charris) Assigned to: Nobody/Anonymous (nobody) Summary: setRollbackOnly() in sfsb behaviour Initial Comment: JBoss 2.4.3, JDK1.3.1 on Win2000. The attached file contains a simple sfsb with a single method that calls EJBContext.setRollbackOnly(). Two consecutive calls to this method from an ordinary java client result in the following exception propagated back to the client: = java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackExceptio n: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans javax.transaction.TransactionRolledbackException: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_ Stub.invoke(Unknown Source) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo keContainer(GenericProxy.java:357) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionPr oxy.invoke(StatefulSessionProxy.java:136) at $Proxy1.error(Unknown Source) at com.lombardrisk.trading.test.StatefulTestBeanTest.main (StatefulTestBeanTest.java:24) == On the server, this exception is preceded by: === [StatefulSessionEnterpriseContext] locked 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) [StatefulSessionEnterpriseContext] locked 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465)
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment
The local use of the mbean will not use this as you say its a bound property of the mbean the service requesting portmapping is talking to. This information needs to be part of the ServiceBinding object for use in remote access to a central authority as well as debugging. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Mike Finn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 6:18 AM Subject: RE: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment Scott, Does the 'server name' (server identity) need to be part of the getPort request, if it is spec'd in the svc bind mbean config? if the server name was set on the mbean, then the port maps could be keyed off that (in addition to service name). So, the request for getport could assume the 'curent' server name for the port lookup. Or am I missing something? (been known to happen) #mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, May 20, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment // The service JMX name String jmxName; // The virtualHost the service wants to bind to which may be null String virtualHost; // The name of the JBoss service instance to support always giving an // instance the same values String serverName; I'm lost. What is this? Can you give an example? Its what I have been referring to as the starksm and dsundstrom config instances. Say we setup two JBoss instances of main.jboss.org. As Dan is saying, I don't want to have to change my configuration to connect to my instance each time the server is restarted. So when Jason configures my instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamestarksm/ServerName /mbean while for your instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamedsundstrom/ServerName /mbean Now there can be a static configuration for our instances for which the client ports, address in use is invariant across instance restarts. // The default port int port; // The default interface InetAddress bindAddr; Of these values, would the ServiceBindingManager only be allowed to change virtualHost, port, and bindAddr? Yes. BTW, do you actually like this idea Scott? Yes, its a definite improvement over what we have. In the future I would like to see this integrated with a client side naming service but as I said that is another layer. ___ 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] Deployers lifecycle/logging question
There is no guarentee of log message ordering in the standard log4j appenders. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Tobias Frech [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 3:55 AM Subject: Re: [JBoss-dev] Deployers lifecycle/logging question Hi Alex! Does log4j guarantee to display the log messages in the order they timely occured ? With the old logging that wasn't the case (it was NOT guaranteed). It do not know for log4j. Just a thought, Tobias Alex Loubyansky wrote: Hello, I am now testing FoeDeployer and have a question that, probably, affects behaviour of other deployers too. ___ 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] How about integrating JSR77 via notifications
A problem that keeps popping up with the JSR77 integration is that it is rather invasive and if it fails it breaks existing code. A better integration path would be strictly as external listeners to JMX events. This would clean up the integration, make it easy to disable and require that key events were being made available for purposes other than JSR77. 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] [ jboss-Bugs-560310 ] 3.0Beta Ear deployement problem.
Bugs item #560310, was opened at 2002-05-24 13:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=560310group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0Beta Ear deployement problem. Initial Comment: I am seeing a problem deploying an ear file in the 3.0Beta. I was able to deploy my ear in previous 3.0 versions but not with the beta. Here is an example message when starting the server. 12:58:21,867 WARN [MainDeployer] The manifest entry in file:/D:/jboss/server30/jboss- 3.0.0beta/tmp/deploy/72.MetadataServerAPI.jar references URL file:/D:/jboss/server30/jboss- 3.0.0beta/tmp/deploy/library/saxpath.jar which could not be opened, entry ignored The problem is there no library directory under tmp/deploy. If I create this directory and add the jar file to it, it deploys fine. So it appears to me that the ear file is not getting exploded correctly in the tmp directory. System info: JBOSS_CLASSPATH=d:\jboss\server30 \lib\;d:\jboss\server30\config\;d:\jb\server30\l ib\jdbc\oraclejdbc816.zip;d:\jb\server30 \lib\jdbc\db2java.zip;d:\jboss\server30\j dk\lib\tools.jar;run.jar INFO Using config: org.jboss.system.ServerConfig@7943a4 INFO JBoss Release: JBoss-3.0.0beta CVSTag=Rel_3_0_0_3 INFO Starting General Purpose Architecture (GPA)... INFO ClassLoaders and ServiceLibraries initialized 15:43:22,495 INFO [root] Started Log4jService, config=file:/D:/jb/server30/jboss /conf/default/log4j.properties 15:43:22,526 INFO [Server] Home Dir: D:\jb\server30\jboss 15:43:22,541 INFO [Server] Install URL: file:/D:/jb/server30/jboss/ 15:43:22,541 INFO [Server] Configuration URL: file:/D:/jb/server30/jboss/conf/de fault/ 15:43:22,541 INFO [Server] Spine URL: file:/D:/jb/server30/jboss/lib/ 15:43:22,541 INFO [Server] Library URL: file:/D:/jb/server30/jboss/lib/ext/ 15:43:22,541 INFO [Server] Patch URL: null 15:43:22,557 INFO [Info] Java version: 1.3.1,Sun Microsystems Inc. 15:43:22,557 INFO [Info] Java VM: Java HotSpot (TM) Client VM 1.3.1-b24,Sun Micro systems Inc. 15:43:22,557 INFO [Info] OS-System: Windows NT 4.0,x86 15:43:22,635 INFO [ServiceController] Controller MBean online -- Comment By: Scott M Stark (starksm) Date: 2002-05-24 13:54 Message: Logged In: YES user_id=175228 Get up to date as this is way old. If its not RC3 we don't care. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=560310group_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] VOTE FOR JBOSS
GADDAMIT, these pools are ridiculous, it is just the company voting for it, and comatose products like oracle has got the full company behind it, so here is our call, if you are on our lists and you haven't voted for us yet, please please go and vote, I did this morning :)I hadn't before. Ok I want us to be #1 there and we will not stop until we are #1 there, clear? http://www.sys-con.com/java/readerschoice2002/nominationform.cfm go marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ 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] How about integrating JSR77 via notifications
Hi Scott A problem that keeps popping up with the JSR77 integration is that it is rather invasive and if it fails it breaks existing code. A better integration path would be strictly as external listeners to JMX events. This would clean up the integration, make it easy to disable and require that key events were being made available for purposes other than JSR77. I don't think this is possible. We are already listening to JMX events to determine the state of a component. But this is only the easy part of JSR-77. Even thought that JSR-77 spec. does not really cover what it was supposed to do the main part currenlty is to retrieve and calculate performance statstics. The rest is just to provide a JSR-77 compliant view to an application server. BTW I am not aware that JSR-77 breaks existing code. Mostely it was the other way around that changes where made and the JSR-77 stuff was left out and broke. The design is made that the invasive part is as small as possible. So what is the source of the problem ? 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
Re: [JBoss-dev] How about integrating JSR77 via notifications
The source of the problem is management setup such as this from
SARDeployer where over 60% of the code is JSR77 setup with
implicit dependencies on the org.jboss.management.* pkgs that
if it fails, prevents the service from being created. Why can't these
steps be performed based on an event generated from here rather
than embedding all of this here? Its not a question of breaking this
code now, its maintainability and mixing of functionality.
public void create(DeploymentInfo di)
throws DeploymentException
{
try
{
// install the MBeans in this descriptor
log.debug(Deploying SAR, create step: url + di.url);
// Register the SAR UCL as an mbean so we can use it as the service
loader
ObjectName uclName = di.ucl.getObjectName();
log.debug(Registering service UCL=+uclName);
getServer().registerMBean(di.ucl, uclName);
// Create JSR-77 SAR-Module
String lURL = di.url.toString();
int lIndex = lURL.lastIndexOf( / );
String lName = lURL.substring( lIndex = 0 ? lIndex + 1 : 0 );
// This is to go around the project dependencies
Class lServiceModule = Class.forName(
org.jboss.management.j2ee.ServiceModule );
Method lCreateSAR = lServiceModule.getMethod(
create,
new Class[] {
MBeanServer.class,
String.class,
URL.class
}
);
ObjectName lSARName = (ObjectName) lCreateSAR.invoke(
null,
new Object[] {
server,
lName,
di.localUrl
}
);
log.info( Created ServiceModule: + lSARName );
List mbeans = di.mbeans;
mbeans.clear();
List descriptorMbeans =
serviceController.install(di.document.getDocumentElement(), uclName);
mbeans.addAll(descriptorMbeans);
// create the services
for (Iterator iter = di.mbeans.iterator(); iter.hasNext(); )
{
ObjectName service = (ObjectName)iter.next();
// The service won't be created until explicitly dependent
mbeans are created
serviceController.create(service);
}
// This is to go around the project dependencies
Class lMBean = Class.forName( org.jboss.management.j2ee.MBean );
Method lCreate = lMBean.getMethod(
create,
new Class[] {
MBeanServer.class,
String.class,
String.class,
ObjectName.class
}
);
ObjectName[] lNames = (ObjectName[]) mbeans.toArray( new
ObjectName[ 0] );
for( int i = 0; i lNames.length; i++ ) {
// If ServiceModule is not created yet, do it now
if( lSARName == null ) {
lSARName = (ObjectName) lCreateSAR.invoke(
null,
new Object[] {
server,
lName,
di.localUrl
}
);
log.info( Created ServiceModule: + lSARName );
}
// Create JSR-77 MBean
log.info( Create MBean, name: + lNames[ i ] + , SAR Module:
+lSARName );
lCreate.invoke(
null,
new Object[] {
server,
lNames[ i ] + ,
lSARName == null ? null : lSARName + ,
lNames[ i ]
}
);
}
}
catch (Exception e)
{
destroy(di);
throw new DeploymentException(create operation failed for package
+ di.url, e);
}
}
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Andreas Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Scott M Stark
[EMAIL PROTECTED]
Sent: Friday, May 24, 2002 2:23 PM
Subject: Re: [JBoss-dev] How about integrating JSR77 via notifications
I don't think this is possible. We are already listening to JMX events
to determine the state of a component. But this is only the easy part
of JSR-77. Even thought that JSR-77 spec. does not really cover
what it was supposed to do the main part currenlty is to retrieve
and calculate performance statstics. The rest is just to provide a
JSR-77 compliant view to an application server.
BTW I am not aware that JSR-77 breaks existing code. Mostely
it was the other way around that changes where made and the
JSR-77 stuff was left out and broke.
The design is made that the invasive part is as small as possible.
So what is the source of the problem ?
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-dev] [xdoclet] java.lang.IllegalStateException
I can't run the 3.0 testsuite on OSX right now because of xdoclet puking: compile-mbean-sources: [mkdir] Created dir: /usr/local/jboss/JBoss3.0/jboss-all/server/output/gen-src sourcepath is deprecated. the preferred way to design sources is via nested fileset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Running mbeanInterface/ [xdoclet] Generating output for 'org.jboss.ejb.EjbModule' using template file 'jar:file:/usr/local/jboss/JBoss3.0/jboss-all/tools/lib/xdoclet.jar!/xdoclet /jmx/mbean.j'. [xdoclet] java.lang.IllegalStateException: Couldn't find source for org.jboss.ejb.plugins.jaws.jdbc.JDBCStartCommand at /usr/local/jboss/JBoss3.0/jboss-all/server/src/main/org/jboss/ejb/plugins/ja ws/jdbc/JDBCStartCommand.java [xdoclet] at xjavadoc.SourceClass.init(SourceClass.java:105) [xdoclet] at xjavadoc.XJavaDoc.scanAndPut(XJavaDoc.java:550) [xdoclet] at xjavadoc.XJavaDoc.getXClass(XJavaDoc.java:393) [xdoclet] at xjavadoc.ProxyClass.resolve(ProxyClass.java:584) [xdoclet] at xjavadoc.ProxyClass.doc(ProxyClass.java:483) [xdoclet] at xdoclet.DocletSupport.isDocletGenerated(DocletSupport.java:269) [xdoclet] at xdoclet.TemplateSubTask.matchesGenerationRules(TemplateSubTask.java:633) [xdoclet] at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:576) [xdoclet] at xdoclet.TemplateSubTask.execute(TemplateSubTask.java:488) [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:54) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) This is working on linux. Is there a workaround for 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
Re: [JBoss-dev] VOTE FOR JBOSS
Remember that your vote doesn't count until you vote the 30 (gasp) categories and receive the corresponding email. So be patient. marc fleury wrote: GADDAMIT, these pools are ridiculous, it is just the company voting for it, and comatose products like oracle has got the full company behind it, so here is our call, if you are on our lists and you haven't voted for us yet, please please go and vote, I did this morning :)I hadn't before. Ok I want us to be #1 there and we will not stop until we are #1 there, clear? http://www.sys-con.com/java/readerschoice2002/nominationform.cfm go marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ 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] How about integrating JSR77 via notifications
Hi Scott The source of the problem is management setup such as this from SARDeployer where over 60% of the code is JSR77 setup with implicit dependencies on the org.jboss.management.* pkgs that if it fails, prevents the service from being created. Why can't these steps be performed based on an event generated from here rather than embedding all of this here? Its not a question of breaking this code now, its maintainability and mixing of functionality. NOTE: this is an experiment because JSR-77 does not know anything about SAR,services etc. I wanted to extrapolate and see what we can gain from. Therefore the implementation is everyting that stable. We could wrap the whole thing in a try-catch block or we can check if the classes are available before going on any further. What is the best way to do so ? If all else fails we can take the part around ServiceModule and management-MBean out. As I mentioned JSR-77 is not what it claims it would be. One of the big missing parts is that you cannot create or destroy any part. Therefore you cannot create a new DataSource, JCA, Queue, Topic etc. which is an important part of J2EE management, isn't it? Like the ServiceModule/MBean I would like to add this as a vendor-specific feature (one feature more than the competition). Have fun - Andy BTW the intrusive stuff is coming with the performance statistics integration because then we need to track the statistics in each service (JMS, JCA, EJBs, etc.) and on demand provide these values to the client (of course massaged when it is running in a cluster). ___ 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] How about integrating JSR77 via notifications
The point is that the current integration is too heavy for something that is at best experimental and I should be able to configure a deployment that runs without it. I would like to see a looser integration that allows for this. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Andreas Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Friday, May 24, 2002 3:05 PM Subject: Re: [JBoss-dev] How about integrating JSR77 via notifications Hi Scott The source of the problem is management setup such as this from SARDeployer where over 60% of the code is JSR77 setup with implicit dependencies on the org.jboss.management.* pkgs that if it fails, prevents the service from being created. Why can't these steps be performed based on an event generated from here rather than embedding all of this here? Its not a question of breaking this code now, its maintainability and mixing of functionality. NOTE: this is an experiment because JSR-77 does not know anything about SAR,services etc. I wanted to extrapolate and see what we can gain from. Therefore the implementation is everyting that stable. We could wrap the whole thing in a try-catch block or we can check if the classes are available before going on any further. What is the best way to do so ? If all else fails we can take the part around ServiceModule and management-MBean out. As I mentioned JSR-77 is not what it claims it would be. One of the big missing parts is that you cannot create or destroy any part. Therefore you cannot create a new DataSource, JCA, Queue, Topic etc. which is an important part of J2EE management, isn't it? Like the ServiceModule/MBean I would like to add this as a vendor-specific feature (one feature more than the competition). Have fun - Andy BTW the intrusive stuff is coming with the performance statistics integration because then we need to track the statistics in each service (JMS, JCA, EJBs, etc.) and on demand provide these values to the client (of course massaged when it is running in a cluster). ___ 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
I suppose they do. AFAIK they must be like NASA, which is said to have running each and every piece of software in the world. Dain Sundstrom wrote: 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 ___ 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 think you are right... though it kinda sucks. I think there is something up with the current tx inside of SpySession, someone is setting it to null... could be due to my missuse, but I will find out soon enough. --jason On Friday 24 May 2002 05:54 am, Hiram Chirino wrote: I think that would be safer. That will also allow the session to go back into the session pool thus you will share your resources better. Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], Scott M Stark [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Date: Fri, 24 May 2002 00:41:03 -0700 Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Thursday, May 23, 2002 8:18 PM Subject: Re: [JBoss-dev] Seeing occasional Invalid tx id with JMS RA Does this mean we should not try to produce more meaningful error messages when this does happen... or just leave it as is? --jason On Thursday 23 May 2002 08:00 pm, Scott M Stark wrote: I don't see sufficient justification to go beyond the spec here so let's just leave it. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 25-May-2002
Number of tests run: 750 Successful tests: 727 Errors:20 Failures: 3 [time of test: 25 May 2002 0:47 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
[JBoss-dev] XDoclet grammer needs to handle \u
I just ran into: [xdoclet] Error parsing org.jboss.ejb.plugins.CMPFilePersistenceManager:Lexical error at line 289, column 44. Encountered: u (117), after : \'\\ Where the code is: cmpField.setChar(instance,'\u'); I will not generate an interface for this, but we should get this fixed. XDoclet should allow this. --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] Automated JBoss(HEAD) Testsuite Results: 25-May-2002
Number of tests run: 744 Successful tests: 720 Errors:19 Failures: 5 [time of test: 25 May 2002 2:22 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-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20020124 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20020124/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
[JBoss-dev] server/src/resources/org/jboss/ejb/deployment/editors
Any idea what these files are for? Are they still used? Looks like it could be left overs from EJX? --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] MBean viewer ideas
Hi. Some interesting ideas. I do not think we can or should drop the HTML interface. It is very handy for administration on machines where you can not install a Java client app. I don't want to stop you from creating a SOAP adapter to JMX, which is what is sounds like you want to build... go for it. But we can't replace the HTML adapter with it, though we should replace it with something better at some point... that thing sucks. --jason On Friday 24 May 2002 09:23 am, Frederick N. Brier wrote: This is in regards to the MBean viewer on port 8082. Instead of using an HTML interface, what if we made it a SOAP interface with a Java Client? This could tie into JAAS security and limit access. I wrote a similar GUI on another Java project. I don't want to cause anyone nausea, but the UI was similar to Microsoft Management Console (MMC). Further, the MBean or SessionBean that was acting as the SOAP service could act as a broker for the same SOAP service running on every JBoss server in the cluster. For those not familiar with it, the MMC has a tree control in a pane to the left and the right pane is defined based on the tree node selected on the left side. The tree child nodes at each level are configurable, both by attributes such as hostname, domain(JMX), service, name, and type or fixed expressions or value lists. So the default which would look similar to now would be by domain name attribute which would yield nodes such as DefaultDomain, JMImplementation, or jboss.deployment. You could also have multiple configurations to look at your beans differently. For instance, if you had an MBean showing number of transactions per second, the tree could show that MBean service at the top node and then all the hostnames underneath it. So you could easily flick from node to note looking for bottlenecks. Of course, with all of the data as XML, you easily design new node/panel handlers that could display charts, graphs, aggregate tables of performance data, etc. One could even have the GUI plug into the MMC and become part of the standard Microsoft operating environment tee hee hee. We could also have the nodes extend into the attributes of an MBean. For instance, the Jetty MBean has a DeployedApplications attribute which is a java.util.Iterator which can't be displayed. Wouldn't it be nice to be able to have a table possibly with hyper-links to related MBeans? Another idea is how to provide better context help for the MBean viewer. This idea uses XDoclet to generate an XML file that could be bundled in the .jar containing the class files for the MBean. It would strip the JavaDoc from the class and data members from the MBean class. Instead of having a dialog pop up and say MBean Attribute you have a description of what it is, as well as the MBean itself. This information would be retrieved by the MBean Viewer SOAP service and provided to the GUI. Thoughts? Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ 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] server/src/resources/org/jboss/ejb/deployment/editors
That is legacy EJX junk. I removed it long ago I don't know why it is back. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 6:40 PM Subject: [JBoss-dev] server/src/resources/org/jboss/ejb/deployment/editors Any idea what these files are for? Are they still used? Looks like it could be left overs from EJX? --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
This is really strange... I end up with a null tx id (SpySession.currentTransactionId is null), so I updated my local copy of SpySession to limit access to currentTrasnactionId through a getter and setter, which appeared to limit the problem a little... though I only did it so I could get some logging going (as SpyXAResource and SpyMessageConsumer both had package protected access to the field. After running more iterations I was able to get this to fail. I hav yet to look at logs. The strange part is that I have 2 sperate vms each with a MDB listening for messages on the same remote queue (using oil il) and when this tx problem occurs, it occurs on both of them at approximatly the same time. Each listing node even has the same number of failures... which is very odd. Does anyong know if the tx methods which assign the xid should ever be null? I know that there are some explicit null's which I am going to replace with an unsetCurrentTransactionId() to be explicit, then throw an exception when setCurrentTransactionId(null) happens... as it appears to be invalid (unless I missed an changing one to use unset). I still have not changed my application to properly use the session and sender... as this is vastly more interesting... but I will have to get around to that eventually. --jason On Friday 24 May 2002 05:56 am, David Jencks wrote: I looked at the jmsra code a bit. You should be able to hold onto the session over method calls (new feature w/ new jca impl) but not anything you get from the session, such as the sender. The session may be associated with different physical connections on each (SFSB) call, and the sender will be tied to the physical connection it was originally created from. david jencks On 2002.05.24 03:41:03 -0400 Jason Dillon wrote: Or perhaps I am not using the JMS resource propertly within the bean... Should I be able to save a QueueSession and QueueSender as fields and use them over multipule calls inside of a SFSB? Or do I need to recreate the session and sender each time? If that is the case it rather sucks... what a pain... --jason On Friday 24 May 2002 12:22 am, Jason Dillon wrote: After thinking about this somemore, and enabling thread info in server.log I realize now that the timer is not an issue, there is never an instance where the timer thread attempts to use the wrapper over the SFSB... the work completes too fast. And due to the fact that I sync'd the wrapper methods it appears that this problem happens simply because the invoke happened in a seperate thread. Unfortunatly it does not really narrow the problem space to debug. The JMS RA does not function with out a TX, it does not attempt to start one if there isn't one already... so it just fails. Is it possible that there is something a miss with the bits which setup the tx for the SFSB? Or would I see other problems when the SFSB commits... I think this is the case, but I am not sure. If that is true, and the SFSB does have a TX, then it must be the JMS RA or JBossMQ which is at fault... and I don't really know how to isolate which it is at this point. If I don't use the JMS RA, then I have to implement all of the XA stuff myself, which I am sure to mess up. Any clue on how I could narrow the problem space any? I am running the same test again with trace enabled for org.jboss.mq and org.jboss.resource.adapter.jms. With the added log messages for the JMS RA I might be able to see a problem... but who knows. --jason On Thursday 23 May 2002 08:26 pm, Scott M Stark wrote: If the only cause of this can be use by multiple threads, then updating the error message to indicate incorrect usage would be good. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 24-May-2002
Number of tests run: 599
Successful tests: 598
Errors:1
Failures: 0
[time of test: 24 May 2002 20:20 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.3.1_03-b03]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.18-3]
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
Re: [JBoss-dev] MBean viewer ideas
Thank you. I didn't know about the jsr-77 stuff though. So first I'll review its features and design, and see what the architects think of the ideas. I might not get involved in that until after July, but I am interested in creating a management console. My first focus is first on the JBoss.net. Then there are a few other ideas that my application might require. One is support for replicated database servers such as those provided by mysql. I haven't seen anything in the docs about it. My thought is to enhance the JDBC connection pool MBean (Minerva?). It would list each slave as well as the master in the JDBC connection pool MBean. If the Master fails, you lose contact, can't ping it, etc, the pool is flushed and connections are created for the next slave in the list, possibly executing some code that would let the slave SQL server know it is now the master. The data source stays the same, and applications are none the wiser. I've never done mysql replication, and it is apparently a new and growing mysql feature, but I don't want to spring for an Oracle license if I don't have to. Fred. At 10:25 PM 5/24/2002, you wrote: Hi. Some interesting ideas. I do not think we can or should drop the HTML interface. It is very handy for administration on machines where you can not install a Java client app. I don't want to stop you from creating a SOAP adapter to JMX, which is what is sounds like you want to build... go for it. But we can't replace the HTML adapter with it, though we should replace it with something better at some point... that thing sucks. --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
