April 2008 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBTM-37) Modifications for the OASIS WS-TX Standard

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-37?page=all ] Andrew Dinn updated JBTM-37: ---------------------------- Fix Version/s: 4.4.CR1 (was: 4.6) > Modifications for the OASIS WS-TX Standard > ------------------------------------------ > > Key: JBTM-37 > URL: http://jira.jboss.com/jira/browse/JBTM-37 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.4.CR1 > > > Preliminary support for the OASIS WS-TX standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-37) Modifications for the OASIS WS-TX Standard

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-37?page=all ] Andrew Dinn closed JBTM-37. --------------------------- Resolution: Done > Modifications for the OASIS WS-TX Standard > ------------------------------------------ > > Key: JBTM-37 > URL: http://jira.jboss.com/jira/browse/JBTM-37 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.6 > > > Preliminary support for the OASIS WS-TX standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
0
0 / 0

[JBoss JIRA] Reopened: (JBTM-37) Modifications for the OASIS WS-TX Standard

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-37?page=all ] Andrew Dinn reopened JBTM-37: ----------------------------- reopening to correct fix version > Modifications for the OASIS WS-TX Standard > ------------------------------------------ > > Key: JBTM-37 > URL: http://jira.jboss.com/jira/browse/JBTM-37 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.6 > > > Preliminary support for the OASIS WS-TX standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
0
0 / 0

[JBoss JIRA] Commented: (JBTM-37) Modifications for the OASIS WS-TX Standard

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-37?page=comments#action_12408552 ] Andrew Dinn commented on JBTM-37: --------------------------------- As of r19546 support for the WS 1.1 protocols is implemented in XTS using JBossWS 3.0.1 Native running on JBossAS 5.0.0Beta4. The JBoss XTS sar can be built to include either the 1.0 implementation, the 1.1 implementation or both. The XTS demo is implemented in two versions. One version uses JaxRPC to invoke the web services and employs the 1.0 WS API classes and implementation. The other uses JaxWS to invoke the web services and employs the 1.1 WS API classes and implementation. Documentation still needs to be updated. > Modifications for the OASIS WS-TX Standard > ------------------------------------------ > > Key: JBTM-37 > URL: http://jira.jboss.com/jira/browse/JBTM-37 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Fix For: 4.6 > > > Preliminary support for the OASIS WS-TX standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-350) tx.registerSynchronization does not throw RollbackException as per JTA 1.1 page 36

by Carlo de Wolf (JIRA)

tx.registerSynchronization does not throw RollbackException as per JTA 1.1 page 36 ---------------------------------------------------------------------------------- Key: JBTM-350 URL: http://jira.jboss.com/jira/browse/JBTM-350 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Priority: Critical 18:39:56,203 WARN [SessionSynchronizationInterceptor] Unexpected IllegalStateException for tx TransactionImple < ac, BasicAction: 7f000101:e23d:47e2a121:6f status: ActionStatus.ABORT_ONLY > with status 1 After tm.setRollbackOnly the transaction is in STATUS_MARKED_ROLLBACK, but tx.registerSynchronization throws an IllegalStateException instead of RollbackException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-348) decouple TransactionStatusManager from SocketProcessId

by Jonathan Halliday (JIRA)

decouple TransactionStatusManager from SocketProcessId ------------------------------------------------------ Key: JBTM-348 URL: http://jira.jboss.com/jira/browse/JBTM-348 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.GA Reporter: Jonathan Halliday Assigned To: Michael Musgrove Fix For: 4.4.CR1 The TransactionStatusManager resuses the ServerSocket opened by SocketProcessId, in an effort to reduce the overall number of ports in use by the system. SocketProcessId needs the socket only to guarantee it's uniq, it does not actually move traffic over it. TransactionStatusManager uses it to handle queries regarding the status of in-flight transactions. The problems start when the box has multiple IP addresses. SocketProcessId must bind on a fixed IP (probably 127.0.0.1) common to all JBossTS instances on the machine, in order that the port number remains uniq across all running JVMs. The TransactionStatusManager however must bind on a user specified IP in order that multiple instances may run on the same machine without interference. Thus it is not appropriate for TransactionStatusManager to reuse the SocketProcessId's ServerSocket. Decouple these, such that TransactionStatusManager reads its config properties and opens a ServerSocket directly, whilst SocketProcessId reads a different config property for its port number rather than reusing the TSM's config property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-253) Listen address of JBossTS ports not configurable

by Arto Huusko (JIRA)

