Listen address of JBossTS ports not configurable

[huuskart]

See JBTM-253.

JBossTS opens a bunch of network ports (three, I think, but debug output only mentions two) it listens on, but JBossTS does not give me the option to specify at which address it listens for connections.

As such, this is not a bug or error. However, standard practice in practically every single network listening software is to give the option for the administrator to specify at which address the software listens on. JBoss AS also gives this option, it even has a global system property jboss.bind.address, and every single service except JBossTS can be separately configured to listen on a particular address, and by default the services usually are configured to listen on ${jboss.bind.address}.

I want to see JBossTS also support this.

My ultimate reason for this is simply the fact that I hate to have services listening globally on ports they have no business or need listening on. Of course my servers are firewalled, so there's no problem of getting rogue connections, but even so, if I'm running a simple single JBoss AS instance, nothing will ever need to connect to JBossTS services from outside of the localhost, then I want to configure JBossTS so that it listens only on localhost.

But really, for complex installations there may be even real reasons why this needs to be configured. The server could have multiple IP addresses, run several JBoss instances, and would need to configure JBossTS in each instance to listen on different IP.

From another point of view, I could ask that if JBossTS does not need to support this configuration option, why would any service in JBoss support it, and why does JBossTS support configuring even the port at all, if listen address configuration need not be supported (these two really always go hand in hand).

[marklittle]

"huuskart" wrote:
See JBTM-253.

JBossTS opens a bunch of network ports (three, I think, but debug output only mentions two) it listens on, but JBossTS does not give me the option to specify at which address it listens for connections.

Correct. These are for the per-node recovery manager.

As such, this is not a bug or error. However, standard practice in practically every single network listening software is to give the option for the administrator to specify at which address the software listens on. JBoss AS also gives this option, it even has a global system property jboss.bind.address, and every single service except JBossTS can be separately configured to listen on a particular address, and by default the services usually are configured to listen on ${jboss.bind.address}.

I want to see JBossTS also support this.

My ultimate reason for this is simply the fact that I hate to have services listening globally on ports they have no business or need listening on. Of course my servers are firewalled, so there's no problem of getting rogue connections, but even so, if I'm running a simple single JBoss AS instance, nothing will ever need to connect to JBossTS services from outside of the localhost, then I want to configure JBossTS so that it listens only on localhost.

Presumably you'd want this capability even if you were running JBossTS stand-alone, i.e., outside of JBossAS? If that's the case, any way we attempt to address this should work with the JBossAS approach, but not be dependant on it.

But really, for complex installations there may be even real reasons why this needs to be configured. The server could have multiple IP addresses, run several JBoss instances, and would need to configure JBossTS in each instance to listen on different IP.

Agreed. However, we need to be careful about giving too many configuration options in this area or crash recovery could be impacted to the point of not working.

From another point of view, I could ask that if JBossTS does not need to support this configuration option, why would any service in JBoss support it, and why does JBossTS support configuring even the port at all, if listen address configuration need not be supported (these two really always go hand in hand).

I think we should support this. The reason we don't is because JBossTS pre-dates JBossAS development by many years and also virtual hosting/multiple IP addresses per machine as a typical state of affairs. It may well be that what you're after is still not that widely needed, because yours is the first suggestion around this and TS has been pretty widely deployed. However, that doesn't negate the need for it.

[adrian.brock]

