qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Draft Interop Testing Spec - Please Read
Date Wed, 07 Mar 2007 08:37:23 GMT
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 <gsim@redhat.com> 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.
>

Mime
View raw message