[adrian.brock]

"jhalliday" wrote:

As long as it returns a value 0-65535 that's uniq in the scope of the O/S it's running on it should be possible to plug it in without too much hassle.

But that's the problem. Its relatively easy to generate a String that is unique,
generating a number that is unique is a lot harder to do.

Why does it have to be a number between 0x0000 and 0xFFFF?

From the other thread:

The SocketProcessId is basically a kludge to get a uniq number (the port number) for use in Uids, in place of the ability to get the process id, which you can't do from Java.

So why can't we plugin our own UID implementation directly?

[marklittle]

"wolfc" wrote:
How can we plug-in another implementation? It appears to me that the usage of SocketProcessId is hard-coded.

No it's not. As Jonathan mentioned earlier there are a couple of approaches that are implemented. New implementations can be added through the Arjuna Process interface mechanism. It's just that the default is based on a Socket.

[marklittle]

So why can't we plugin our own UID implementation directly?

As Jonathan has pointed out, this isn't such an easy option. Uid is used throughout the transaction service for a number of different reasons. Replacing it with any alternative implementation would be an invasive process and there are simpler alternative solutions to the problem.

[jhalliday]

"wolfc" wrote:
How can we plug-in another implementation? It appears to me that the usage of SocketProcessId is hard-coded.

No it's not. As Jonathan mentioned earlier there are a couple of approaches that are implemented. New implementations can be added through the Arjuna Process interface mechanism. It's just that the default is based on a Socket.

Actually you are both partially right. There is an interface providing for abstraction, but the implementation class to use is hardcoded rather than read from the properties file. You need to programatically override it using com.arjuna.ats.arjuna.utils.Utility.setProcess(...)

[marklittle]

lol

Did you look, or did you notice that I created https://jira.jboss.org/jira/browse/JBTM-406 at the time I posted ;-) ?

[jhalliday]

Email is lagging somewhat, so the JIRA notification has not shown up yet. Glad you mentioned it or I would have wound up creating a duplicate issue.

[wolfc]

All in all this thing should never communicate with SBM in the first place.
It's not some network service which AS provides. It's a hack around a JVM limitation. There are no real configuration options, because the option should actually be called: process id. So running two JBoss AS instances on one machine with the same 'process id' results in an error.

I think transaction-jboss-beans.xml should just be configured with a '0' setting => go figure out your own process id. The fact that this must happen via a localhost socket hack is an implementation detail. (Note that this not invalidate JBTM-406.) If anyone would configure one instance to use another interface it would screw things up badly. If anyone would preconfigure a port and do two micro startups, it would screw up as well. So no configuration is the best way out.

[marklittle]

I think you're right for the time being, though Jonathan and I will talk about this at the f2f we're about to have. I'd been toying with a few ideas as alternatives a while back for this anyway and have finally raised a JIRA https://jira.jboss.org/jira/browse/JBTM-407

So a longer term better solution is coming.

[adrian.brock]

What interface are using to bind to for the SocketProcessID?

If I'm working offline, i.e. no eth0/network and start jboss on localhost
the server doesn't boot.

If however, I change /etc/hosts so that it includes my host name as localhost it will boot
127.0.0.1 hostname localhost

[mmusgrov]

What interface are using to bind to for the SocketProcessID?

It's using InetAddress.getLocalHost() which is wrong - I've raised JBTM-412 to get it fixed.

[brian.stansberry]

"wolfc" wrote:
All in all this thing should never communicate with SBM in the first place.
It's not some network service which AS provides. It's a hack around a JVM limitation.

I'm not convinced. The argument you make that it's not a network service is true enough; using the SBM for this is conceptually a bit unclean.

But if I'm an admin who starts the AS and looks at what sockets it's opened and want to know where to configure the ports, I'd much prefer to be told to go to one location than be told to go to one place except for X which uses a dynamic port. I don't care that it's not a network service.

Generally dynamic ports are used for client sockets or short lived ones. This one is a "nothing socket" :) But the fact it lives as long as the server makes it IMHO a lot closer to a server socket than anything.

[vbs001]

Hi, I would like jboss 5; use the ports file ports-binding.xml to distribute the various instances as I do in jboss 4.2.2.; do it like this:
.. / jboss-5.0.1.GA / bin / ports-binding.xml

. / conf / service-jboss.xml
tag <- <mbean code="org.jboss.services.binding.ServiceBindingManager" name="jboss.system:service=ServiceBindingManager">
   <attribute name="ServerName"> ports-default </ attribute>
   <attribute name="StoreURL"> /jboss-5.0.1.GA/ bin / port-bindings.xml </ attribute>
   <attribute name="StoreFactoryClassName"> org.jboss.services.binding.XMLServicesStoreFactory </ attribute>
   </ mbean>

ports are passed by the generic file /jboss/server/defautl/generic-port, for example generic-port

port.prefix=8

/bin/ksh -x /jboss-5.0.1.GA/bin/run.sh -c default -b 0.0.0.0 -P /jboss-5.0.1.GA/server/default/generic-port

Error displayed after setting:

12:50:32,249 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss-5.0.1.GA/server/default/conf/jboss-service.xml state=PreReal mode=Manual requiredState=Real

org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.system:service=ServiceBindingManager

        at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

        at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)

        at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)

        at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)

        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)

        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)

        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)

        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)

        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)

        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)

        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)

        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)

        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)

        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)

        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)

        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)

        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)

        at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)

        at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:698)

        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:274)

        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)

        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)

        at org.jboss.Main.boot(Main.java:209)

        at org.jboss.Main$1.run(Main.java:547)

        at java.lang.Thread.run(Thread.java:595)

Caused by: java.lang.IllegalStateException: jboss.system:service=ServiceBindingManager is already installed.

        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)

        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)

        at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)

        at org.jboss.system.ServiceController.install(ServiceController.java:273)

        at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)

        ... 23 more

12:50:32,682 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:

  Deployment "vfsfile:/opt/jboss-5.0.1.GA/server/default/conf/jboss-service.xml" is in error due to the following reason(s): java.lang.IllegalStateException: jboss.system:service=ServiceBindingManager is already installed.

12:50:32,686 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.1.GA (build: SVNTag=JBoss_5_0_1_GA date=200902231221)] Started in 33s:243ms

^C12:50:51,718 INFO  [ServerImpl] Runtime shutdown hook called, forceHalt: true

12:50:54,817 INFO  [ServerImpl] Shutdown complete

Shutdown complete

[mmusgrov]

Intructions for changing the default port bindings are on the wiki: http://community.jboss.org/wiki/ConfigurePorts