[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
Mark Little edited comment on JBTM-1712 at 5/24/13 11:00 AM:
-------------------------------------------------------------
Agreed. Trivial change, which I can make it you want to assign it to me Tom.
was (Author: marklittle):
Agreed.
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4
> Reporter: Jonathan Halliday
> Assignee: Tom Jenkinson
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1691:
-------------------------------------
So, you are saying we didn't get a merge conflict? If you know the two revisions (master and 5_BRANCH) it would help here, thanks.
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1691:
-------------------------------------
It failed when compiling the AS. Essentially the AS ended up with a borked .java file that would not compile.
I think the auto-merge is coded to always "succeed". The problem is that it makes decisions even when it shouldn't. I think git generally handles merging transparently for the straight-forward cases and only creates a merge-conflict when human interaction is required. Therefore, I think we might always get a failed merge if we try to apply our merging strategy.
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by Jonathan Halliday (JIRA)
Jonathan Halliday created JBTM-1712:
---------------------------------------
Summary: perf problem in FileSystemStore.openAndLock
Key: JBTM-1712
URL: https://issues.jboss.org/browse/JBTM-1712
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Transaction Core
Affects Versions: 4.16.4
Reporter: Jonathan Halliday
Assignee: Tom Jenkinson
if(!file.exits())
{
if(createHierarchy(file))
incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
if(!file.getParent().exists())
{
if(createHierarchy(file))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1691:
-------------------------------------
That does make sense, it doesn't even need to be heavily modified. If they modify a single line that we do too this will happen.
At the moment we are optimized for success.
May I ask, did the build fail if the auto-merge did (as in straight after the merge, not as a consequence of it further down the line), if not that is the bug here?
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1691:
-------------------------------------
The merge failed again in CI. This time it was caused by upstream heavily modifying a file that we had already heavily modified. I don't have the conflict file anymore, but there was no way it could have been automatically merged.
It was however, quite obvious to me what had gone wrong.
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1710) CDI @Inject doesn't work in CompensationHandler et al
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1710:
-----------------------------------
Summary: CDI @Inject doesn't work in CompensationHandler et al
Key: JBTM-1710
URL: https://issues.jboss.org/browse/JBTM-1710
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: TXFramework
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M3
org.jboss.narayana.compensations.impl.Participant uses class.newInstance to create the handler instance. This means that Weld does not handle the @Inject annotation.
Creating the instance via the BeanManager solves this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1709) NPE during deploy the restat-web.war
by Amos Feng (JIRA)
Amos Feng created JBTM-1709:
-------------------------------
Summary: NPE during deploy the restat-web.war
Key: JBTM-1709
URL: https://issues.jboss.org/browse/JBTM-1709
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Application Server Integration, BlackTie
Reporter: Amos Feng
Assignee: Amos Feng
Fix For: 5.0.0.M3
http://172.17.131.2/job/blacktie-linux64-el5/1545/
{noformat}
13:38:34,246 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.deployment.default-host./rest-tx: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./rest-tx: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at io.undertow.servlet.core.CompositeThreadSetupAction$1.tearDown(CompositeThreadSetupAction.java:59)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:196)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:75)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
... 3 more
Caused by: java.lang.NullPointerException
at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.popMetaAwareObject(CachedConnectionManagerImpl.java:240)
at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.teardown(CachedConnectionManagerSetupProcessor.java:107)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$1$1.tearDown(UndertowDeploymentInfoService.java:214)
at io.undertow.servlet.core.CompositeThreadSetupAction$1.tearDown(CompositeThreadSetupAction.java:52)
... 7 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBTM-1707) JBTM-377 not able to download patch 4.4.CR2, 4.2.3.CP09 for jboss version 4.2.3.GA
by Sube Singh (JIRA)
[ https://issues.jboss.org/browse/JBTM-1707?page=com.atlassian.jira.plugin.... ]
Sube Singh commented on JBTM-1707:
----------------------------------
Hi,
Could you please confirm, can we use JBossTS 4.3.GA release for above mentioned problem.
Thanks,
Sube
> JBTM-377 not able to download patch 4.4.CR2, 4.2.3.CP09 for jboss version 4.2.3.GA
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1707
> URL: https://issues.jboss.org/browse/JBTM-1707
> Project: JBoss Transaction Manager
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: Recovery
> Environment: JBoss 4.2.3.GA
> Reporter: Sube Singh
> Assignee: Tom Jenkinson
> Labels: jboss
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> We are facing "WARN [arjLoggerI18N] [com.arjuna.ats.internal.arjuna.gandiva.inventory...." issue. To fix it we got to know about patch "4.4.CR2, 4.2.3.CP09" from url "https://issues.jboss.org/browse/JBTM-377" but did not find web-link to download the same patch.
> Please also suggest do we have to apply this patch or go for higher version of jboss that has fix of above discussed problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months