[
Presumably you'd want this capability even if you were running JBossTS stand-alone, i.e., outside of JBossAS? If that's the case, any way we attempt to address this should work with the JBossAS approach, but not be dependant on it.

The JBossAS approach is to inject a bind address:

//@Inject
setBindAddress(String address);

and then the configuration is usually done form a system property

<attribute name="BindAddress">${jboss.bind.address}</attribute>

But IMHO this is a bad way to do it. There should really be a way
to inject a ServerSocketFactory which allows a lot more configuration
of what the properties are and what protocol, e.g. ssl

In fact, my real opinion is that you should do the reverse and provide
an implementation of an interface like the following:

void run(InputStream is, OutputStream os) throws IOException {}

a bit like a servlet container or IIOP and then the host (e.g. JBoss)
decides how those streams are constructed and invokes your interface
to handle it.

[marklittle]

Yes, that's pretty much what I had in mind last night when I was looking at this from a stand-alone perspective.

[dmlloyd]

In fact, my real opinion is that you should do the reverse and provide
an implementation of an interface like the following:

void run(InputStream is, OutputStream os) throws IOException {}

Except this makes it totally impossible to use NIO. Probably better would be to depend on an NIO framework (like Grizzly or MINA perhaps?) which could still conceptually allow you to fiddle with the socket and protocol details within the container, but at the same time support nice NIO things like reducing copying and better (than thread-per-connection/thread-per-request) threading models.

[adrian.brock]

Agreed.

Although I'm yet to be convinced that NIO in java really does have those advantages.
It certainly hasn't been true of the spec/Sun implementation.

The best threading model is one thread per cpu doing NBIO
(minimal context switching and cpu cache misses! :-)
Its great in terms of throughput for asynchronous work.

But the response times are appalling under load for more RPC style uses. :-)

[phufnag]

JBossTS opens a bunch of network ports (three, I think, but debug output only mentions two) it listens on, but JBossTS does not give me the option to specify at which address it listens for connections.

As such, this is not a bug or error. However, standard practice in practically every single network listening software is to give the option for the administrator to specify at which address the software listens on. JBoss AS also gives this option, it even has a global system property jboss.bind.address, and every single service except JBossTS can be separately configured to listen on a particular address, and by default the services usually are configured to listen on ${jboss.bind.address}.

I have to echo this sentiment, as far as configurability. At present, we run WebSphere6 (on the machine base address), and jboss4.0/4.2 on secondary IP's on our systems (with the plan of migrating everything to jboss eventually). While setting up 4.2 for migrating (4.0->4.2) for our apps, I'm also moving away from "IP per jvm" which we were doing for 4.0 (ugly, having to plumb a new IP for every jvm) to "port range per jvm" - every jboss 4.2 instance running on eth0:1, with a port range where 42009 would be AJP/JK, 42099/42098 for jnp/jndi, etc (420xx for that particular jvm - range of 100 ports 00-99 for each jvm, trying to keep the last 2 digits from the 'default' ports, and room for any new features that may creep in with future jboss releases).

The sticking point here is JbossTS/Arjuna, which doesn't allow a unique port to be assigned for a particular instance. I've already had (just today) one new jvm we couldn't start, because TS on another instance "happened" to randomly grab port 44209 (which would be the AJP port for the new instance). Had to bounce another app to get it to use a different port for TS, so I could start the new one. Luckily still in our "QA" environment, because that would be *unacceptable* in a live production environment (to bounce a "live" running prod app, because its "random" port is preventing another from starting).

For now, I've set (linux): net.ipv4.ip_local_port_range="49000 65000"
... to keep the "random" ports out of the way of other applications, however it would be far preferable to be able to specify the ports and keep them within the specified range for the particular jvm.

(side note here, jboss portal had hardcoded 1100/1098/1099 ports in one of the XML files that had to change too - the assumption that every jvm will run on a unique IP with fixed ports based on ${jboss.bind.address} is really a bad one, yet seems to be a 'presumption' in most of the jboss packages - while an easy fix (one XML - where I replaced them with -D cmd line variables so we can map for each instance), the idea of being able to control port mappings at the least for *every* service can be very important, especially from a security/firewalling perspective.

[marklittle]

This is an old discussion. There are JIRAs covering this. Monitor those for progress.

[tobias]

In different JIRAs I have seen there are some changes made for 4.2.3+ versions. But still 4.2.3 GA opens up three server sockets which bind to all (!) interfaces.

From an administrators point of view specifying "-b 1.2.3.4" should result in all services being bound only to that interface. Since 4.2 if "-b" is not specified the default interface to use is 127.0.0.1.