September 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1954) Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1954?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1954. --------------------------------- Resolution: Cannot Reproduce Bug It may be the case but it could have been an issue with the version of Jenkins too. Closing until we see it happen again. > Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails > ----------------------------------------------------------------- > > Key: JBTM-1954 > URL: https://issues.jboss.org/browse/JBTM-1954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > > If an axis of CI job jbossts-EAP61-jdbcobjectstore fails no files are archived. > The job config looks perfectly fine and the files are archived if the job is successful so maybe this is a Jenkins bug to do with multi-axis jobs. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1939) Consider using awestruct to develop http://narayana.io

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1939?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1939: -------------------------------- Assignee: Gytis Trikleris (was: Tom Jenkinson) > Consider using awestruct to develop http://narayana.io > ------------------------------------------------------ > > Key: JBTM-1939 > URL: https://issues.jboss.org/browse/JBTM-1939 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > Awestruct appears to be a powerful and flexible tool to develop websites with. This task is to research the capabilities of the tool and determine if the benefits of awestruct apply to our website. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2055) Add testing on WELD container

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2055?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2055: -------------------------------- Fix Version/s: (was: 6.0.0) > Add testing on WELD container > ----------------------------- > > Key: JBTM-2055 > URL: https://issues.jboss.org/browse/JBTM-2055 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2055) Add testing on WELD container

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2055?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2055. --------------------------------- Resolution: Incomplete Description > Add testing on WELD container > ----------------------------- > > Key: JBTM-2055 > URL: https://issues.jboss.org/browse/JBTM-2055 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1763) Consider running the QA tests in parrallel

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1763. --------------------------------- Resolution: Won't Fix Although it might be useful, we do not have any intention of doing this at this time and there are alternatives such as job config that could do this. > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1763) Consider running the QA tests in parrallel

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1763: -------------------------------- Fix Version/s: (was: 6.0.0) > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2150) Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2150?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2150. --------------------------------- Resolution: Won't Fix > Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION > ---------------------------------------------------------------------------------------- > > Key: JBTM-2150 > URL: https://issues.jboss.org/browse/JBTM-2150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > They should be able to infer this from the projects own pom files. > For narayana.sh it is in /pom.xml: > <jboss-as.version>8.0.1.Final-SNAPSHOT</jboss-as.version> > For narayana-quickstart/config it is in (for example) ./XTS/wsat-jta-multi_service/pom.xml: > <jboss-as.version>8.0.1.Final-SNAPSHOT</jboss-as.version> -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2189) Bootstrapping from Complex Classloader (OneJar)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2189?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2189. --------------------------------- Resolution: Incomplete Description Hi Chris, As per my comment earlier in the year, I am going to have to close this issue as incomplete. Thanks for your interest and please do feel free to complete the details and re-open. Tom > Bootstrapping from Complex Classloader (OneJar) > ----------------------------------------------- > > Key: JBTM-2189 > URL: https://issues.jboss.org/browse/JBTM-2189 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Common > Affects Versions: 5.0.1 > Environment: JDK 8, OneJar 0.97 > Reporter: Chris Pheby > Assignee: Tom Jenkinson > > I am using Narayana within a JavaSE application. The application is compiled into a single Jar. When executing, Narayana fails to bootstrap properly. > The first problem is within com.arjuna.common.util.ConfigurationInfo. > Lines 111-115 aim to load the MANIFEST file from the classpath: > String pathToManifest = basePath+"/META-INF/MANIFEST.MF"; > InputStream is = null; > try { > is = new URL(pathToManifest).openStream(); > I replaced this with: > InputStream is = null; > // BEGIN - WORKAROUND FOR ONE-JAR > try { > String targetPrefix = pathToThisClass.substring(0, pathToThisClass.length() - "/com/arjuna/common/util/ConfigurationInfo.class".length()); > Enumeration<URL> resources = ConfigurationInfo.class.getClassLoader().getResources("META-INF/MANIFEST.MF"); > while (resources.hasMoreElements()) { > URL next = resources.nextElement(); > if (next.toString().startsWith(targetPrefix)) { > is = next.openStream(); > break; > } > } > // END - WORKAROUND FOR ONE-JAR > This should work for all environments. > Changes are also required in com.arjuna.common.util.propertyservice.AbstractPropertiesFactory to attempt loading from classpath as well as file system: > The last line of initDefaultProperties (195) needed changing to: > defaultProperties = getPropertiesFromClasspath(propertyFileName, PropertiesFactoryStax.class.getClassLoader()); > if (defaultProperties == null) { > defaultProperties = getPropertiesFromFile(propertyFileName, PropertiesFactoryStax.class.getClassLoader()); > } > } > and the following methods added / replaced: > /** > * Returns the config properties read from a specified relative location on the classpath. > * > * @param propertyFileName the file name relative to the classpath root. > * @return the Properties loaded from the specified source. > */ > public Properties getPropertiesFromClasspath(String propertyFileName, ClassLoader classLoader) { > Properties properties = null; > > try { > Enumeration<URL> resources = ConfigurationInfo.class.getClassLoader().getResources(propertyFileName); > while (resources.hasMoreElements()) { > URL next = resources.nextElement(); > > properties = loadFromStream(next.openStream()); > return properties; > } > } catch(Exception e) { > return null; > } > return properties; > } > > /** > * Returns the config properties read from a specified location. > * > * @param propertyFileName the file name. If relative, this is located using the FileLocator algorithm. > * @return the Properties loaded from the specified source. > */ > public Properties getPropertiesFromFile(String propertyFileName, ClassLoader classLoader) { > String propertiesSourceUri = null; > try > { > // This is the point where the search path is applied - user.dir (pwd), user.home, java.home, classpath > propertiesSourceUri = com.arjuna.common.util.propertyservice.FileLocator.locateFile(propertyFileName, classLoader); > } > catch(FileNotFoundException fileNotFoundException) > { > // try falling back to a default file built into the .jar > // Note the default- prefix on the name, to avoid finding it from the .jar at the previous stage > // in cases where the .jar comes before the etc dir on the classpath. > URL url = AbstractPropertiesFactory.class.getResource("/default-"+propertyFileName); > if(url == null) { > throw new RuntimeException("missing property file "+propertyFileName); > } else { > propertiesSourceUri = url.toString(); > } > } > catch (IOException e) > { > throw new RuntimeException("invalid property file "+propertiesSourceUri, e); > } > Properties properties = null; > try { > properties = loadFromFile(propertiesSourceUri); > properties = applySystemProperties(properties); > } catch(Exception e) { > throw new RuntimeException("unable to load properties from "+propertiesSourceUri, e); > } > return properties; > } > private Properties loadFromStream(InputStream inputStream) throws IOException { > Properties inputProperties = new Properties(); > Properties outputProperties = new Properties(); > try { > loadFromXML(inputProperties,inputStream); > } finally { > inputStream.close(); > } > Enumeration namesEnumeration = inputProperties.propertyNames(); > while(namesEnumeration.hasMoreElements()) { > String propertyName = (String)namesEnumeration.nextElement(); > String propertyValue = inputProperties.getProperty(propertyName); > propertyValue = propertyValue.trim(); > // perform JBossAS style property substitutions. JBTM-369 > propertyValue = StringPropertyReplacer.replaceProperties(propertyValue); > outputProperties.setProperty(propertyName, propertyValue); > } > return outputProperties; > } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1965) Add support for XADisk

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1965: -------------------------------- Assignee: (was: Tom Jenkinson) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2216) Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2216?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2216. --------------------------------- Resolution: Done Resolved in https://github.com/jbosstm/narayana/commit/18f1884ee15da0c2ec6a2a33e2bdac... > Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed > ----------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2216 > URL: https://issues.jboss.org/browse/JBTM-2216 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.20, 4.17.21, 5.0.2 > Environment: JBoss EAP 6.3 > Reporter: Tom Ross > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > When using AMQ failover protocol, the Narayana recovery process generates the following exception: > {noformat} > 10:19:36,053 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Failover transport not connected: unconnected > at org.apache.activemq.TransactionContext.recover(TransactionContext.java:656) > at org.apache.activemq.ra.LocalAndXATransaction.recover(LocalAndXATransaction.java:135) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.recover(XAResourceWrapperImpl.java:177) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:548) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:187) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > 10:21:56,165 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:619) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > {noformat} > Although the first message may be expected if the resource manager throws an exception in XAResource::recover(), the second message does not add any further assistance in resolving the issue and should be removed as noise. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2014