activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Opinion about approach for using local/distributed message dispatch
Date Fri, 08 Jun 2007 12:26:22 GMT
On 6/8/07, David Budworth <> 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).

> 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.


View raw message