[JBoss JIRA] (JBTM-1645) Allow pull requests to configure some parameters in scripts/hudson/narayana.sh
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1645?focusedWorklogId=12429695&page=... ]
Gytis Trikleris logged work on JBTM-1645:
-----------------------------------------
Author: Gytis Trikleris
Created on: 29/Aug/13 9:55 AM
Start Date: 29/Aug/13 9:55 AM
Worklog Time Spent: 40 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 1 hour)
Time Spent: 1 hour, 40 minutes (was: 1 hour)
Worklog Id: (was: 12429695)
> Allow pull requests to configure some parameters in scripts/hudson/narayana.sh
> ------------------------------------------------------------------------------
>
> Key: JBTM-1645
> URL: https://issues.jboss.org/browse/JBTM-1645
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M5
>
> Original Estimate: 4 hours
> Time Spent: 1 hour, 40 minutes
> Remaining Estimate: 0 minutes
>
> If the pull description has something like this:
> export NARAYANA_BUILD=1 AS_BUILD=1 NARAYANA_TESTS=1 TXF_TESTS=1 XTS_TESTS=1 XTS_AS_TESTS=1 txbridge=1 QA_TESTS=1 [SUN_ORB=0] [JAC_ORB=1] [QA_TARGET=ci-jts-tests]
> We could use it in scripts/hudson/narayana.sh if we detect it is a pull build. We might need to white list users we apply this to.
--
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
11 years, 4 months
[JBoss JIRA] (JBTM-1902) Build number of Narayana is not resolved, says ${buildNumber}
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1902?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1902:
-------------------------------------
Amos,
Can you take a look at this as I don't have time at the moment. We already have the buildnumber-maven-plugin in our root pom and it is now set to a version that supports git. We also seem to have the scm block set in the root pom. However, ${buildNumber} is still not resolving. We don't have it configured as it suggests in the following doc, which may be the problem. However, I have tried configuring it as suggested, but it is still not being resolved.
http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html
Also, I think we need the following config, when you do get it working:
{code}
<configuration>
<!-- gives us a short SHA1 instead of the full commit id -->
<shortRevisionLength>5</shortRevisionLength>
<!-- allows us to do a build with un-committed files. Essential for development -->
<doCheck>false</doCheck>
<!-- Doesn't do a git update during build. Essential for development -->
<doUpdate>false</doUpdate>
</configuration>
{code}
> Build number of Narayana is not resolved, says ${buildNumber}
> -------------------------------------------------------------
>
> Key: JBTM-1902
> URL: https://issues.jboss.org/browse/JBTM-1902
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Radoslav Husar
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
>
> Logs say..
> {noformat}
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {noformat}
> which is not very useful :-)
--
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
11 years, 4 months
[JBoss JIRA] (JBTM-1902) Build number of Narayana is not resolved, says ${buildNumber}
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1902?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1902:
-------------------------------------
It's still present in M4, and probably has been there ever since we moved to git.
> Build number of Narayana is not resolved, says ${buildNumber}
> -------------------------------------------------------------
>
> Key: JBTM-1902
> URL: https://issues.jboss.org/browse/JBTM-1902
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Radoslav Husar
> Assignee: Paul Robinson
> Priority: Minor
>
> Logs say..
> {noformat}
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {noformat}
> which is not very useful :-)
--
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
11 years, 4 months
[JBoss JIRA] (JBTM-1902) Build number of Narayana is not resolved, says ${buildNumber}
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1902?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1902:
-------------------------------------
Working on a fix now. The plan is to have the short SHA1 of the git commit as the revision number.
> Build number of Narayana is not resolved, says ${buildNumber}
> -------------------------------------------------------------
>
> Key: JBTM-1902
> URL: https://issues.jboss.org/browse/JBTM-1902
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Radoslav Husar
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M5
>
>
> Logs say..
> {noformat}
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {noformat}
> which is not very useful :-)
--
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
11 years, 4 months
[JBoss JIRA] (JBTM-1902) Build number of Narayana is not resolved, says ${buildNumber}
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1902?page=com.atlassian.jira.plugin.... ]
Paul Robinson moved WFLY-1932 to JBTM-1902:
-------------------------------------------
Project: JBoss Transaction Manager (was: WildFly)
Key: JBTM-1902 (was: WFLY-1932)
Issue Type: Bug (was: Enhancement)
Affects Version/s: (was: 8.0.0.Beta1)
Component/s: Build System
(was: Transactions)
Security: Public
> Build number of Narayana is not resolved, says ${buildNumber}
> -------------------------------------------------------------
>
> Key: JBTM-1902
> URL: https://issues.jboss.org/browse/JBTM-1902
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Radoslav Husar
> Assignee: Paul Robinson
> Priority: Minor
>
> Logs say..
> {noformat}
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {noformat}
> which is not very useful :-)
--
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
11 years, 4 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1712:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 968125|https://bugzilla.redhat.com/show_bug.cgi?id=968125]
Verified existence of the patch under 6.1.1.ER7
> 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, 5.0.0.M2
> Reporter: Jonathan Halliday
> Assignee: Mark Little
> Fix For: 4.17.6, 5.0.0.M3
>
>
> 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
11 years, 4 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1712:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 968125|https://bugzilla.redhat.com/show_bug.cgi?id=968125] from ON_QA to VERIFIED
> 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, 5.0.0.M2
> Reporter: Jonathan Halliday
> Assignee: Mark Little
> Fix For: 4.17.6, 5.0.0.M3
>
>
> 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
11 years, 4 months