June 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2161) Allow the list of jndi names to contact in the CMR recovery module to be refreshed when a new CMR resource is added

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2161: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1091308|https://bugzilla.redhat.com/show_bug.cgi?id=1091308] from ASSIGNED to POST > Allow the list of jndi names to contact in the CMR recovery module to be refreshed when a new CMR resource is added > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2161 > URL: https://issues.jboss.org/browse/JBTM-2161 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Resource Manager > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > Currently the list is fixed at startup time as it is stored in a list, as there is no real performance impact of checking the list once every 120 seconds and it will allow resources to be more dynamically added (at least for recovery). > It would assist with: https://bugzilla.redhat.com/show_bug.cgi?id=1091308 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2192) Use org.jboss.logging.annotations instead of the old deprecated package

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2192?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2192: ----------------------------------- Issue Type: Bug (was: Feature Request) > Use org.jboss.logging.annotations instead of the old deprecated package > ----------------------------------------------------------------------- > > Key: JBTM-2192 > URL: https://issues.jboss.org/browse/JBTM-2192 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.3 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2192) Use org.jboss.logging.annotations instead of the old deprecated package

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2192: -------------------------------------- Summary: Use org.jboss.logging.annotations instead of the old deprecated package Key: JBTM-2192 URL: https://issues.jboss.org/browse/JBTM-2192 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Affects Versions: 5.0.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.0.3 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2137) JDBCStore recovery is too slow

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2137: -------------------------------- Fix Version/s: (was: 4.17.21) > JDBCStore recovery is too slow > ------------------------------ > > Key: JBTM-2137 > URL: https://issues.jboss.org/browse/JBTM-2137 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.3 > > > The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2183: -------------------------------- Fix Version/s: (was: 4.17.21) > Need finer grained control over which XAResource is used for recovery > --------------------------------------------------------------------- > > Key: JBTM-2183 > URL: https://issues.jboss.org/browse/JBTM-2183 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.20, 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.0.3 > > > During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery. > However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user". > The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) . > And finally, I I wonder if we want to make this new behaviour optional? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2191) CMR recovery fails if Sybase connection is down

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2191?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2191. ------------------------------- Resolution: Done > CMR recovery fails if Sybase connection is down > ----------------------------------------------- > > Key: JBTM-2191 > URL: https://issues.jboss.org/browse/JBTM-2191 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.20, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.21, 5.0.3 > > > If CMR recovery gets an exception removing old xids if the connection to the database is down it keeps retrying in a perpetual loop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2186) Probing the object store raises an error if the recovery manager has not performed a first pass

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2186?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2186. ------------------------------- Resolution: Done > Probing the object store raises an error if the recovery manager has not performed a first pass > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2186 > URL: https://issues.jboss.org/browse/JBTM-2186 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Resource Manager > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.21, 5.0.3 > > > ObjectStoreBrowser::probe requires that the recovery manager performs the first pass of recovery to load in the current in doubt Xids. This is not currently done so the user gets an error. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 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 commented on JBTM-2189: ------------------------------------- Hi Chris, Many thanks for your interest in Narayana. Normally for something like this it is best to start with a discussion on our forums over here: https://community.jboss.org/en/jbosstm. That said, please can you add a little more detail into the description as to the nature of the bug. We do already function in Java SE and also complex classloader hierarchies so this may be a corner case which we would be happy to work with you to address. I am not familiar with OneJar, is it a maven plugin that will put all the dependency jar classes into the same Jar as the application jar? The main problem with your report as it stands is that we don't have a well defined reason for _why_ the change needs to be made, if you can express the motivation for the change in more general terms then we can get it merged. As you say, the fix looks like it should work in our currently supported options so it shouldn't be a problem to get it merged once we have more context to backup the need to merge it. Once we understand the problem better, and we proceed with your approach, please can you: 1. Sign the CLA over here: https://cla.jboss.org/ (project is JBoss Transactions) 2. Fork: https://github.com/jbosstm/narayana 3. Raise a pull request on the main repo with your fix in. It should be easier to review inline, plus it will get CI run on it. Many thanks for the contribution! 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 > Security Level: Public(Everyone can see) > 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.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2182) [quickstart] NoClassDefFoundError on ArjunaJTA/maven

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2182?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2182: ------------------------------------- I merged this for the reported QS, I will leave it open till we have checked more of them. > [quickstart] NoClassDefFoundError on ArjunaJTA/maven > ---------------------------------------------------- > > Key: JBTM-2182 > URL: https://issues.jboss.org/browse/JBTM-2182 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator > Reporter: Andrew Rubinger > Assignee: Tom Jenkinson > Fix For: 5.0.3 > > > [INFO] --- exec-maven-plugin:1.2:exec (default-cli) @ maven --- > Exception in thread "main" java.lang.RuntimeException: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager; > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:81) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49) > at com.arjuna.ats.jta.common.jtaPropertyManager.getJTAEnvironmentBean(jtaPropertyManager.java:42) > at com.arjuna.ats.jta.TransactionManager.transactionManager(TransactionManager.java:71) > at TransactionManagerExample.main(TransactionManagerExample.java:39) > Caused by: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager; > at java.lang.Class.getDeclaredFields0(Native Method) > at java.lang.Class.privateGetDeclaredFields(Class.java:2570) > at java.lang.Class.getDeclaredFields(Class.java:1903) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:135) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:78) > ... 4 more > Caused by: java.lang.ClassNotFoundException: javax.transaction.TransactionManager > at java.net.URLClassLoader$1.run(URLClassLoader.java:372) > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:360) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 9 more > Probably due to Tx API being in provided scope, not included in exec:exec under src/java/main? > [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:provided > Also: NCDFE in javax_transaction/TransactionExample: > Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logging/Logger > Probably wanna audit the whole module; is this not tested in CI? Would suggest re-implementing perhaps as unit tests instead of Main classes. > From Mike: It gets run under CI regularly (and the last build was on 22-May-2014 16:13:23). I can't remember the last time it failed. You should be able to just check out the repo and type mvn clean install from the top > From Tom: I said that we might not run exec:exec in CI as some of the QS are quite intricate and difficult to script. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2190) Recovery is not run for XA datasource which does not define password under <security>

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2190?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2190: ------------------------------------- Hi Ondra, this looks like a JCA issue rather than a Narayana issue. I will move it for you. Thanks, Tom > Recovery is not run for XA datasource which does not define password under <security> > ------------------------------------------------------------------------------------- > > Key: JBTM-2190 > URL: https://issues.jboss.org/browse/JBTM-2190 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.20, 5.0.2 > Reporter: Ondřej Chaloupka > Assignee: Tom Jenkinson > Attachments: server.log > > > If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database. > When you define just: > {code} > <security> > <user-name>crashrec</user-name> > </security> > {code} > and database is set to not require password - e.g. for postgres > vim /var/lib/pgsql/data/pg_hba.conf > you define connection with 'trust' > host all all 127.0.0.1/32 trust > Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run > {code} > 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS > 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS > {code} > Whole configuration of xa-datasource used: > {code} > <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true"> > <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property> > <xa-datasource-property name="PortNumber">5432</xa-datasource-property> > <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property> > <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> > <driver>postgres</driver> > <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> > <xa-pool> > <min-pool-size>5</min-pool-size> > <max-pool-size>50</max-pool-size> > </xa-pool> > <security> > <user-name>crashrec</user-name> > </security> > <recovery> >  > </recovery> > <validation> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/> > </validation> > <timeout> > <blocking-timeout-millis>30000</blocking-timeout-millis> > <idle-timeout-minutes>15</idle-timeout-minutes> > </timeout> > <statement> > <prepared-statement-cache-size>75</prepared-statement-cache-size> > </statement> > </xa-datasource> > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues June 2014