Opinion about approach for using local/distributed message dispatch

[David Budworth <db...@gmail.com>]

I have a mechanism I've written that uses dynamic proxies to intercept hits
to JMX mbeans that checks to see if a local instance is up and initialized,
if not, it will send a JMS message to a centralized broker to see if another
server has the service available to service the request.

Basically it's a mechanism to allow unordered startup of services that
allows servicing requests while the system is starting up.  (think jini
services without the classloader magic/hassle)

All this is non-persisted with short timeouts (2 seconds usually), so
reliability isn't really an issues.

I was thinking, would a network of brokers allow me to do this without all
the hassle of having to query the jmx server for state solve the same
problem?

Idea is:
each server starts it's own local broker (that participates in a network of
brokers).  This is done as the first thing on startup
each service connects to the local JMS broker using the vm:// transport.

If a message is sent to queue:serviceA on that local broker, and there is no
listener for queue:serviceA, it would send that off to the partner brokers,
yes?

so, while Server1 is coming up, the early starting services will be getting
responses from other (already fully up) servers, and once Server1 is done
loading it's services, all the calls it makes (via the vm:// transport) will
be local and not incur the network hit?

vm:// transports serialize the objects attached to an ObjectMessage if the
receiver is local?

Basically looking something that doesn't add a ton of overhead to a JMX
call.  Since the receiver end would be listeneing to the queue and just
doing an
mbeanServer.invokeMethod(OBJNAME,"method",Object[]{args}) style hit

hoping that the requests that are serviced locally do not incur the
marshaling overhead.

Ideas?

Re: Opinion about approach for using local/distributed message dispatch

[James Strachan <ja...@gmail.com>]

On 6/8/07, David Budworth <db...@gmail.com> wrote:
> I have a mechanism I've written that uses dynamic proxies to intercept hits
> to JMX mbeans that checks to see if a local instance is up and initialized,
> if not, it will send a JMS message to a centralized broker to see if another
> server has the service available to service the request.
>
> Basically it's a mechanism to allow unordered startup of services that
> allows servicing requests while the system is starting up.  (think jini
> services without the classloader magic/hassle)
>
> All this is non-persisted with short timeouts (2 seconds usually), so
> reliability isn't really an issues.

Interesting! :). I've been having some conversations with various
folks lately for the need for an Apache licensed 'locator & failover'
library that folks could use to turn their POJOs into distributed
services and have the location transparency, auto-location & failover
type stuff. Something that could work over any kind of transport or
binding (WS or JMS or whatnot)

Also in a similar vein is being able to partition services into
slices, then assign master/slaves to a group of service instances etc.

I was thinking it might be worth spinning up a little library for this
kinda stuff. If we used Camel we'd  be transport agnositc; though JMS
is fine too :). We wrote ActiveCluster a while ago which kinda did a
form of distributed discovery so each node could see the available
nodes; it could use some work & be spring-cleaned so to speak :)


> I was thinking, would a network of brokers allow me to do this without all
> the hassle of having to query the jmx server for state solve the same
> problem?

As it happens, there's a JMX-over-JMS too so you can view an
MBeanServer as if its local but the MBeans could be distributed. (With
goodness like using a topic to control multiple MBeans as a single
logical MBean etc).

http://lingo.codehaus.org/JMX+over+JMS

> Idea is:
> each server starts it's own local broker (that participates in a network of
> brokers).  This is done as the first thing on startup
> each service connects to the local JMS broker using the vm:// transport.
>
> If a message is sent to queue:serviceA on that local broker, and there is no
> listener for queue:serviceA, it would send that off to the partner brokers,
> yes?
>
> so, while Server1 is coming up, the early starting services will be getting
> responses from other (already fully up) servers, and once Server1 is done
> loading it's services, all the calls it makes (via the vm:// transport) will
> be local and not incur the network hit?
>
> vm:// transports serialize the objects attached to an ObjectMessage if the
> receiver is local?

Yes, to be JMS compliant you have to; though local serialization can
be disabled if you like (which is faster, but sometimes can result in
class loader issues).


> Basically looking something that doesn't add a ton of overhead to a JMX
> call.  Since the receiver end would be listeneing to the queue and just
> doing an
> mbeanServer.invokeMethod(OBJNAME,"method",Object[]{args}) style hit
>
> hoping that the requests that are serviced locally do not incur the
> marshaling overhead.
>
> Ideas?

That all sounds great. I think there's room for merging these various
things (a general purpose Locator/Discovery mechanism which can use
various mechanisms (multicast, rendezvous/bonjour, http, LDAP,
database or JMS), then there's a kinda distributed JMX bus (which a
general purpose JMX over JMS might do the trick) along with for
advanced users a general purpose failover/partitioning service.

-- 
James
-------
http://macstrac.blogspot.com/