Listen address of JBossTS ports not configurable ------------------------------------------------ Key: JBTM-253 URL: http://jira.jboss.com/jira/browse/JBTM-253 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.SP3 Environment: JBoss AS 4.2.0 GA Reporter: Arto Huusko Assigned To: Mark Little JBossTS integrated in JBoss AS 4.2.0 GA always binds some tcp ports to listen on all addresses. jboss.bind.address has no effect on the listen address, nor is it otherwise configurable. Looking at source code (for example ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/TransactionStatusManager.java in jbossts-jta-4.2.3.SP3-src.zip) confirms that there is no kind of support for binding the listen address, only the port can be freely selected. The listen address should be configurable, so that it can be limited to localhost, for example. In addition, if possible, it would be nice to be able to disable listening on any ports. I'm not sure if the TransactionStatusManager really needs to listen on any port in a simple JBoss AS installation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

4
10
0 / 0

[JBoss JIRA] Created: (JBTM-324) Enable Setting Port with com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort

by Thomas Krieger (JIRA)

Enable Setting Port with com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort ------------------------------------------------------------------------------------ Key: JBTM-324 URL: http://jira.jboss.com/jira/browse/JBTM-324 Project: JBoss Transaction Manager Issue Type: Patch Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.2.3.SP5 Reporter: Thomas Krieger If you set <property name="com.arjuna.ats.internal.arjuna.recovery.recoveryPort" value="1213"/> <property name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="1214"/> you get the following Exception: com.arjuna.ats.arjuna.exceptions.FatalError: [com.arjuna.ats.internal.arjuna.utils.SocketProcessId_2] - SocketProcessId.getpid could not get unique port. at com.arjuna.ats.internal.arjuna.utils.SocketProcessId.getpid(SocketProcessId.java:122) at com.arjuna.ats.arjuna.utils.Utility.getpid(Utility.java:206) at com.arjuna.ats.arjuna.common.Uid.<init>(Uid.java:105) at com.arjuna.ats.arjuna.utils.Utility.getProcessUid(Utility.java:218) at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.<init>(TransactionStatusManagerItem.java:323) at com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem.createAndSave(TransactionStatusManagerItem.java:71) at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.start(TransactionStatusManager.java:157) at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.<init>(TransactionStatusManager.java:78) at com.arjuna.ats.arjuna.coordinator.TxControl.<clinit>(TxControl.java:312) at com.arjuna.ats.jbossatx.jta.TransactionManagerService.startService(TransactionManagerService.java:139) The first problem is that in TransactionStatusManager calling ServerSocket socket = SocketProcessId.getSocket(); returns null, so that a new ServerSocket is created in TransactionStatusManager getTsmServerSocket (int port) (line 218) The solution is, to call (new SocketProcessId()).getpid(); in the constructor. The second problem is that RecoveryManagerImple.activeRecoveryManager uses the wrong port (line 197): SocketProcessId uses Property com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort and not com.arjuna.ats.internal.arjuna.recovery.recoveryPort. Solution is to change activeRecoveryManager (). Thomas Krieger for P&I Team Tess (Ralph-Rainer Welzel, Andreas Rugullies ...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-352) Memory leak in TransactionReaper._timeouts

by Ivan Szanto (JIRA)

Memory leak in TransactionReaper._timeouts ------------------------------------------ Key: JBTM-352 URL: http://jira.jboss.com/jira/browse/JBTM-352 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.3.0.GA Environment: Compiled 4.3.0.GA for the EAP 4.3 as JTS according to the instructions (by setting JBOSS_HOME to jboss-5.0.0.Beta4) on RHEL4. Run ~ 1500 JMS transactions in EAP 4.3 all configuration on RHEL4 to see it leaks. Used Sun jdk 1.5.0.14 Reporter: Ivan Szanto The leak can also be seen by using the debugger to check the number of entries in TransactionReaper._timeouts after a couple of transactions. It appears that the TransactionReaper.insert method uses ControlWrapper objects as keys when putting elements into the hashtable, but the TransactionReaper.remove method sometimes unsuccessfully tries to use Uid ojbects to remove them. I will post a corrected version of TransactionReaper.java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

4
16
0 / 0

[JBoss JIRA] Created: (JBTM-349) Unfounded exception is thrown on registerSynchronization in wrong state

by Carlo de Wolf (JIRA)

Unfounded exception is thrown on registerSynchronization in wrong state ----------------------------------------------------------------------- Key: JBTM-349 URL: http://jira.jboss.com/jira/browse/JBTM-349 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Priority: Critical java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.syncsnotallowed] [com.arjuna.ats.internal.jta.transaction.arjunacore.syncsnotallowed] Synchronizations are not allowed! at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:473) The exception message does not say why it's not allowed (tx is in wrong state) and the context in which it is occuring (the actual tx state). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2008