Hi all, I submitted on QPID-1421 a patch that introduces some improvements on Q-Man design. Briefly :
**** PUBLISH / SUBSCRIBE PATTERN **** QMan has an MBean administration interface that allows extermal (JMX clients) to regitester themselves a listeners. Q-Man is sending notification to registered listenrers in the following scenarios : - A schema (class / event) has been requested (Schema request); - A schema (class / event) has been injected (Schema response); - A schema cannot be parsed (probably it is malformed); - An object instance has been created (Instrumentation / Configuration response); - An event instance has been created (Instrumentation / Configuration response); - An object instance has been removed (Instrumentation / Configuration response); - An event instance has been removed (Instrumentation / Configuration response); - A method has been invoked and the corresponding result has been received. So basically, referring to this issue, the added test case are external JMX listeners that are using the above mechanism in order to check the behaviour of the management command messages exchange. For example the ManagementSchemaMessagesTest is doing the following in order to test 's' / 'S' messages exchange : - Starts QMan (Qpid is already started); - Register a notification listener interested in schema events and wait - When a "schema requested" notification (= Schema request has been sent) comes from Q-Man, test stores the FQN of the entity (class or event) on a Set; - When a "schema injected" notification (Schema response has been received and corresponding enrtity definition has been built) comes from Q-Man, test stores the FQN of the entity (class or event) on another Set. - A check is made in order to see that all "requested schema" entries have a corresponding entry on the "injected schema" collection. **** QMAN JMX DOMAIN MODEL *** Q-Man domain model has been improved adding two new kind of entities : Class & Event; Previously, only object& event instances were registered on MBeanServer; now there's their definition too. Regards, Andrea 2008/10/31 Carl Trieloff <[EMAIL PROTECTED]> > > I think the key is to make sure you exchange one of each type of management > command > via QMF to the broker. Then we will know if any breaks at the protocol > level. > > Then we can expand it to cover more operations, but that is not critical as > it is all generic code. so > working out to test each type of generic code is the way to go and get all > the types of methods > covered. That will catch 90+ % of all errors, with no repetition. so > picking a function that has > params and a response is better as it covers more code paths. > > The flow though is fine. > > Carl. > > > > Andrea Gazzarini wrote: > >> Hi Carl, and what do you think about the following scenario? >> Precondition: There's a JUnit test for testing the invocation of >> queue.purge() method. >> >> - Qpid starts; >> - QMan starts; >> - Test case starts : using standard JMX interface it registers itself as a >> notification listener of QMan and wait... >> - Qpid sends a content information message (to QMan) about a queue >> instance; >> - QMan store that data in raw format (he has not yet the queue class >> definition) and requests to Qpid schema for class queue; >> - Qpid sends a schema response message; >> - Qman builds the class definition, uses the previous incoming data to >> create the queue object instance and emit a JMX notification to inform >> regoistered listeners about that. >> - Test case receives the notification and get (via QMan JMX interface) the >> current number of messages on that queue; >> - Test case invokes on QMan the purge() method of the queue instance and >> wait; >> - QMan send a method request message to Qpid; >> - Qpid invokes the method and sends a method response message; >> - QMan receives the method response message and emit another JMX >> notification to inform registered listeners. >> - QMan receives the content information message containing data updates >> for >> queue, updates the object and emit another JMX Notification >> - Test receives notification and check the result; >> >> The JUnit Test could be decorated too with JUnitPerf to run a timed test >> in >> order to ensure that all what described above is performed under a certain >> amount of time... >> >> Of course It's still not a complete idea but I think that there's >> something >> of interesting on that... >> >> The interesting thing is that you could have differnet listeners than >> JUnit >> Test used for listening QMan events. >> So for example you could create a separate module that is registering as a >> QMan listener and, using something like JBoss Rules, could define >> configurable rules for detecting threshold conditions, alerts for QMF >> events >> and therefore determining an output channel (SMNP Traps, Email, SMS, I >> don't >> know....) >> >> Regards, >> Andrea >> >> 2008/10/31 Andrea Gazzarini <[EMAIL PROTECTED]> >> >> >> >>> Yes Carl,I agree...what do you think about that? >>> http://clarkware.com/software/JUnitPerf.html >>> >>> I used it in my previous project and that was great! >>> Regards, >>> Andrea >>> >>> 2008/10/30 Carl Trieloff <[EMAIL PROTECTED]> >>> >>> Andrea Gazzarini wrote: >>> >>> >>>> Hi all, >>>>> Actual bundle of QMan has only "offline" unit test that are running >>>>> tests >>>>> again isolated "components" of QMan. That means that in order to see >>>>> those >>>>> tests running you don't need to have QMan and / or Qpid running. This >>>>> is >>>>> good for development stage, allowing a (moreless) test-driven >>>>> development >>>>> and therefore a flexible code but in order to see that all is working >>>>> (Test >>>>> --> QMan --> Qpid) we need to add tests against a runnning QMan >>>>> connected >>>>> to >>>>> a broker. I'm thinking about that...I already coded some tests but it's >>>>> an >>>>> hard work because the asynchronous nature of the interaction between >>>>> QMan >>>>> & >>>>> Qpid. Probably QMan will be extended to support JMX notifications. I'm >>>>> thinkng about that so I'm not sure but from a test perspective should >>>>> be >>>>> cool if you could register a test as a listener of QMan notifications >>>>> and >>>>> in >>>>> that way you will be informed about object creations, events, method >>>>> invocations and all what you need to run your verifications. If you >>>>> some >>>>> kind of idea feel free to suggest... Regards, Andrea >>>>> >>>>> >>>>> >>>>> >>>>> >>>> yes, the question is how to prove all the function interop in a clean >>>> and >>>> automated way. >>>> >>>> I expect you will need a time based test, you know an update will be >>>> reported back with-in >>>> the interval configured on the broker. You can set that to 1 sec in the >>>> script, and have the >>>> test wait say 5sec max before reporting it as failed. >>>> >>>> Carl. >>>> >>>> >>>> >>> >>> >> >> >> > >
