Mailing-List: contact qpid-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: qpid-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of rupertlssmith@googlemail.com
 designates 64.233.162.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=MtPWDnDbDyepex1eTXgekdDbaVB2EbuzTYV00bg/jM9zuUGsK38yVd0c/XWpImv+5It2JxyPt3ZrHE5FMtj/+KsQevFJqCOdZhNz5n0lf6k+p04Ps3G3M38Rgc409WWfPOH7uRI77SMwmY6FDQKkkQ/hoCWBAeiXnTqw+5QgVNc=
Message-ID: <a21e8c210705020340q1ab02532m570d0b1ffa1dfffe@mail.gmail.com>
Date: Wed, 2 May 2007 11:40:13 +0100
From: "Rupert Smith" <rupertlssmith@googlemail.com>
To: qpid-dev@incubator.apache.org
Subject: Re: C++ M2 JIRAs
In-Reply-To: <46386171.4090306@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5698_9373078.1178102413751"
References: <1177356048.32369.20.camel@localhost.localdomain>
	 <4635AF72.3040409@redhat.com>
	 <a21e8c210705020229i69d79223gcc4a4d70fa81128c@mail.gmail.com>
	 <46386171.4090306@redhat.com>

------=_Part_5698_9373078.1178102413751
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 02/05/07, Gordon Sim <gsim@redhat.com> wrote:
>
> Rupert Smith wrote:
> > I have some pending commits to make on the Java side of interop to
> complete
> > it. Are you doing the C++ as per the spec. so they will talk to one
> > another?
>
> Yes, I am trying to do that. Also looking at whats there so far on the
> java side.
>
> The property name for the assigned role isn't yet specified (at least I
> couldn't find it). I just used 'ROLE' for now. The valid values aren't
> specified either - ideally that would be done per test case to allow
> future cases to vary the roles if needed.


Will add that to the spec. Property 'ROLE',  valid values for all test cases
defined so far 'SENDER' and 'RECEIVER'

Some questions:
>
> * Does start only get called for certain roles (e.g. sender)?


Yes, only calls start on the sender to tell it to start sending. Will
clarify that in the spec.

* I'm assuming that the report should be sent in response to the start
> request, at least for the sender. However I wasn't sure if the receiver
> should do the same or send it in response to the status request.


The sender sends its report in response to the start. The receiver sends its
report in response to a status request. Will clarify in spec.


* 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.

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?

* 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.

* 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?

> Once I've got the Java checked in I think I will write the interop test
> > clients for .Net too.
> >
> > Also, I'm doing this on the M2 branch.
>
> Me too.
>

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.

Rupert

------=_Part_5698_9373078.1178102413751--