Arjunas TransactionStatusManager in JBoss

[dimonv]

Hello all,

I read in the Failure Recovery Guide

Currently a tcp connection is used for communication between the RecoveryManager and TransactionStatusManager

Will it be changed in future?
Is it really necessary to use TCP/IP if all participants are running in JBoss?
At the moment we have to define a dedicated port for this.
Moreover this communication is insecure; no TLS configuration is possible.

Thanks and kind regards

[jhalliday]

> Will it be changed in future?

No plans to at present. Feel free to submit a patch.

> Is it really necessary to use TCP/IP if all participants are running in JBoss?

No.

> At the moment we have to define a dedicated port for this.

so?

> Moreover this communication is insecure; no TLS configuration is possible.

use 127.0.0.1, then the traffic will never hit the wire anyhow.

[dimonv]

Thanks a lot for your reply.
Regarding the defining a new port. We have defined and are managing a port range for all the JBoss instances on our environment. This range contains ports for all known protocols e.g. RMI, HTTP, HTTPS, debug and so on.
Since JBoss uses Arjuna as default TM we have to define a new one and make a change to our port management.
As you said it is not necessary to use this port. Could you please write me
why there are no plans to change it?

Thanks in advance.

[jhalliday]

For what purpose are you managing the port range?

There are no plans to change it because it works fine as it is. We have a lot of more important things on the roadmap and only a limited amount of developer time.

[dimonv]

The purpose for the managing the port range is that the every new JBoss instance on our environment gets a dedicated port range.

I would like to set the listen address to localhost, but this configuration is not possible in the version 4.2.3.GA.

[dimonv]

Hello Jonathan,

I opened a feature request in JIRA
https://jira.jboss.org/jira/browse/JBTM-389 with a possible solution.

I would be grateful if you could take a look at this.

Kind regards

[jhalliday]

ok, I'll try to look it over in the next few days.

[jhalliday]

Right, I've had a quick glance through the proposed changes.

I agree that for the use case where the JTA transaction manager is co-located with the recovery manager, using PipedStreams makes sense.

We don't plan of doing any more feature releases for the 4.2.x line and can't easily use this solution there anyhow due to the entanglement of SocketProcessId and the TransactionStatusManager, not to mention the absence of ManagementFactory from the Java 1.4 API.

However, it looks like a relatively straightforward modification for 4.4. I'll try to squeeze it in to the next iteration. Unless I hear from you I'll consider the code you submitted to be LGPL and reuse it as I see fit.

[dimonv]

Yes, of course it is LGPL.
Thanks a lot.

[jhalliday]

> I agree that for the use case where the JTA transaction manager is co-located with the recovery manager, using PipedStreams makes sense.

Actually I'm going to change my mind on this. If the transaction manager and recovery manager are in the same JVM, it's cleaner just to bypass the stream based communication paradigm altogether and make a direct method call.

The TransactionStatusManager is essentially a remoting facility wrapping the ActionStatusService. The recovery manager (actually TransactionStatusConnectionManager) already falls back to using the ActionStatusService directly if it can't get a connection to the TSM. Hence all we need is a small tweak to the recovery code to allow it to detect 'local' transactions and cleanly skip over the attempt to use the remote TSM. With that and a config property to allow the TSM to be disabled it should be possible to run without using a socket or pipe.

[dimonv]

Hello Jonathan,

could you please provide the change on the recovery code to be made to avoid usage of the remote TSM as well as the required config property?

By the way, what about com.arjuna.ats.internal.arjuna.utils.SocketProcessId; it uses a server socket too. My suggetion was the JVMProcessId class.

Thanks a lot

[jhalliday]

The recovery changes are in progress, they should go into trunk today or tomorrow, watch JBTM-389.

The process id stuff is covered by JBTM-406 and JBTM-407, it's basically done already.