Original problem was that a customer was gettting an Caused by: java.util.NoSuchElementException when trying to recover from a failed transaction. The bug is from the concurrent.jar(oswego). Adrian patched the oswego jar and rebuilt it in JBAS-4698. it just needs to be included in the build.
Description
Original problem was that a customer was gettting an Caused by: java.util.NoSuchElementException when trying to recover from a failed transaction. The bug is from the concurrent.jar(oswego). Adrian patched the oswego jar and rebuilt it in JBAS-4698. it just needs to be included in the build.
Fernando Nasser [22/Oct/07 09:35 AM]
We don't ship binary JAs, we build all from source.
It seems that Adrian used patches from the oswego site:
Adrian Brock [11/Sep/07 09:54 AM]
The two "unreleased fixes" described at the bottom of here:
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
have been applied as patches to create an oswego-concurrent:1.3.4-jboss
We could try and find those same patches and apply to our build if our concurrent version is the same (latest).
If the concurrent version is newer than the one we are currently using, you will need to assing this JIRA to "Patch Triage Team" for review.
Regards.
Yep Adrian wisely fixed the code and added a new version in the repository(1.3.4-jboss). The previous version was 1.3.4-brew. Oswego is not releasing any more builds because they are in maintenance. Matter of fact, these fixes weren't released as a package, but were available as individual files on the site. 1.3.4 is the last version that will ever be released from them.
The original problem that Adrian fixed is that values, keySet, and entrySet toArray() methods were not thread safe. Adrian put a fix in there that used an iterator to build a secondary collection that we then call toArray with. This was the bug that was fixed. JBAS-4698. It doesn't look like that fix was ever moved into the cp. Actually there were a couple fixes in the oswego libraries that Adrian fixed, that didn't look like they were in EAP 4.2 CP/4.3. The version of the oswego libaries that was released for this fix(it went into 4.2.2) was 1.3.4-jboss(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss/)
The problem with the 1.3.4-jboss fix is that if an entry is removed, then it leaves a null in the map. When iterating through the collections the null would be propagated to the temporary collection being used to convert to an array. The end result was that when toArray() is called, it throws a null pointer exception. So the new version 1.3.4-jboss-update1 has that fix in there. So I put a check for a null in there for the values, keyset, and entry collections. This version of the oswego libraries that was just released is 1.3.4-jboss-update1.(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss-update1).
My plan is to change the build-thirdparty.xml file to reflect the new version. I also had to change the component-info.xml file in jbossxb version 1.0.0SP1-brew to reflect the compatibility with the new version of concurrent.jar.(http://repository.jboss.com/jboss/jbossxb/1.0.0.SP1-brew/component-info.xml)
I had assumed that the same build process for EAP as AS, is that an incorrect assumption. The build-thirdparty.xml file holds the versions that are to be looked up in the repository. The version is then fetched from the repository and build. I have put a new version up in the repository. The build seems to run fine with the new entry in build-thirdpary. Does EAP build do the same thing? I had made the assumption that it did.
Jay:)
Jay Howell [12/Dec/07 11:39 PM]
Yep Adrian wisely fixed the code and added a new version in the repository(1.3.4-jboss). The previous version was 1.3.4-brew. Oswego is not releasing any more builds because they are in maintenance. Matter of fact, these fixes weren't released as a package, but were available as individual files on the site. 1.3.4 is the last version that will ever be released from them.
The original problem that Adrian fixed is that values, keySet, and entrySet toArray() methods were not thread safe. Adrian put a fix in there that used an iterator to build a secondary collection that we then call toArray with. This was the bug that was fixed. JBAS-4698. It doesn't look like that fix was ever moved into the cp. Actually there were a couple fixes in the oswego libraries that Adrian fixed, that didn't look like they were in EAP 4.2 CP/4.3. The version of the oswego libaries that was released for this fix(it went into 4.2.2) was 1.3.4-jboss(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss/)
The problem with the 1.3.4-jboss fix is that if an entry is removed, then it leaves a null in the map. When iterating through the collections the null would be propagated to the temporary collection being used to convert to an array. The end result was that when toArray() is called, it throws a null pointer exception. So the new version 1.3.4-jboss-update1 has that fix in there. So I put a check for a null in there for the values, keyset, and entry collections. This version of the oswego libraries that was just released is 1.3.4-jboss-update1.(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss-update1).
My plan is to change the build-thirdparty.xml file to reflect the new version. I also had to change the component-info.xml file in jbossxb version 1.0.0SP1-brew to reflect the compatibility with the new version of concurrent.jar.(http://repository.jboss.com/jboss/jbossxb/1.0.0.SP1-brew/component-info.xml)
I had assumed that the same build process for EAP as AS, is that an incorrect assumption. The build-thirdparty.xml file holds the versions that are to be looked up in the repository. The version is then fetched from the repository and build. I have put a new version up in the repository. The build seems to run fine with the new entry in build-thirdpary. Does EAP build do the same thing? I had made the assumption that it did.
Jay:)
I am reverting your change in the branch. Please peovide a source code diff against oswego-concurrent 1.3.4 so we can rebuild it with the patch. You can attach it to this JIRA and leave the building, uploading etc to us.
Fernando Nasser [13/Dec/07 09:27 AM]
Sorry Jay, we can't use binary JARs in EAP.
I am reverting your change in the branch. Please peovide a source code diff against oswego-concurrent 1.3.4 so we can rebuild it with the patch. You can attach it to this JIRA and leave the building, uploading etc to us.
Regards,
Fernando
Fernando Nasser [24/Jan/08 02:42 PM]
Branch upgraded to 1.3.4.patch01-brew (which contain the 3 patches).
Hudson tests run and <compatible> lines added to Messaging and JBossXB.
Task
Resolved
Major
Merge JBAS-4698 into the next CP. This effectively fixes the oswego library. Several defects were found, including an unthreadsafe call to toArray().
It seems that Adrian used patches from the oswego site:
Adrian Brock [11/Sep/07 09:54 AM]
The two "unreleased fixes" described at the bottom of here:
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
have been applied as patches to create an oswego-concurrent:1.3.4-jboss
We could try and find those same patches and apply to our build if our concurrent version is the same (latest).
If the concurrent version is newer than the one we are currently using, you will need to assing this JIRA to "Patch Triage Team" for review.
Regards.