May 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.

by Weinan Li (JIRA)

[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ] Weinan Li commented on JBTM-1695: --------------------------------- Hi Tom, I'm working on this with Paul one by one. After I change the dir structure of one component, I'll rerun mvn install on whole project to make sure I don't break anything. For what I've seen most of these legacy components could be restructured to maven standard one. If there are some more complex situations we could discuss on it then, wdyt? > Change the 'common' module to use the normal maven convention for source layout. > -------------------------------------------------------------------------------- > > Key: JBTM-1695 > URL: https://issues.jboss.org/browse/JBTM-1695 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Weinan Li > > The common module doesn't use the normal maven convention for source layout. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1694) upload orson and emma to repository.jboss.org

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1694?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1694: ------------------------------------- Hi Weinan, We may/may not continue to use emma in the future so I would be reluctant to add that, especially as we are using a custom fork but only for community testing. I may instead move the use of emma to a specific profile that you do not need to activate. On the other hand, we can look at the licence for orson and upload that one if it is permitted. Thanks, Tom > upload orson and emma to repository.jboss.org > --------------------------------------------- > > Key: JBTM-1694 > URL: https://issues.jboss.org/browse/JBTM-1694 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Weinan Li > Assignee: Tom Jenkinson > > Currently in ArjunaCore/arjuna/pom.xml: > {code} > <systemPath>${orson.jar.location}/../qa/dbdrivers/jConnect-6_0/classes/jconn3.jar</systemPath> > {code} > And user need to download orson.jar from internet and set orson jar location manually. Is it okay that we upload the jars to repository.jboss.org? -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1695: ------------------------------------- Hi Weinan, We left as much of the old builds directory structure in place as maven could cope with. Please can you clarify if there is an EAP issue with the code in these folders as we have previously decided not to make cosmetic changes to the structure? Tom > Change the 'common' module to use the normal maven convention for source layout. > -------------------------------------------------------------------------------- > > Key: JBTM-1695 > URL: https://issues.jboss.org/browse/JBTM-1695 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 4.17.4 > Reporter: Weinan Li > Assignee: Weinan Li > > The common module doesn't use the normal maven convention for source layout. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1697) AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1697?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1697: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/blacktie/pull/48 > AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1 > ------------------------------------------------------------------------- > > Key: JBTM-1697 > URL: https://issues.jboss.org/browse/JBTM-1697 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/job/blacktie-linux64-el5/1528/ > {noformat} > 06:38:31,520 INFO [AdvertiseUnadvertiseTest] (default task-2) Got the exception > 06:38:31,872 ERROR [org.jboss.remoting.remote.connection] (Remoting "beacon:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > 06:38:32,400 INFO [org.hornetq.ra] (default-threads - 1) HQ151001: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2c717166 destination=queue/BTR_BTStompAdmin destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > 06:38:36,876 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (default task-2) Could not deploy queue of .testsui1: java.io.IOException: java.net.ConnectException: > JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > {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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1697) AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1697?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1697: --------------------------------- http://172.17.131.2/job/blacktie-windows2008-taconic/297/ > AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1 > ------------------------------------------------------------------------- > > Key: JBTM-1697 > URL: https://issues.jboss.org/browse/JBTM-1697 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/job/blacktie-linux64-el5/1528/ > {noformat} > 06:38:31,520 INFO [AdvertiseUnadvertiseTest] (default task-2) Got the exception > 06:38:31,872 ERROR [org.jboss.remoting.remote.connection] (Remoting "beacon:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > 06:38:32,400 INFO [org.hornetq.ra] (default-threads - 1) HQ151001: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2c717166 destination=queue/BTR_BTStompAdmin destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > 06:38:36,876 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (default task-2) Could not deploy queue of .testsui1: java.io.IOException: java.net.ConnectException: > JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > {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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1692) Tx tests failed with restat errors

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1692?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1692: --------------------------------- http://172.17.131.2/job/blacktie-windows2008-taconic/295/console > Tx tests failed with restat errors > ---------------------------------- > > Key: JBTM-1692 > URL: https://issues.jboss.org/browse/JBTM-1692 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.0.M3 > > > http://172.17.131.2/job/blacktie-windows2008-taconic/294/ > http://172.17.131.2/job/blacktie-linux32-el5/961/ > http://172.17.131.2/job/blacktie-linux64-el5/1526/ > {noformat} > 00:44:57,846 WARN [org.jboss.resteasy.plugins.providers.RegisterBuiltin] (default task-36) NoClassDefFoundError: Unable to load builtin provider: org.jboss.resteasy.plugins.validation.hibernate.HibernateValidatorContextResolver > 00:44:57,854 INFO [org.jboss.resteasy.spi.ResteasyDeployment] (default task-36) Deploying javax.ws.rs.core.Application: class org.jboss.jbossts.star.service.TMApplication > 00:44:57,856 ERROR [io.undertow.request] (default task-36) Servlet request failed io.undertow.server.HttpServerExchange@13c6c59: java.lang.LinkageError: org/jboss/resteasy/spi/validation/GeneralValidator > [exec] 2013-05-16 00:44:48,645 [0x00001c10] INFO (TxHttpTxManager :116 ) - Unable to start a new txn on URI > {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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1697) AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1697?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1697: --------------------------------- http://172.17.131.2/job/blacktie-windows2008-taconic/296/console > AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1 > ------------------------------------------------------------------------- > > Key: JBTM-1697 > URL: https://issues.jboss.org/browse/JBTM-1697 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/job/blacktie-linux64-el5/1528/ > {noformat} > 06:38:31,520 INFO [AdvertiseUnadvertiseTest] (default task-2) Got the exception > 06:38:31,872 ERROR [org.jboss.remoting.remote.connection] (Remoting "beacon:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > 06:38:32,400 INFO [org.hornetq.ra] (default-threads - 1) HQ151001: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2c717166 destination=queue/BTR_BTStompAdmin destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > 06:38:36,876 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (default task-2) Could not deploy queue of .testsui1: java.io.IOException: java.net.ConnectException: > JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > {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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1697) AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1697?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1697: --------------------------------- http://172.17.131.2/job/blacktie-linux64-el5/1532/ > AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1 > ------------------------------------------------------------------------- > > Key: JBTM-1697 > URL: https://issues.jboss.org/browse/JBTM-1697 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/job/blacktie-linux64-el5/1528/ > {noformat} > 06:38:31,520 INFO [AdvertiseUnadvertiseTest] (default task-2) Got the exception > 06:38:31,872 ERROR [org.jboss.remoting.remote.connection] (Remoting "beacon:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 > 06:38:32,400 INFO [org.hornetq.ra] (default-threads - 1) HQ151001: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2c717166 destination=queue/BTR_BTStompAdmin destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > 06:38:36,876 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (default task-2) Could not deploy queue of .testsui1: java.io.IOException: java.net.ConnectException: > JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out > {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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1693) TXFramework Tests: Arquillian DeploymentException: Cannot deploy: test.war

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1693?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1693: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/295 > TXFramework Tests: Arquillian DeploymentException: Cannot deploy: test.war > -------------------------------------------------------------------------- > > Key: JBTM-1693 > URL: https://issues.jboss.org/browse/JBTM-1693 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, TXFramework > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.0.M3 > > > See: > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/48/TESTS=XTS,jdk=... > Looks like a general issue with our usage of Arquillian. It seems to be happening consistently, so should be easy to reproduce. It's just started happening and I don't think we have made any changes that could of caused it, therefore I suspect it's due to some change in WildFly. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1644) Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1644?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1644: ----------------------------------- Attachment: use-postgresql.patch I tested using a modified version of the jta crash rec quickstart (http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/jta-crash-rec/) running on an instance of the wildfly application server. The modification is to use postgresql as the database and to halt the VM after committing the JMS resource but just before committing the database resource. To facilitate recovery from another node you must use network accessible addresses for the database, i.e. configure postgresql to listen on the same IP address as the ServerName in the datasource configuration (i.e. localhost is no good). This restriction does not apply to the application server which can be started on localhost. Then I moved the file based object store to another host and started another application server with the same version and config. Identical configs probably isn't necessary as long as the transaction and datasources subsystems are configured in the same way, in particular any JNDI datasources needing recovery must be present. If application deployments define their own datasources (which is the case with the jta crash rec example) then these applications must also be deployed on the new server. The transaction config includes a node id which must be the same as the failed host. It is imperative that only one server is running with this node id (i.e. do not restart the failed node with the same id whenever you plan to recover on a different host). This restriction guarantees that different recovery systems do not recover the same transactions. We also mandate that we have one recovery system per object store. In the future we may relax this restriction to allow different nodes to share stores. Note that you can avoid copying the file based object store if you use a JDBC object store running, for simplicity, on the same postgresql database. To do this you would need to configure a non XA datasource (by updating the transactions subsystem properties use-jdbc-store and jdbc-store-datasource with this datasource JNDI name or just add the config directly to the transactions subsystem definition in standalone-full.xml, eg <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectStoreDS"/> If you plan to restart the old node using the same store we recommend that you use different table names. Now recovery will eventually commit the database update which you can verify by polling the quickstart db table: {noformat} -bash-4.2$ psql -h a.b.c.d -U sa jta-quickstart-database psql (9.1.6) Type "help" for help. jta-quickstart-database=> select (name,value) from kvpair; ... {noformat} The attached patch contains the modification to commit the JMS datasource before the database and includes the datasource definition for using postgresql (jta-crash-rec-quickstart-ds.xml - you will need to change ServerName from a.b.c.d to an IP address that is accessible from both hosts in your test configuration). > Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?) > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-1644 > URL: https://issues.jboss.org/browse/JBTM-1644 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, Documentation > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.0.0.M3 > > Attachments: use-postgresql.patch > > > Please can you document any restrictions (stating none if there are none). How to configure the recovery manager (e.g. specific node id, not *). Considerations a user should have (not to connect more than one recovery manager to the same store at once, suggestions for how to restrict that - maybe object store specific?) > Object store specific information, e.g. if you are using filesystem/hornetq/jdbc do any of them ensure that only one process is accessing at the same time? > A simple quickstart demonstrating how to use (maybe JDBC object store inside AS7 would be most appropriate) would be useful. > Does IP address play a role, are there any other restrictions? -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2013