-
1. Re: bind options
You need to find your bisocket configure file and change the configuration entry:
<attribute name="serverBindAddress">${jboss.bind.address}</attribute>
replace the ${jboss.bind.address} with your host name.
Or you can pass this parameter through command line when starting your jboss server, like
./run.sh -c <config> -b <hostname>
-
-
3. Re: bind options
I'am already binding to hostname and changeing the config prevents my server from deploying the application correctly. What I'm actually after is how it works out that it cant use the hostname and decideds to use the ipaddress and random port.
-
4. Re: bind options
The serverBindPort is used for a client to connect to server, for a server replying to the client using a fixed port, you need
<attribute name="secondaryBindPort">xyz</attribute>
<attribute name="secondaryConnectPort">abc</attribute>Not sure if this are what you want.
-
5. Re: bind options
why do I have to alter the config I have 1 server that this works as expected on and another that it does not.
The jboss config is the same on both servers I need to know why Jboss is binding differently, this must be down to the host os config.
-
6. Re: bind options
If both jboss server has same config, it must be your machine/os that causes the error. I usually check etc/hosts (for linux os) to see if they have some entries that need to be removed (or added).
-
-
8. Re: bind options
Yes I know the log is from JMS but I get the same type of error. The RMI is trying to connect via IP address rather than name on this server.
If I get the log I provided displaying hostnames at startup I'm confident the RMI will also work.
-
9. Re: bind options
the JBM src looks up the remoting connector service and logs the info from there. Howard, do you know what version of remoting Pete needs to look at to debug?
-
10. Re: bind options
I'm not sure. Each version of JBM goes with a specific version of JBR. If Pete need to look at the remoting src, he need to check the version of JBM in the logs. Usually if the log level is TRACE, you can find the remoting version also in the logs.
-
11. Re: bind options
Looks like the messageing code is calling
String locatorURI = (String)JMXAccessor.getJMXAttributeOverSecurity(server, connectorObjectName, "InvokerLocator"); I need to find the code that creates the object this line is accessing.
I have checked out the following source JBoss_4_2_3_GA so I should have the class I need to look at.
-
-
13. Re: bind options
No we have JBoss_4_2_3_GA with JBossMessaging_1_4_2_GA I have no idea what version of Jboss Remoting is being used. The source I have checked out does not have InvokerLocator in it.
-
14. Re: bind options
I found that the remoting source being used is 2.2.2-SP8
The problem was being cause by the name of the server redditch_efin_app01. Once the URI hasd been parsed the call to uri.getHost was returning null. I added an entry to the host file for redefinapp01 and restarted the appserver. The new URI was parsed correctly and the call to uri.getHost returned the correct value.
Whilst trying to get to the bottom of this I found that the remoting code does not seem to use the default setting for remoting.bind_by_host
String bindByHost = System.getProperty(BIND_BY_HOST, "True");
byHost = Boolean.getBoolean(bindByHost); //this was false even thought the above string was 'True'
I managed to fix this with a change of config but I did not seem to ba able to force a legacy parse or to bind by host.