I see your point, shifting as much stuff into the coordinator as possible. I had a suspicion I was making the test case interaction between the test clients too complex.
I will change it so that the coordinator waits for report messages from both senders and receivers in order to determine whether the test has completed. Coordinator to compare sender and receiver reports to decide if test has passed or not. "Complete Role" and "Test Done" messages are not needed because the clients will know that their role is complete when they send their reports. This is much closer to your original proposal. I will also add a reply queue to the coordinator, so that responses to its broadcast messages are returned only to it. Thanks for taking time to read through and provide feedback Gordon. Your comments are definitely guiding me towards a better solution. Rupert On 3/6/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Rupert Smith wrote: > http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Specification Control of tests is still done through direct interaction between clients. The aim of the centralized approach was to restrict all control traffic to occur between a test client and the controller, not between test clients themselves. I think this keeps the test clients simpler while allowing richer composition of these clients into different scenarios. e.g. A test sender only needs to send messages to a particular 'destination', then inform the controller what it has done. A test receiver merely listens for messages, and reports back what it received when the test completes. Any communication between the test clients is part of the test, not part of the control. I'm also not clear why the clients respond to invites by sending messages to the control topic. That means all clients see all messages and have to ignore those that are not relevant. I'd prefer to keep the clients as isolated from each other as possible. Messages for the controller would be sent directly to the controller and would not be broadcast to all listeners. The controller in this view is not a generic test runner that merely triggers tests; it simplifies the language dependant parts by extracting as much as possible from them, implementing it once in one place where it is easier to change or extend.
