activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Budworth" <>
Subject Opinion about approach for using local/distributed message dispatch
Date Thu, 07 Jun 2007 23:12:19 GMT
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

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,

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message