JBossDeveloper

> Furthermore, i just looked at the transaction-jboss-beans.xml and i see that with the new AS MC structure this now resides in the "deploy"folder (earlier the config was in servername/conf folder

The -beans.xml has always been in deploy. The jbossts-properties.xml was in conf but is now obsolete as the new TS allows everything to be configured by beans, rather than just a subset of the features as in the old version.

> By the way, i couldn't find a max retries property in that file, is it renamed to something else

There are around 130 config settings for the TS. To reduce clutter only the important ones or those that need non-default values are specified in the -beans.xml. The rest have sane defaults hardcoded internally.  The old non-bean property names ('com.arjuna.blah..') still work for now, but are deprecated. The -beans.xml files uses the bean property names instead, so what you need is

<bean name="CoreEnvironmentBean" ...

    <property name="socketProcessIdMaxPorts">10</property>

or alternatively

<bean name="CoreEnvironmentBean" ...

  <property name="processImplementation">some.class.implementing.Process</property>

if you prefer to replace the socket based approach entirely.

> Furthermore,i have been comparing the SBM files across AS versions and i see thisexact same configuration (with the same comments) being used across allthese versions. So it used to work with this configuration. I amcurious, as to what exactly in the JBossTS changed now.

The transaction-jboss-beans.xml in previous versions did not pick up the port from SBM, it used a hardcoded value of '0', which means 'pick any free port at random'  We changed that following user complaints that the system would occasionally pick a port that some process later in the boot sequence needed. Which is basically the same reason we don't ship a default of a port range - it's non-deterministic.

OT: Grr, email notifications from this thread appear to not be working.

So is this a solution to our immediate problem:

1) Change the value for this port in the SBM config to '0', essentially restoring the old behavior? Or does JBossTS no longer know how to deal with ephemeral port configs?

2) Raise a blocker JIRA for M2 or M3 to come up with a better solution.

I obviously don't want to revert this change. It's a PITA and wastes everyone's time. But leaving 1/2 the testsuite broken is not an option.

Ignore the SBM port '0' suggestion, although I'd like to know the answer as to whether it would work. Sounds like the suggestion of

<bean name="CoreEnvironmentBean" ...

    <property name="socketProcessIdMaxPorts">10</property>

accomplishes the same purpose when combined with the blocker JIRA to come up with a better solution.

The socketProcessIdMaxPorts workaround is checked in: https://jira.jboss.org/jira/browse/JBAS-7554

The JIRA replacing with something cleaner is https://jira.jboss.org/jira/browse/JBAS-7555

> Ignore the SBM port '0' suggestion, although I'd like to know the answer as to whether it would work.

Putting a value of 0 in the SMB file does not work, because it gets incremented +100 or such for other port sets. 0 means 'random port' but '100' means '100', but SMB did not grok this last time I checked.   Putting '0' in the transaction-jboss-beans.xml however does work and is equivalent to the setup in 5.x/6.M1. Using a port range instead is better in that it limits the randomness, but not particularly user friendly as it splits the config over multiple files.

Thanks, good to know. FYI, the following would avoid the "increment by 100" problem:

            <!-- 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">0</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>
               <!-- This port should not be changed between different 
                    binding sets; all nodes need to use an ephemeral port -->
               <property name="fixedPort">true</property>
            </bean>

But if one of the other Process impls from JBTM-407 or something custom will suit, that's better.

BTW, JBoss Messaging (and I presume HornetQ) requires that each node has a stable integer identifier. I think sometimes about solving both use cases with the same solution, but it's not a clean fit. The messaging ServerPeerID has to be stable, so these Process values that change after restart won't work. We could use the user-specified value used for messaging as the value in a JBossTS Manual Process, but that 1) forces the user to specify the value even in a single node deployment, which isn't currently required, and 2) is unsafe, since multiple unrelated JBM instances running on the same machine could be configured with the same value, and JBM wouldn't care.