C++ M2 JIRAs

[Alan Conway <ac...@redhat.com>]

I've marked 6 C++ JIRAs as Fix for M2
https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12311718&mode=hide

3 are for interop tests, those are marked critical, I don't think we
should release without a working interop test framework to prove we talk
to each other.

The other 3 are to add initial demos and and make control of the broker
easier. They can all be done by one person inside a week and none are
show stoppers. 

Gordon - I think you were planning to work on interop, can you give some
idea of when that could be completed for a release?

Cheers,
Alan.

Re: Interop test runner command line options

[Gordon Sim <gs...@redhat.com>]

Rupert Smith wrote:
> Yeah, thats seems more intuitive. I'll go with that.

Great, thanks! I have updated the spec page accordingly, hope that is ok 
(if not shold be easy to revert).

Re: Interop test runner command line options

[Rupert Smith <ru...@googlemail.com>]

Yeah, thats seems more intuitive. I'll go with that.

Rupert

On 03/05/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Rupert,
>
> Could we modify the standard command line options to the client test
> programs slightly? In particular could we use '-v' for virtual host,
> leaving '-h (or --help) for a usage statement? Also instead of a broker
> url could we just specify hostname and port as separate options (-b and
> -p, say)?
>
> --Gordon.
>

Interop test runner command line options

[Gordon Sim <gs...@redhat.com>]

Rupert,

Could we modify the standard command line options to the client test 
programs slightly? In particular could we use '-v' for virtual host, 
leaving '-h (or --help) for a usage statement? Also instead of a broker 
url could we just specify hostname and port as separate options (-b and 
-p, say)?

--Gordon.

Re: C++ M2 JIRAs

[Rupert Smith <ru...@googlemail.com>]

Your point about trying to make the coordinator not care too much about the
what the clients are doing is valid, and worth pursuing for the purpose of
making the coordinator abstract enough to be re-usable for different kinds
of tests. I think the coordinator as a whole does need to be aware of the
roles it assigns to test clients to ensure that it assigns receiver roles
before starting senders. This behaviour has been encapsulated in the
CoordinatingTestCase class.

The purpose of CoordinatingTestCase is to coordinate a two participant
sender/receiver test. I may pull an interface out of it add another
implementation the purpose of which is to coordinate a multi-client
performance test. This will consist of a group of 'senders' (which probably
also consume their own messages), spread over a set of test machines, and
the coordinator will be used to to run a distributed test using the test
machines to try and provide a better simulation of broker load with a large
number of connections. One limit of the current performance tests is that
they only run on a single client machine, limiting their scalability.
Performance tests have been run up to 1000 connections, but with that many
threads on the client machine, the overhead impacts the results obtained.

Should be able to do distributed performance testing with the current design
by only changing the coordinator to introduce a new kind of test case,
without making any changes to existing interop test clients.

On 02/05/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Rupert Smith wrote:
> > 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.
>
> Well, if we want to make the changes at some point, now would be the
> best time before more code is in place. The question is whether they
> actually simplify things or whether they just represent my preference.
> However, I can live with whats there now.
>

Re: C++ M2 JIRAs

[Gordon Sim <gs...@redhat.com>]

Rupert Smith wrote:
> 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.

Well, if we want to make the changes at some point, now would be the 
best time before more code is in place. The question is whether they 
actually simplify things or whether they just represent my preference. 
However, I can live with whats there now.

Re: C++ M2 JIRAs

[Rupert Smith <ru...@googlemail.com>]

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 <gs...@redhat.com> wrote:
>
> Rupert Smith wrote:
> [...]
> > On 02/05/07, Gordon Sim <gs...@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!
>
>

Re: C++ M2 JIRAs

[Gordon Sim <gs...@redhat.com>]

Rupert Smith wrote:
[...]
> On 02/05/07, Gordon Sim <gs...@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!

Re: C++ M2 JIRAs

[Rupert Smith <ru...@googlemail.com>]

On 02/05/07, Gordon Sim <gs...@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

Re: C++ M2 JIRAs

[Gordon Sim <gs...@redhat.com>]

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.

Some questions:

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

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

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

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

* 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

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

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

Re: C++ M2 JIRAs

[Rupert Smith <ru...@googlemail.com>]

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

Rupert

On 30/04/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Alan Conway wrote:
> > I've marked 6 C++ JIRAs as Fix for M2
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12311718&mode=hide
> >
> > 3 are for interop tests, those are marked critical, I don't think we
> > should release without a working interop test framework to prove we talk
> > to each other.
> >
> > The other 3 are to add initial demos and and make control of the broker
> > easier. They can all be done by one person inside a week and none are
> > show stoppers.
> >
> > Gordon - I think you were planning to work on interop, can you give some
> > idea of when that could be completed for a release?
>
> I have now assigned myself QPID-412 (Implement initial c++ interop
> tests) and will start on that right away. Hopefully I should have some
> demonstrable interop between java and c++ tested by the end of the week.
> I'll send updates earlier if relevant.
>

Re: C++ M2 JIRAs

[Gordon Sim <gs...@redhat.com>]

Alan Conway wrote:
> I've marked 6 C++ JIRAs as Fix for M2
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12311718&mode=hide
> 
> 3 are for interop tests, those are marked critical, I don't think we
> should release without a working interop test framework to prove we talk
> to each other.
> 
> The other 3 are to add initial demos and and make control of the broker
> easier. They can all be done by one person inside a week and none are
> show stoppers. 
> 
> Gordon - I think you were planning to work on interop, can you give some
> idea of when that could be completed for a release?

I have now assigned myself QPID-412 (Implement initial c++ interop 
tests) and will start on that right away. Hopefully I should have some 
demonstrable interop between java and c++ tested by the end of the week. 
I'll send updates earlier if relevant.