qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: C++ M2 JIRAs
Date Wed, 02 May 2007 11:29:47 GMT
Ok, lets just leave things as they are then. Seems more important to just
get the code written at the moment. I'll add those clarifications.

Rupert

On 02/05/07, Gordon Sim <gsim@redhat.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message