Hi Andrea, There are existing JMX interfaces exposed in the Java broker which we'll need to maintain for existing users. I'll try to find some more information about the existing features we provide, which are in use.
I also think its worth discussing on the list the way in which this information is created. Currently, for example, some of the queue related information is triggered (updated) by queue activity which is not ideal but the alternatives can be quite costly in terms of performance on the JMX call. Rob Godfrey should be able to shed more light here since he has worked on this area. I'll have a look around and come back to you shortly too ! Thanks & Regards, Marnie On 4/22/08, Andrea Gazzarini <[EMAIL PROTECTED]> wrote: > > Hi Arnaud, just a mail to ask you some questions (if you are not busy). > > ******** BRIDGE GRANULARITY ************ > I read that, according to QPID management features, capabilities are > divided in four categories: > > 1) Exchange > 2) Connection > 3) Broker > 4) Queue > > For example, for the "Queue" category, the management interface will be > able to get information about: > > 1. General Queue properties(like name, durable, etc.) > 2. The maximum size of a message that can be accepted from the message > producer. > 3. The number of the active consumers accessing the Queue. > 4. The total number of consumers (Active and Suspended). > 5. The number of undelivered messages in the Queue. > 6. The total number of messages received on the Queue since startup. > 7. The maximum number of bytes for the Queue that can be stored on the > Server. > 8. The maximum number of messages for the Queue that can be stored on the > Server. > > 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... > > *********** MOCK OBJECTS ************** > Is it possible to use something like mock objects, easymock, or somewhat > else? > I used to use that for developing things using a TDD approach... > > ************ BRIDGE PROJECT ************** > I created a project my workspace (it's a local project) following moreless > the structure of the other preexistsing projects. > Could you be so kindly to let me know what do you think about the > structure of the packages in the test directory? Ok, It's possible that, > while developing, other packages will be added... > > Regards, Andrea >
