[jaikiran]

jhalliday wrote:

You can extend SBM to support that if you like, but the end result won't be much different from using a fixed port (the bottom of the range) in SMB and a retry counter (the number of ports up from there to try in turn) in the transaction beans file, which is already possible with 0 dev effort. In my view it's not worth the dev effort to move it into SBM unless other things need it to. 

I personally (more as a developer) don't mind updating the transaction beans file to configure this. But as an end user/admin, i think this  might add to the confusion, since he has to go update a different file instead of a single central SBM file. 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). I think, this makes it even more necessary that we don't ask the end user/admin to update that file. By the way, i couldn't find a max retries property in that file, is it renamed to something else? I was able to locate it in the jbossts-service.xml for earlier versions of AS.

Having said that, i don't know how much of an effort it is to somehow glue the max retry counter through the SBM. So i really can't say which is the easier approach (from a dev perspective).

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

[jhalliday]

> 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.

[jhalliday]

> 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.

[brian.stansberry]

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.

[brian.stansberry]

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.

[brian.stansberry]

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

[jhalliday]

> 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.

[brian.stansberry]

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.