activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tpounds <>
Subject Proposed Additional BrokerViewMBean Methods
Date Mon, 01 Oct 2007 01:02:07 GMT

I think the following operations would be very useful if they were added the
the BrokerViewMBean:

void add/removeConnector(URI bindAddress) throws Exception;
void add/removeNetworkConnector(URI discoveryAddress) throws Exception;
void add/removeProxyConnector(URI bindAddress) throws Exception;

Basically all this entails is updating the BrokerView class to forward these
methods from the already registered BrokerSerive object avaible in the
class.  The only impeding feature from forwarding the methods from
BrokerService directly is the
TransportConnector/NetworkConnector/ProxyConenctor objects that are returned
from the methods in the BrokerService impl do not implement the Serializable
interface. This can be supported by two options: 1) either implementing the
Serializable interface on the returned objects or 2) by changing the
BrokerViewMBean method to throw an exception on a non-successful
registration of the network connector URI.  If we go with the option 1 then
we could potentially publish all of the add*Connector methods provided by
the BrokerService class.  Option 2 requires the least amount of code changes
and could be implemented fairly quickly. I'm currently in the process of
developing some patches to support option 2...but I wanted to get an idea
what the core developers think about the proposed feature.  I can create a
jira improvement ticket for the task and assign it to myself if everyone
thinks this would be beneficial to the community.

I know this feature will be very useful in environments that have statically
configured connectors where auto discovery is not provided or possible (i.e.
internet). A dynamically changing business environment that has remote
management tools for auto-registering of client brokers could benefit in the
above case when all that is known at deployment time is that local JMS
clients connect to a local broker that needs to publish queue/topic upstream
to unknown.  This is also particularly useful for components based on
ActiveMQ such as ServiceMix where servicemix client need to connect to other
ServiceMix/ActiveMQ brokers/clusters upstream.
View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message