Hi, I think that the first step toward providing a good set of management features is to make a list of what we have (Gordon has already initiated that). That would be the starting point for defining the set of features that we want. I believe that we should definitely planify now rather than in few months hence risking to realize that people time has been wasted.
I would suggest that Andrea starts and drives the discussion. Andrea would you make a list of existing feature with the definition that we currently have? We would then need to make sure that the defs are unambiguous (that is going to be fun). On suggestion would be to list the qpid entities (queue, exchange, etc.) a feature is related to. This would help us adding the necessary hooks to the java broker. Once we have all agreed of a final well defined set of management features we would then implement the bridge. I realize that this is a hard task that may not be as fun as coding. However, I believe that this is a necessary step toward achieving a good product. Andrea would you be ready to drive the process? Thanks Arnaud On Tue, 2008-04-22 at 09:08 +0100, Marnie McCormack wrote: > 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 > >
