qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: C++ M2 JIRAs
Date Wed, 02 May 2007 11:17:33 GMT
Rupert Smith wrote:
[...]
> On 02/05/07, Gordon Sim <gsim@redhat.com> 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!


Mime
View raw message