Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data 3.1.diff Description: Binary data
Re: [JBoss-dev] [ jboss-Bugs-590816 ] XAProto Errors on closed XAResources
I think I may have tracked down the SwiftMQ bug... let me know if this sounds right. SwiftMQ doesn't support start(suspend), so they return false for all calls to isSameRM(). This should cause all connections being enlisted to be given a unique xid (with different branch qualifiers). I think this is compliant with the JTA and XA specs. In enlistResource (TransactionImpl:535), a check is made to see if this RM is already enlisted (call to findResource). But, this check uses an equality test. If you are enlisting a connection that was previously closed in the same transcation scope, then this will find the old resource, and attempt to re-enlist with a TMJOIN, which on SwiftMQ yields an XAException (PROTO?). Basically, we can't assume that (resource1 == resource2) implies (resource1.isSameRM(resource2)). The problem now is that the TM must be able to enlist the same resource multiple times with different branch-ids, and then figure out which xid to use on the next call to delist. I have attached a patch (one for JBoss 3.1 one for JBoss 3.0) that I think fixes the problem. Please let me know what you think. -Larry 3.0.diff Description: Binary data 3.1.diff Description: Binary data
[JBoss-dev] XAConnection close problems
(JBoss Branch_3_0, though I've also verified this on HEAD) I think I've discovered a source of generic XA_PROTO errors. When an XA connection is closed (see org/jboss/resource/connectionmanager/XATxConnectionManager$XAConnectionEventListener.connectionClosed[306]), it is first delisted from the Transaction Manager. It used to be called with XAResource.TMSUCCESS, but about 5 weeks ago it was changed to use XAResource.TMSUSPEND. This connection is now put back in the available pool. Unfortunately, when the transaction is committed, it must first be re-enlist the resource and end it with a TMSUCCESS (see TxCapsule (3.0) or TransactionImpl (3.1) method, endResources). The problem occurs if that connecction has been handed out to a requesting client, and it is already within the scope of another transaction. The solutions I can see are: 1) Change back to TMSUCCESS on connectionClosed 2) Do not put the connection back in the pool until it has been ended with either TMSUCCESS or TMFAIL 3) As per the comments in TxCapsule (and TransactionImpl) do not re-enlist a suspended transaction before ending it. This apparently violates the JTA spec, but complies with the XA/Open spec - perhaps an option could be set to toggle this? Did I miss something? Which of these solutions do you recommend? Thanks -Larry
Re: [JBoss-dev] is x++ an atomic operation??
The jguru article is not accurate.
Given the code:
public class Test {
public int testInc(int x) {
x++;
return x;
}
public int testAdd(int x) {
x = x + 1;
return x;
}
}
This produces the following byte-code:
Method Test()
0 aload_0
1 invokespecial #1 Method java.lang.Object()
4 return
Method int testInc(int)
0 iinc 1 1
3 iload_1
4 ireturn
Method int testAdd(int)
0 iload_1
1 iconst_1
2 iadd
3 istore_1
4 iload_1
5 ireturn
Note the single operation for the incrementor (iinc 1 1). I do not know if
this operation is atomic or not, but this invalidates the logic of the jguru
post.
-Larry
- Original Message -
From: Rhett Aultman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 18, 2002 6:24 AM
Subject: RE: [JBoss-dev] is x++ an atomic operation??
I'm fairly sure that the increment/decrement operators are not atomic.
Hm...here's a post on Jguru showing why:
http://www.jguru.com/forums/view.jsp?EID=384082
Additionally, I think the statement that you gave in your example would be
non-atomic anyway- even if an increment was atomic, you're first performing
the increment, then storing it in a second variable. That's a two-step
process, regardless of atomicity in the increment.
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 18, 2002 8:55 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] is x++ an atomic operation??
Quick question for you Java Language Gurus out there, I heard one that the
post increment operator was an atomic operation. For example, if you have a
multi-threaded application with:
id=lastRequestId++;
You would not need to put this in a synchronized block be cause the ++ would
be atomic and thus you would not get 2 duplicate ids. I was wondering if
this is true or not. Can anybody confirm this for me??
Regards,
Hiram
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is x++ an atomic operation??
Ah - you are correct. Here is the byte-code for the incrementor with a
member variable:
Method Test()
0 aload_0
1 invokespecial #1 Method java.lang.Object()
4 return
Method int testInc()
0 aload_0
1 dup
2 getfield #2 Field int x
5 iconst_1
6 iadd
7 putfield #2 Field int x
10 aload_0
11 getfield #2 Field int x
14 ireturn
Method int testAdd()
0 aload_0
1 aload_0
2 getfield #2 Field int x
5 iconst_1
6 iadd
7 putfield #2 Field int x
10 aload_0
11 getfield #2 Field int x
14 ireturn
These two methods are now identical, and obviously not atomic. Thanks.
-Larry
- Original Message -
From: Kevin Conner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 18, 2002 7:19 AM
Subject: RE: [JBoss-dev] is x++ an atomic operation??
You know...something seemed odd about it, but I was going to
go with it anyway...I'm still pretty sure that an increment
operation is not atomic, but I can't be sure.
Regardless, the example statement given in the original post
was something like:
x = y++;
And I'm almost 100% certain that's not atomic, as the
increment of y and assignment to x are two separate operations.
The increment of y is not guaranteed to be atomic as it involves
a read, an increment and then a write. These operations may be
interleaved with operations on another thread. This is before
you have the assigment to x.
The iinc operator is only for local method variables and therefore
not visible in other threads. If you change the code to the following
then you should see different bytecode.
public class Test {
private int x ; // instance variable
public int testInc() {
x++;
return x;
}
public int testAdd() {
x = x + 1;
return x;
}
}
Kev
Kevin Conner
Orchard Information Systems Limited
Newcastle Technopole, Kings Manor
Newcastle Upon Tyne, NE1 6PA. United Kingdom
Registered in England, Number 1900078
Tel: +44 (0) 191-2032536 Fax: +44 (0) 191 2302515
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] sar startup ordering
I set it up so non-numbered deployments deploy last. It seemed that someone who required that kind of control over ordering would only need it for the first deployments. Should I change it so that non-numbered deployments deploy first? -Larry - Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 03, 2002 5:49 AM Subject: RE: [JBoss-dev] sar startup ordering This should be the default comparator, I have been saying it for about 4 month, Main Deployer is part of the System, marcf PS: please patch HEAD with this, |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Per |Nyfelt |Sent: Monday, June 03, 2002 12:31 AM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] sar startup ordering | | |I ended up creating my own Comparator since i want the |non-numbered files to |deploy first using the rules of the DeploymentSorter and then deploy |according to their numbered prefix. In order to actually use is |however, the |only way I found that worked was to add my class to jboss-system.jar, |otherwise i got a ClassNotFoundException (e.g. when jaring it up |and putting |the jar in lib). Is this a bug or intended? | |Best regards, |Per | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of | lsanders | Sent: Thursday, May 30, 2002 4:59 PM | To: [EMAIL PROTECTED] | Subject: Re: [JBoss-dev] sar startup ordering | | | This has been available since (I think) 3.0 RC2. Take a look at | the default | jboss-service.xml file. At the bottom in the Deployment | Scanning section, | look for an attribute named URLComparator. The default comparator | (DeploymentSorter) sorts by type in this order: *.sar, |*service.xml, *rar, | *jar, *war, *wsr, *ear, *zip, *. | | There is a second comparator (commented out) called | PrefixDeploymentSorter. | If you use this then all deployments that start with a numeric |prefix will | be deployed in order of those prefixes. Non-prefixed deployments are | deployed last. Ties are broken using the sorting from DeploymentSorter | above. | | If this is still not cutting it, then you are free to implement | an instance | of java.util.Comparator that is capable of comparing two URL objects. | | -Larry | | - Original Message - | From: Per Nyfelt [EMAIL PROTECTED] | To: Jboss-Development@Lists. Sourceforge. Net | [EMAIL PROTECTED] | Sent: Thursday, May 30, 2002 6:29 AM | Subject: [JBoss-dev] sar startup ordering | | | I've been trying to find what was decided for how to specify in | what order | sar archives should be loaded and started, but the mail |discussions I've | found points in many different directions. Could anyone please set me | straight? | | I have a jxta.sar that i want to start before a ozone.sar | From what i can see from testing the following works: | | 1. Label them 10-jxta.sar and 20-ozone.sar | | 2. keep the names but make sure the timestamp of the jxta.sar |is earlier | than the ozone.sar | | Is there any mechanism that allows this behaviour to be configured? | | Best regards, | Per | | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | ___ | | Don't miss the 2002 Sprint PCS Application Developer's Conference | August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
Re: [JBoss-dev] sar startup ordering
The best solution I have found is to use the classpath... / tag in your default jboss-service.xml. Certainly putting it in your jboss-system.jar seems a bit extreme. -Larry - Original Message - From: Per Nyfelt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 03, 2002 12:30 AM Subject: RE: [JBoss-dev] sar startup ordering I ended up creating my own Comparator since i want the non-numbered files to deploy first using the rules of the DeploymentSorter and then deploy according to their numbered prefix. In order to actually use is however, the only way I found that worked was to add my class to jboss-system.jar, otherwise i got a ClassNotFoundException (e.g. when jaring it up and putting the jar in lib). Is this a bug or intended? Best regards, Per -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of lsanders Sent: Thursday, May 30, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] sar startup ordering This has been available since (I think) 3.0 RC2. Take a look at the default jboss-service.xml file. At the bottom in the Deployment Scanning section, look for an attribute named URLComparator. The default comparator (DeploymentSorter) sorts by type in this order: *.sar, *service.xml, *rar, *jar, *war, *wsr, *ear, *zip, *. There is a second comparator (commented out) called PrefixDeploymentSorter. If you use this then all deployments that start with a numeric prefix will be deployed in order of those prefixes. Non-prefixed deployments are deployed last. Ties are broken using the sorting from DeploymentSorter above. If this is still not cutting it, then you are free to implement an instance of java.util.Comparator that is capable of comparing two URL objects. -Larry - Original Message - From: Per Nyfelt [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 6:29 AM Subject: [JBoss-dev] sar startup ordering I've been trying to find what was decided for how to specify in what order sar archives should be loaded and started, but the mail discussions I've found points in many different directions. Could anyone please set me straight? I have a jxta.sar that i want to start before a ozone.sar From what i can see from testing the following works: 1. Label them 10-jxta.sar and 20-ozone.sar 2. keep the names but make sure the timestamp of the jxta.sar is earlier than the ozone.sar Is there any mechanism that allows this behaviour to be configured? Best regards, Per ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] UDS DeployedURL.watchedUrl
This sounds like something I added for exploded deployments. (the url to watch for redeployment is the app-specific xml: ejb-jar.xml for ejbs, application.xml for ears, ...) It is an MBean operation in MainDeployer that returns the corresponding DeploymentInfo's watch field. -Larry Can someone please explain to me what DeployedURL.watchedUrl is for? --jason - This mail sent through IMP: http://horde.org/imp/ ___ 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
