Rupert Smith wrote:
[...]
On 02/05/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
* I'm guessing that the reply-to on both messages would be the same
anyway, but probably worth clarifying. This also means we have to
standardise on the format for reply-to - I'll take what the jms client
does as that standard for now. (In part I would rather use a well-known
queue for responses, but whats there works as well).
Yes, I put the reply-to in both the start and status request messages. I'm
always using the same queue for this though, so could change to a
well-known
queue and get rid of the reply-to's if needed.
Not necessary, it works as is I was only indicating preference. I'm
working on the assumption that the format will be:
<exchange type>://<exchange name>/<routing key>?<options>
and all I need is the exchange name and routing key. Is that correct?
Some suggestions:
* can we combine the role assignment and start controls? (This would get
rid of the ambiguity pointed out in the second question above).
Want to make sure that both clients have accepted their roles before
calling
start. Are you saying you want to send start_role to reciever, wait for
ack,
then send start_role to sender, then wait for reports from both?
I'm suggesting that, yes. The assign role request doesn't do much for
senders and the start isn't needed for receivers. My thought was that
combining them and starting roles in order might be simpler. Ideally I'd
like the test runner framework not to need to care about roles, and
leave that to the specific test definitions. Not a big deal though, just
a suggestion.
* do we need both CLIENT_NAME and CLIENT_PRIVATE_CONTROL_KEY given that
the latter includes the former? e.g. could we just assign names to
processes from the command line and use a topic style hierachy such as
iop.control.java.receiver1, iop.control.java.receiver2,
iop.control.cpp.sender1 etc
Yes, we could do that. The private control key always begins with
iop.control so its a little pointless to send that along with the client
name.
I don't mind sending the 'iop.control' at the start. I just think
sending both properties isn't needed.
* STATUS_REQUEST seems more like a STOP request to me, sent to roles
that do not have a natural, automatic completion point. All roles would
send a report on completion.
It seemed to me that the sender would know when it is done, but the
receiver
might not. So if the test was for 100 messages, the sender knows its done
once it has sent 100. If some didn't make it to the reciever, it might have
got less than 100 and still be waiting for some. So it can't decide if it
should keep waiting or send its report for less than 100. I chose the
sequence send start to sender, wait for senders report then send status
request to receiver (effectively telling it that its time is up). I guess
what you are saying is that you'd prefer STATUS_REQUEST to be renamed to
STOP?
Yes! Again not a big deal.
[...]
I've noted some things that are to be changed in the spec.
Do you want me to also change the following?
Use well known reply address rather than reply-to field.
Combine role assignment and start, but make sure reciever is started before
sender.
Use standard naming of client private control address, so only send client
name in enlists.
Rename status request to stop.
Depends on how you feel about them and how much effort it would be to
change any code already written. Using reply-to is probably a good idea
as it avoids having hardcoded addresses in all the different test
runners, lets stick with that. The others are just suggestions, your call!
