Jonathan Halliday closed JBTM-389.
In line with discussion in the referenced forum thread, pipes are not required as channel
based communication can simply be eliminated entirely.
Added config property to allow optional disabling of the TransactionStatusManager
listener. Updated recovery to bypass any attempt to use TransactionStatusManager for local
(same process id) transactions and go straight to the ActionStatusService, which it
previously did only as a fallback.
Added config property to allow optional disabling of the socket listener for recovery
manager. This has a side effect of making it easier to inadvertently start multiple
recovery managers for the same objectstore, but is otherwise not a big problem as actual
use of the listener is limited.
Updated failure recovery guide to document new config properties, appropriate use cases
SocketProcessId issues handled separately, see JBTM-406, JBTM-407.
property substitution fix also present in the provided patch is likewise handled
separately, see JBTM-369.
TransactionStatusManager and Recovery integration without Sockets
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Application Server Integration, Configuration, Recovery, Transaction
Affects Versions: 4.2.3
Environment: JBoss 4.2.3
Reporter: Dmitri Voronov
Assignee: Jonathan Halliday
Fix For: 4.5
In the current JBoss integration the communication within Arjuna occurs over Sockets
whereby the communication is within the same JVM and doesn't need to use any socket or
listen on any ports. It requires at least two ports, one for TransactionStatusManager and
one for the recovery. Another one is not configurable and is used as Arjuna's unique
If no ports have been configured, the next free port is opened.
In our environment we manage the port ranges per JBoss instance. This port range contains
the ports for all standard protocols used by JBoss like HTTPS, RMI etc. This port range is
a part of the JBoss instance configuration.
Firstly, we would like to avoid a probability that one JBoss instance can allocate the
ports dedicated to another instance, by opening its sockets on a next free port.
Secondly, the configuration overhead is large, if the ports should be determined. Since
we have up to 100 JBoss instances per stage running it is quite difficult to upgrade their
configuration with new ports.
In my opinion an implementation without involvement of sockets would simplify
Arjuna's configuration, avoid any port conflicts and increase the usability.
My suggestion is to use piped streams (see attachment); it would prevent the changes on
Arjuna's API and the internal algorithms.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira