As it happens I've just been corresponding with Brian on the same topic, as this affects the clustering tests too.

"The port for socketProcessId is configured via  ServiceBindingManager. As long as the two servers you start  use different port configs it's not a problem. As far as I  can tell, that's not done with the clustering tests for some  reason. That means it will need manual configuration to  override the socket setting e.g. munge the  transaction-jboss-beans.xml to hardcode a port rather than  using the SBM. Or use a different Process Id impl, but that  will likewise require munging the xml so it's no better really."

Jonathan.

I'll again reiterate that SocketProcessId should not communicate with SBM, because it's the actual binding is an implementation detail around a hack. It's not a true service.

TransactionManager and AS' ServiceBindingManager

> Looks like this approach will no longer work?

Correct - the default JBossTS config no longer supports that. If the AS community feels they want that functionality out of hte box, either keep the socketProcessId but change the default config so it can hunt for randon free ports (which will incur the wrath of sysadmins who like fixed port sets) or swap the socketProcessId for some other Process id implementation.

Now where is that rolling eyes smiley.

<!-- JBossTS SocketProcessId.  The address part is ignored, it will always use localhost/127.0.0.1. -->
<bean class="org.jboss.services.binding.ServiceBindingMetadata">
   <property name="serviceName">TransactionManager</property>
   <property name="bindingName">socketProcessId</property>
   <property name="port">4714</property>
   <property name="description">Socket used to provide unique
process id for JBossTS. The address configuration is ignored; will
always use localhost/127.0.0.1</property>
</bean>

> I'll again reiterate that SocketProcessId should not communicate with SBM

And I'll reiterate again: that's nonsense. The SMB exists specifically for cases like this. It's there to allow different servers to define different port sets so they don't interfere with each other, which is exactly what's needed here. Ingoring it just forces admins to hack a separate config file for each server instance, which will not make you popular.

> Now where is that rolling eyes smiley.

SocketProcessId exists specifically to guarantee a port number that is uniq to all instances on the host, regardless of how many network interfaces that host has. It's functioning as designed. If you don't like, don't use it - the Process id implementation is pluggable.

The second comment is  not inconsistent. It may, perhaps, be unclear. It says that the host address
needs to be the same on all nodes but does not say anything about the portbeing the same. The point
it is trying to make relates to the use of an algorithm which scans upwards from a specified port
value looking for a free port. If JVMs used different bind addresses then some of them might possibly
bind to the same port number. If they all use the same bind address then no two JVMs can bind to the
same port. This is misleading because the configuration mechanism for the clustering requires assigning
specific ports via the SMB i.e. the docs talk about implementation details not visible to the user.
Add it to the list of TX doc defects (not to mention the AS ones).

Binding multiple AS instances to different IPs isn't just a simple convenience for unsophisticated users.

The recommendation for how to run multiple AS instances on a single  server has never been to configure separate port sets; that's always  been Plan B. The recommendation has always been to multihome the machine  and bind the different instances to different IP addresses.[1]

The multi-server tests in the testsuite all run with our recommended  configuration (except for those specifically testing using separate port  sets).

Requiring use of separate port sets or munging of configuration is a massive regression. We have a policy that commits that cause significant testsuite regressions are reverted. That is going to happen with this change if we don't come up with a solution by the end of the day

[1] http://community.jboss.org/docs/DOC-9384