RE: [JBoss-dev] Multiple Instance - continued

[Mike Finn]

OK.

 

I figure it goes like so:

1) Each 'proxied' service (jboss-service, SARs, etc) optionally comes up on a random, unprivileged (> 1024) port. This should be possible by setting the port to 0 in the configs. This would force the IP stack to pick a random port. Of course there would need to be a way to find out the port that was selected, which you can do if you have access to the ServerSocket. An alternative would to use a rolling mechanism (8080 fails, try 8081, 8081 fails, try 8082, etc), or something of that ilk.

2) A proxy-manager service (MBean) starts on a predetermined port. This service provides the listener for all the (proxy-managed) protocols, on one port.

3) Somehow the proxy-managed services (MBean) notify the proxy manager MBean of their port, once they are up. JXTA or JMX notify-s are options here. With JXTA, there may be added benefit (all MBeans could be members of a peer group and share management messages - like "I am going down" - for consumption by the group).

4) All 'clients' connect through the service proxy. He looks at the content on the wire (protocol header) and (pardon the leap of faith) determines the protocol. This is done via PushbackInputStream, which lets you read bytes from the stream, then 'unread' them. The socket is handed off to a separate thread (pooled) that couples the client to the proper service (opens new server socket) and handles the input/output stream reads/writes until the tcp connection terminates. Much like an HTTP proxy.

 

Issues?

1) With the identify-protocol-from-the-wire-content approach, can only support a single instance of each 'service' (http, jndi, etc), within a JVM. No other way (?) to uniquely identify which service 'instance' (like if there are more than one HTTP server - JMX-HTML and Jetty for instance).

2) Need to know the wire protocol content, so we can uniquely identify the stream to map it to a 'service'. Should be easy to reverse engineer with tcpdump or ethereal. Ideally, should be able to get from specs.

3) Not sure how/if this approach is impacted by clustering. Help?

4) Is there any udp based stuff to worry about? I suspect in HA-naming? I have only thought about tcp.

5) How to get the actual port used by a given service? Depends on service (if we have access to the server socket opened).

 

6) (Of course) - is there a simpler/better solution to this that anyone can think of?

 

I do have a tcp port-proxy solution mostly written (couldn't find a 'portable' or non-native open source one), but don't want to spend too much more time on it if you guys think this is not feasible.

 

Regards,

Mike

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
Sent: Tuesday, April 16, 2002 2:38 PM
To: Mike Finn; Jboss-Development-List
Subject: RE: [JBoss-dev] Multiple Instance - continued

we care, revive the thread if you can, better submit configuration that would work with "many instances" on the same machine

 

marcf

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Finn
Sent: Tuesday, April 16, 2002 11:01 AM
To: Jboss-Development-List
Subject: [JBoss-dev] Multiple Instance - continued

You guys probably have more to worry about right now, with RC1 and all, but:

 

A while back there was a thread regarding the whole 'multiple instance detection' thing - where the problem of managing multiple listeners vying for the same port was discussed (JNDI, RMI, etc).

 

Was there any resolution or direction? This is of interest to me as we do often have multiple JBosses running on a single box (to make it more challenging - we share a box with another group that has pure RMI apps running on it..).

 

One of the options was a 'port manager' that would (if I understand) forward traffic (like a proxy) to the correct port for the requested service.

1) To do this, I imagine the 'port mgr' would have to be able to sniff the incoming bytestream and determine the requested service by interrogating the content. This imposes the restriction that only one instance of a service (service being wire protocol - JNDI, HTTP, RMI, etc) can be routed, since there probably would be no unambiguous way to differentiate between two HTTP streams (for instance).

2) The port mgr (MBean?) would somehow need to be aware of the 'real' ports being used within the JBoss process space by the managed services. Would the MBean Notification mechanism suffice? Where each MBean that owns a "managed" port would send a notification with the port/s onwhich it it is listening. Or, as (I think) Marc suggested, a P2P solution like JXTA (which may be a better solution than JMX Notifications?). Or a config file (less than optimal, IMO).

 

Thoughts?

 

I would definitely be interested in contributing on this. Or maybe no one cares about this one anymore.  :-)

 

Mike