qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Some questions...
Date Tue, 22 Apr 2008 10:25:00 GMT
Andrea Gazzarini wrote:
> Now, my question is : what level of granuarity should be used in the JMX Bridge? 
> Do you think it's better to use an interface like this: 
> 
> int getMessageCurrentCount(); 
> int getMessagePendingCount(); 
> int getActiveConsumbers(); 
> int getTotalConsumers(); 
> ... 
> 
> or using data transfer object like the following: 
> 
> Queue getQueue(...); 
> 
> where Queue is a DTO and is implementing the interface described above. 
> 
> Let me know... 

I initially imagined the JMX bridge to be a JMX 'connector' that (a) 
exposed the AMQP-based approach to management that the c++ broker uses 
to JMX clients and (b) allowed a JMX managed entity (such as the java 
broker) to be manipulated using that same AMQP-based approach.

I.e. the bridge would be very generic and usable for interop between the 
AMQP-based management scheme and JMX regardless of the object model 
exposed by the managed entity. (The rationalisation/standardisation of 
the object models exposed by c++ and java brokers would then be a 
separate step).

However, this was just a very vague and very high-level picture in my 
mind. Is this actually feasible? If so the bridge itself would not care 
about the granularity of the object model to be used. If not, what are 
the issues that prevent it?

Mime
View raw message