You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Michael Stover <ms...@apache.org> on 2005/06/15 19:23:24 UTC
2.1 release
What needs doing before we can release 2.1? As far as I'm concerned,
we're ready for at least a release candidate. Sebb - any todos
outstanding?
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
tonight I plan to update the release notes to list the relevant
changes/additions.
peter
On 6/28/05, Michael Stover <ms...@apache.org> wrote:
> Creating a release branch is part of the process. It's what allows new
> development to happen without interfering with version 2.1
>
> -Mike
>
> On Tue, 2005-06-28 at 23:18 +0100, sebb wrote:
> > +1 to 2.1 RC
> >
> > Not sure that we need a 2.1 branch though.
> >
> > S.
> > On 6/28/05, Peter Lin <wo...@gmail.com> wrote:
> > > +1
> > >
> > > hurray, we're releasing more often
> > >
> > > peter
> > >
> > > On 6/28/05, Michael Stover <ms...@apache.org> wrote:
> > > > I'm of the opinion we should get a 2.1 release candidate out there. We
> > > > can work on the documentation and some bugs after an candidate release
> > > > just as well as before. Shall I branch 2.1 in CVS?
> > > >
> > > > -Mike
> > > >
> > > > On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> > > > > What else do we need to do for the 2.1 release :)
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > To "fix" runtime controller, you could put the endOfLoop() check
> > > > > > directly in the next() method. That way, it will know to return null as
> > > > > > soon as its time is up. As it is currently, it only checks this if it's
> > > > > > nextIsNull() method is ever called, which it won't be in the case
> > > > > > presented in that bug - ie, where it's child is a forever loop.
> > > > > >
> > > > > > This change would affect the controller, which currently only stops a
> > > > > > run at boundaries of its children (ie, after its last child sampler, or
> > > > > > the last child controller goes). This has the positive effect of
> > > > > > treating the Runtime Controller's children as an inviolable group of
> > > > > > requests that either all go, or none. If we make this change, then the
> > > > > > Runtime Controller halts operation as soon as the time is up, even if
> > > > > > it's on the third sampler of five.
> > > > > >
> > > > > > I don't see a third alternative, because the Loop Controller, when set
> > > > > > to infinite, never sends any signals to its parent controllers on when
> > > > > > it starts a new loop. To its children, yes, but not the parents. Which
> > > > > > means for the Runtime Controller to decided "enough is enough", it has
> > > > > > to make the decision arbitrarily, with no notion of where in its cycle
> > > > > > the Loop Controller is at.
> > > > > >
> > > > > > Frankly, I think the scenario presented in the bug is one of the more
> > > > > > obvious use-cases of the Runtime Controller, and I think it should be
> > > > > > changed as I suggest. The docs would need to reflect the behavior
> > > > > > change.
> > > > > >
> > > > > > -Mike
> > > > > >
> > > > > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > > > > all of these ?
> > > > > > > - Messaging Request
> > > > > > > - JNDI Default Configuration
> > > > > > > - LDAPArgument List
> > > > > > >
> > > > > > > I can create empty place-holders, but I don't know enough to be able
> > > > > > > to document them.
> > > > > > >
> > > > > > > There's a "new" bug in Runtime Controller - see
> > > > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > > > > >
> > > > > > > I must have broken that when I fixed various other problems with the
> > > > > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > > > > fix it without breaking the others ...
> > > > > > >
> > > > > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > > > > test-case, but fixing it is another matter.
> > > > > > >
> > > > > > > There are of course other bugs, but the RT used to work, so it would
> > > > > > > be good if it could be fixed.
> > > > > > >
> > > > > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > > > > etc, but they can wait.
> > > > > > >
> > > > > > > BTW, the test load and save tests are failing because various extra
> > > > > > > fields are being saved.
> > > > > > >
> > > > > > > S.
> > > > > > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > > I will finish writing the jms topic how-to and update the index number
> > > > > > > > this weekend.
> > > > > > > >
> > > > > > > >
> > > > > > > > peter
> > > > > > > >
> > > > > > > >
> > > > > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > > > > > outstanding?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
> --
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Michael Stover <ms...@apache.org>.
Creating a release branch is part of the process. It's what allows new
development to happen without interfering with version 2.1
-Mike
On Tue, 2005-06-28 at 23:18 +0100, sebb wrote:
> +1 to 2.1 RC
>
> Not sure that we need a 2.1 branch though.
>
> S.
> On 6/28/05, Peter Lin <wo...@gmail.com> wrote:
> > +1
> >
> > hurray, we're releasing more often
> >
> > peter
> >
> > On 6/28/05, Michael Stover <ms...@apache.org> wrote:
> > > I'm of the opinion we should get a 2.1 release candidate out there. We
> > > can work on the documentation and some bugs after an candidate release
> > > just as well as before. Shall I branch 2.1 in CVS?
> > >
> > > -Mike
> > >
> > > On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> > > > What else do we need to do for the 2.1 release :)
> > > >
> > > > peter
> > > >
> > > >
> > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > To "fix" runtime controller, you could put the endOfLoop() check
> > > > > directly in the next() method. That way, it will know to return null as
> > > > > soon as its time is up. As it is currently, it only checks this if it's
> > > > > nextIsNull() method is ever called, which it won't be in the case
> > > > > presented in that bug - ie, where it's child is a forever loop.
> > > > >
> > > > > This change would affect the controller, which currently only stops a
> > > > > run at boundaries of its children (ie, after its last child sampler, or
> > > > > the last child controller goes). This has the positive effect of
> > > > > treating the Runtime Controller's children as an inviolable group of
> > > > > requests that either all go, or none. If we make this change, then the
> > > > > Runtime Controller halts operation as soon as the time is up, even if
> > > > > it's on the third sampler of five.
> > > > >
> > > > > I don't see a third alternative, because the Loop Controller, when set
> > > > > to infinite, never sends any signals to its parent controllers on when
> > > > > it starts a new loop. To its children, yes, but not the parents. Which
> > > > > means for the Runtime Controller to decided "enough is enough", it has
> > > > > to make the decision arbitrarily, with no notion of where in its cycle
> > > > > the Loop Controller is at.
> > > > >
> > > > > Frankly, I think the scenario presented in the bug is one of the more
> > > > > obvious use-cases of the Runtime Controller, and I think it should be
> > > > > changed as I suggest. The docs would need to reflect the behavior
> > > > > change.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > > > all of these ?
> > > > > > - Messaging Request
> > > > > > - JNDI Default Configuration
> > > > > > - LDAPArgument List
> > > > > >
> > > > > > I can create empty place-holders, but I don't know enough to be able
> > > > > > to document them.
> > > > > >
> > > > > > There's a "new" bug in Runtime Controller - see
> > > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > > > >
> > > > > > I must have broken that when I fixed various other problems with the
> > > > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > > > fix it without breaking the others ...
> > > > > >
> > > > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > > > test-case, but fixing it is another matter.
> > > > > >
> > > > > > There are of course other bugs, but the RT used to work, so it would
> > > > > > be good if it could be fixed.
> > > > > >
> > > > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > > > etc, but they can wait.
> > > > > >
> > > > > > BTW, the test load and save tests are failing because various extra
> > > > > > fields are being saved.
> > > > > >
> > > > > > S.
> > > > > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > > I will finish writing the jms topic how-to and update the index number
> > > > > > > this weekend.
> > > > > > >
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > > > > outstanding?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
--
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by sebb <se...@gmail.com>.
+1 to 2.1 RC
Not sure that we need a 2.1 branch though.
S.
On 6/28/05, Peter Lin <wo...@gmail.com> wrote:
> +1
>
> hurray, we're releasing more often
>
> peter
>
> On 6/28/05, Michael Stover <ms...@apache.org> wrote:
> > I'm of the opinion we should get a 2.1 release candidate out there. We
> > can work on the documentation and some bugs after an candidate release
> > just as well as before. Shall I branch 2.1 in CVS?
> >
> > -Mike
> >
> > On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> > > What else do we need to do for the 2.1 release :)
> > >
> > > peter
> > >
> > >
> > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > To "fix" runtime controller, you could put the endOfLoop() check
> > > > directly in the next() method. That way, it will know to return null as
> > > > soon as its time is up. As it is currently, it only checks this if it's
> > > > nextIsNull() method is ever called, which it won't be in the case
> > > > presented in that bug - ie, where it's child is a forever loop.
> > > >
> > > > This change would affect the controller, which currently only stops a
> > > > run at boundaries of its children (ie, after its last child sampler, or
> > > > the last child controller goes). This has the positive effect of
> > > > treating the Runtime Controller's children as an inviolable group of
> > > > requests that either all go, or none. If we make this change, then the
> > > > Runtime Controller halts operation as soon as the time is up, even if
> > > > it's on the third sampler of five.
> > > >
> > > > I don't see a third alternative, because the Loop Controller, when set
> > > > to infinite, never sends any signals to its parent controllers on when
> > > > it starts a new loop. To its children, yes, but not the parents. Which
> > > > means for the Runtime Controller to decided "enough is enough", it has
> > > > to make the decision arbitrarily, with no notion of where in its cycle
> > > > the Loop Controller is at.
> > > >
> > > > Frankly, I think the scenario presented in the bug is one of the more
> > > > obvious use-cases of the Runtime Controller, and I think it should be
> > > > changed as I suggest. The docs would need to reflect the behavior
> > > > change.
> > > >
> > > > -Mike
> > > >
> > > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > > all of these ?
> > > > > - Messaging Request
> > > > > - JNDI Default Configuration
> > > > > - LDAPArgument List
> > > > >
> > > > > I can create empty place-holders, but I don't know enough to be able
> > > > > to document them.
> > > > >
> > > > > There's a "new" bug in Runtime Controller - see
> > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > > >
> > > > > I must have broken that when I fixed various other problems with the
> > > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > > fix it without breaking the others ...
> > > > >
> > > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > > test-case, but fixing it is another matter.
> > > > >
> > > > > There are of course other bugs, but the RT used to work, so it would
> > > > > be good if it could be fixed.
> > > > >
> > > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > > etc, but they can wait.
> > > > >
> > > > > BTW, the test load and save tests are failing because various extra
> > > > > fields are being saved.
> > > > >
> > > > > S.
> > > > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > > I will finish writing the jms topic how-to and update the index number
> > > > > > this weekend.
> > > > > >
> > > > > >
> > > > > > peter
> > > > > >
> > > > > >
> > > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > > > outstanding?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
+1
hurray, we're releasing more often
peter
On 6/28/05, Michael Stover <ms...@apache.org> wrote:
> I'm of the opinion we should get a 2.1 release candidate out there. We
> can work on the documentation and some bugs after an candidate release
> just as well as before. Shall I branch 2.1 in CVS?
>
> -Mike
>
> On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> > What else do we need to do for the 2.1 release :)
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > To "fix" runtime controller, you could put the endOfLoop() check
> > > directly in the next() method. That way, it will know to return null as
> > > soon as its time is up. As it is currently, it only checks this if it's
> > > nextIsNull() method is ever called, which it won't be in the case
> > > presented in that bug - ie, where it's child is a forever loop.
> > >
> > > This change would affect the controller, which currently only stops a
> > > run at boundaries of its children (ie, after its last child sampler, or
> > > the last child controller goes). This has the positive effect of
> > > treating the Runtime Controller's children as an inviolable group of
> > > requests that either all go, or none. If we make this change, then the
> > > Runtime Controller halts operation as soon as the time is up, even if
> > > it's on the third sampler of five.
> > >
> > > I don't see a third alternative, because the Loop Controller, when set
> > > to infinite, never sends any signals to its parent controllers on when
> > > it starts a new loop. To its children, yes, but not the parents. Which
> > > means for the Runtime Controller to decided "enough is enough", it has
> > > to make the decision arbitrarily, with no notion of where in its cycle
> > > the Loop Controller is at.
> > >
> > > Frankly, I think the scenario presented in the bug is one of the more
> > > obvious use-cases of the Runtime Controller, and I think it should be
> > > changed as I suggest. The docs would need to reflect the behavior
> > > change.
> > >
> > > -Mike
> > >
> > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > all of these ?
> > > > - Messaging Request
> > > > - JNDI Default Configuration
> > > > - LDAPArgument List
> > > >
> > > > I can create empty place-holders, but I don't know enough to be able
> > > > to document them.
> > > >
> > > > There's a "new" bug in Runtime Controller - see
> > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > >
> > > > I must have broken that when I fixed various other problems with the
> > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > fix it without breaking the others ...
> > > >
> > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > test-case, but fixing it is another matter.
> > > >
> > > > There are of course other bugs, but the RT used to work, so it would
> > > > be good if it could be fixed.
> > > >
> > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > etc, but they can wait.
> > > >
> > > > BTW, the test load and save tests are failing because various extra
> > > > fields are being saved.
> > > >
> > > > S.
> > > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > I will finish writing the jms topic how-to and update the index number
> > > > > this weekend.
> > > > >
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > > outstanding?
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Michael Stover <ms...@apache.org>.
I'm of the opinion we should get a 2.1 release candidate out there. We
can work on the documentation and some bugs after an candidate release
just as well as before. Shall I branch 2.1 in CVS?
-Mike
On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> What else do we need to do for the 2.1 release :)
>
> peter
>
>
> On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > To "fix" runtime controller, you could put the endOfLoop() check
> > directly in the next() method. That way, it will know to return null as
> > soon as its time is up. As it is currently, it only checks this if it's
> > nextIsNull() method is ever called, which it won't be in the case
> > presented in that bug - ie, where it's child is a forever loop.
> >
> > This change would affect the controller, which currently only stops a
> > run at boundaries of its children (ie, after its last child sampler, or
> > the last child controller goes). This has the positive effect of
> > treating the Runtime Controller's children as an inviolable group of
> > requests that either all go, or none. If we make this change, then the
> > Runtime Controller halts operation as soon as the time is up, even if
> > it's on the third sampler of five.
> >
> > I don't see a third alternative, because the Loop Controller, when set
> > to infinite, never sends any signals to its parent controllers on when
> > it starts a new loop. To its children, yes, but not the parents. Which
> > means for the Runtime Controller to decided "enough is enough", it has
> > to make the decision arbitrarily, with no notion of where in its cycle
> > the Loop Controller is at.
> >
> > Frankly, I think the scenario presented in the bug is one of the more
> > obvious use-cases of the Runtime Controller, and I think it should be
> > changed as I suggest. The docs would need to reflect the behavior
> > change.
> >
> > -Mike
> >
> > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > Various JMS test elements have no documentation - Peter, are you doing
> > > all of these ?
> > > - Messaging Request
> > > - JNDI Default Configuration
> > > - LDAPArgument List
> > >
> > > I can create empty place-holders, but I don't know enough to be able
> > > to document them.
> > >
> > > There's a "new" bug in Runtime Controller - see
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > >
> > > I must have broken that when I fixed various other problems with the
> > > If, While and Once only controllers. Unfortunately I don't know how to
> > > fix it without breaking the others ...
> > >
> > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > test-case, but fixing it is another matter.
> > >
> > > There are of course other bugs, but the RT used to work, so it would
> > > be good if it could be fixed.
> > >
> > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > etc, but they can wait.
> > >
> > > BTW, the test load and save tests are failing because various extra
> > > fields are being saved.
> > >
> > > S.
> > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > I will finish writing the jms topic how-to and update the index number
> > > > this weekend.
> > > >
> > > >
> > > > peter
> > > >
> > > >
> > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > outstanding?
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
I'll take a look and try to get that fixed by the weekend.
peter
On 6/21/05, sebb <se...@gmail.com> wrote:
> The test run shows that component reference is missing the following entry:
> 'JNDI Default Configuration' -
> org.apache.jmeter.protocol.jms.control.gui.JndiDefaultsGui
> It would be useful to document that.
>
> The other test run error messages are:
> - the class org.apache.jmeter.protocol.jms.control.gui.JmsTestSampleGui
> is what causes the missing 'Messaging Request' message. However,
> selecting this sampler in a test plan produces a JMS Point to Point
> Sampler embedded in the Messaging name panel. Looks a it odd. I
> suspect this class should be deleted. It's confusing to have the
> Messaging sampler in the menus.
>
> - the class org.apache.jmeter.protocol.ldap.config.gui.LDAPArgumentsPanel
> is defined as a sub-class of AbstractConfigGui, hence the missing
> component entry for 'LDAPArgument List'. I don't know if it was ever a
> stand-alone GUI element, but at present it is used by LdapExtConfigGui
> only. It should probably be a sub-class of JPanel (like UrlConfigGui).
> But that could be fixed later.
>
> S
> On 6/21/05, Peter Lin <wo...@gmail.com> wrote:
> > What else do we need to do for the 2.1 release :)
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > To "fix" runtime controller, you could put the endOfLoop() check
> > > directly in the next() method. That way, it will know to return null as
> > > soon as its time is up. As it is currently, it only checks this if it's
> > > nextIsNull() method is ever called, which it won't be in the case
> > > presented in that bug - ie, where it's child is a forever loop.
> > >
> > > This change would affect the controller, which currently only stops a
> > > run at boundaries of its children (ie, after its last child sampler, or
> > > the last child controller goes). This has the positive effect of
> > > treating the Runtime Controller's children as an inviolable group of
> > > requests that either all go, or none. If we make this change, then the
> > > Runtime Controller halts operation as soon as the time is up, even if
> > > it's on the third sampler of five.
> > >
> > > I don't see a third alternative, because the Loop Controller, when set
> > > to infinite, never sends any signals to its parent controllers on when
> > > it starts a new loop. To its children, yes, but not the parents. Which
> > > means for the Runtime Controller to decided "enough is enough", it has
> > > to make the decision arbitrarily, with no notion of where in its cycle
> > > the Loop Controller is at.
> > >
> > > Frankly, I think the scenario presented in the bug is one of the more
> > > obvious use-cases of the Runtime Controller, and I think it should be
> > > changed as I suggest. The docs would need to reflect the behavior
> > > change.
> > >
> > > -Mike
> > >
> > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > all of these ?
> > > > - Messaging Request
> > > > - JNDI Default Configuration
> > > > - LDAPArgument List
> > > >
> > > > I can create empty place-holders, but I don't know enough to be able
> > > > to document them.
> > > >
> > > > There's a "new" bug in Runtime Controller - see
> > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > >
> > > > I must have broken that when I fixed various other problems with the
> > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > fix it without breaking the others ...
> > > >
> > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > test-case, but fixing it is another matter.
> > > >
> > > > There are of course other bugs, but the RT used to work, so it would
> > > > be good if it could be fixed.
> > > >
> > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > etc, but they can wait.
> > > >
> > > > BTW, the test load and save tests are failing because various extra
> > > > fields are being saved.
> > > >
> > > > S.
> > > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > > I will finish writing the jms topic how-to and update the index number
> > > > > this weekend.
> > > > >
> > > > >
> > > > > peter
> > > > >
> > > > >
> > > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > > outstanding?
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by sebb <se...@gmail.com>.
The test run shows that component reference is missing the following entry:
'JNDI Default Configuration' -
org.apache.jmeter.protocol.jms.control.gui.JndiDefaultsGui
It would be useful to document that.
The other test run error messages are:
- the class org.apache.jmeter.protocol.jms.control.gui.JmsTestSampleGui
is what causes the missing 'Messaging Request' message. However,
selecting this sampler in a test plan produces a JMS Point to Point
Sampler embedded in the Messaging name panel. Looks a it odd. I
suspect this class should be deleted. It's confusing to have the
Messaging sampler in the menus.
- the class org.apache.jmeter.protocol.ldap.config.gui.LDAPArgumentsPanel
is defined as a sub-class of AbstractConfigGui, hence the missing
component entry for 'LDAPArgument List'. I don't know if it was ever a
stand-alone GUI element, but at present it is used by LdapExtConfigGui
only. It should probably be a sub-class of JPanel (like UrlConfigGui).
But that could be fixed later.
S
On 6/21/05, Peter Lin <wo...@gmail.com> wrote:
> What else do we need to do for the 2.1 release :)
>
> peter
>
>
> On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > To "fix" runtime controller, you could put the endOfLoop() check
> > directly in the next() method. That way, it will know to return null as
> > soon as its time is up. As it is currently, it only checks this if it's
> > nextIsNull() method is ever called, which it won't be in the case
> > presented in that bug - ie, where it's child is a forever loop.
> >
> > This change would affect the controller, which currently only stops a
> > run at boundaries of its children (ie, after its last child sampler, or
> > the last child controller goes). This has the positive effect of
> > treating the Runtime Controller's children as an inviolable group of
> > requests that either all go, or none. If we make this change, then the
> > Runtime Controller halts operation as soon as the time is up, even if
> > it's on the third sampler of five.
> >
> > I don't see a third alternative, because the Loop Controller, when set
> > to infinite, never sends any signals to its parent controllers on when
> > it starts a new loop. To its children, yes, but not the parents. Which
> > means for the Runtime Controller to decided "enough is enough", it has
> > to make the decision arbitrarily, with no notion of where in its cycle
> > the Loop Controller is at.
> >
> > Frankly, I think the scenario presented in the bug is one of the more
> > obvious use-cases of the Runtime Controller, and I think it should be
> > changed as I suggest. The docs would need to reflect the behavior
> > change.
> >
> > -Mike
> >
> > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > Various JMS test elements have no documentation - Peter, are you doing
> > > all of these ?
> > > - Messaging Request
> > > - JNDI Default Configuration
> > > - LDAPArgument List
> > >
> > > I can create empty place-holders, but I don't know enough to be able
> > > to document them.
> > >
> > > There's a "new" bug in Runtime Controller - see
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > >
> > > I must have broken that when I fixed various other problems with the
> > > If, While and Once only controllers. Unfortunately I don't know how to
> > > fix it without breaking the others ...
> > >
> > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > test-case, but fixing it is another matter.
> > >
> > > There are of course other bugs, but the RT used to work, so it would
> > > be good if it could be fixed.
> > >
> > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > etc, but they can wait.
> > >
> > > BTW, the test load and save tests are failing because various extra
> > > fields are being saved.
> > >
> > > S.
> > > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > > I will finish writing the jms topic how-to and update the index number
> > > > this weekend.
> > > >
> > > >
> > > > peter
> > > >
> > > >
> > > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > > we're ready for at least a release candidate. Sebb - any todos
> > > > > outstanding?
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
What else do we need to do for the 2.1 release :)
peter
On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> To "fix" runtime controller, you could put the endOfLoop() check
> directly in the next() method. That way, it will know to return null as
> soon as its time is up. As it is currently, it only checks this if it's
> nextIsNull() method is ever called, which it won't be in the case
> presented in that bug - ie, where it's child is a forever loop.
>
> This change would affect the controller, which currently only stops a
> run at boundaries of its children (ie, after its last child sampler, or
> the last child controller goes). This has the positive effect of
> treating the Runtime Controller's children as an inviolable group of
> requests that either all go, or none. If we make this change, then the
> Runtime Controller halts operation as soon as the time is up, even if
> it's on the third sampler of five.
>
> I don't see a third alternative, because the Loop Controller, when set
> to infinite, never sends any signals to its parent controllers on when
> it starts a new loop. To its children, yes, but not the parents. Which
> means for the Runtime Controller to decided "enough is enough", it has
> to make the decision arbitrarily, with no notion of where in its cycle
> the Loop Controller is at.
>
> Frankly, I think the scenario presented in the bug is one of the more
> obvious use-cases of the Runtime Controller, and I think it should be
> changed as I suggest. The docs would need to reflect the behavior
> change.
>
> -Mike
>
> On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > Various JMS test elements have no documentation - Peter, are you doing
> > all of these ?
> > - Messaging Request
> > - JNDI Default Configuration
> > - LDAPArgument List
> >
> > I can create empty place-holders, but I don't know enough to be able
> > to document them.
> >
> > There's a "new" bug in Runtime Controller - see
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> >
> > I must have broken that when I fixed various other problems with the
> > If, While and Once only controllers. Unfortunately I don't know how to
> > fix it without breaking the others ...
> >
> > AFAIK, there's no test case for the RT C, which is presumably why the
> > problem was not noticed earlier. I'm fairly sure that I can create a
> > test-case, but fixing it is another matter.
> >
> > There are of course other bugs, but the RT used to work, so it would
> > be good if it could be fixed.
> >
> > I still want to do some more fixes on HTTPsamplers and SampleResult
> > etc, but they can wait.
> >
> > BTW, the test load and save tests are failing because various extra
> > fields are being saved.
> >
> > S.
> > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > I will finish writing the jms topic how-to and update the index number
> > > this weekend.
> > >
> > >
> > > peter
> > >
> > >
> > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > we're ready for at least a release candidate. Sebb - any todos
> > > > outstanding?
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Michael Stover <ms...@apache.org>.
To "fix" runtime controller, you could put the endOfLoop() check
directly in the next() method. That way, it will know to return null as
soon as its time is up. As it is currently, it only checks this if it's
nextIsNull() method is ever called, which it won't be in the case
presented in that bug - ie, where it's child is a forever loop.
This change would affect the controller, which currently only stops a
run at boundaries of its children (ie, after its last child sampler, or
the last child controller goes). This has the positive effect of
treating the Runtime Controller's children as an inviolable group of
requests that either all go, or none. If we make this change, then the
Runtime Controller halts operation as soon as the time is up, even if
it's on the third sampler of five.
I don't see a third alternative, because the Loop Controller, when set
to infinite, never sends any signals to its parent controllers on when
it starts a new loop. To its children, yes, but not the parents. Which
means for the Runtime Controller to decided "enough is enough", it has
to make the decision arbitrarily, with no notion of where in its cycle
the Loop Controller is at.
Frankly, I think the scenario presented in the bug is one of the more
obvious use-cases of the Runtime Controller, and I think it should be
changed as I suggest. The docs would need to reflect the behavior
change.
-Mike
On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> Various JMS test elements have no documentation - Peter, are you doing
> all of these ?
> - Messaging Request
> - JNDI Default Configuration
> - LDAPArgument List
>
> I can create empty place-holders, but I don't know enough to be able
> to document them.
>
> There's a "new" bug in Runtime Controller - see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
>
> I must have broken that when I fixed various other problems with the
> If, While and Once only controllers. Unfortunately I don't know how to
> fix it without breaking the others ...
>
> AFAIK, there's no test case for the RT C, which is presumably why the
> problem was not noticed earlier. I'm fairly sure that I can create a
> test-case, but fixing it is another matter.
>
> There are of course other bugs, but the RT used to work, so it would
> be good if it could be fixed.
>
> I still want to do some more fixes on HTTPsamplers and SampleResult
> etc, but they can wait.
>
> BTW, the test load and save tests are failing because various extra
> fields are being saved.
>
> S.
> On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > I will finish writing the jms topic how-to and update the index number
> > this weekend.
> >
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > we're ready for at least a release candidate. Sebb - any todos
> > > outstanding?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
martin already wrote the JMS docs for queue messaging and the topic
messaging how-to is 60% there. I just need to finish it and update the
index numbers. the one I'm not sure about is LDAP Argument list. I'll
look at that tonight and send out a summary
peter
On 6/15/05, sebb <se...@gmail.com> wrote:
> Various JMS test elements have no documentation - Peter, are you doing
> all of these ?
> - Messaging Request
> - JNDI Default Configuration
> - LDAPArgument List
>
> I can create empty place-holders, but I don't know enough to be able
> to document them.
>
> There's a "new" bug in Runtime Controller - see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
>
> I must have broken that when I fixed various other problems with the
> If, While and Once only controllers. Unfortunately I don't know how to
> fix it without breaking the others ...
>
> AFAIK, there's no test case for the RT C, which is presumably why the
> problem was not noticed earlier. I'm fairly sure that I can create a
> test-case, but fixing it is another matter.
>
> There are of course other bugs, but the RT used to work, so it would
> be good if it could be fixed.
>
> I still want to do some more fixes on HTTPsamplers and SampleResult
> etc, but they can wait.
>
> BTW, the test load and save tests are failing because various extra
> fields are being saved.
>
> S.
> On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > I will finish writing the jms topic how-to and update the index number
> > this weekend.
> >
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > we're ready for at least a release candidate. Sebb - any todos
> > > outstanding?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by sebb <se...@gmail.com>.
Thanks!
I've fixed the tests.
Just committed a fix for Bug 35370. Problem seemed to be that the
Header class was using the test element name for the name of the
header item, so I changed it to set a different property name.
However, I've just realised that this invalidates all existing JMX
files with Headers defined in them. So this needs to be replaced with
a better fix that preserves existing test plans - or backed out.
S.
On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> I'll take a look at the Runtime controller. The load tests probably
> need to be remade in order to pass.
>
> -Mike
>
> On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > Various JMS test elements have no documentation - Peter, are you doing
> > all of these ?
> > - Messaging Request
> > - JNDI Default Configuration
> > - LDAPArgument List
> >
> > I can create empty place-holders, but I don't know enough to be able
> > to document them.
> >
> > There's a "new" bug in Runtime Controller - see
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> >
> > I must have broken that when I fixed various other problems with the
> > If, While and Once only controllers. Unfortunately I don't know how to
> > fix it without breaking the others ...
> >
> > AFAIK, there's no test case for the RT C, which is presumably why the
> > problem was not noticed earlier. I'm fairly sure that I can create a
> > test-case, but fixing it is another matter.
> >
> > There are of course other bugs, but the RT used to work, so it would
> > be good if it could be fixed.
> >
> > I still want to do some more fixes on HTTPsamplers and SampleResult
> > etc, but they can wait.
> >
> > BTW, the test load and save tests are failing because various extra
> > fields are being saved.
> >
> > S.
> > On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > > I will finish writing the jms topic how-to and update the index number
> > > this weekend.
> > >
> > >
> > > peter
> > >
> > >
> > > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > > we're ready for at least a release candidate. Sebb - any todos
> > > > outstanding?
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Michael Stover <ms...@apache.org>.
I'll take a look at the Runtime controller. The load tests probably
need to be remade in order to pass.
-Mike
On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> Various JMS test elements have no documentation - Peter, are you doing
> all of these ?
> - Messaging Request
> - JNDI Default Configuration
> - LDAPArgument List
>
> I can create empty place-holders, but I don't know enough to be able
> to document them.
>
> There's a "new" bug in Runtime Controller - see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
>
> I must have broken that when I fixed various other problems with the
> If, While and Once only controllers. Unfortunately I don't know how to
> fix it without breaking the others ...
>
> AFAIK, there's no test case for the RT C, which is presumably why the
> problem was not noticed earlier. I'm fairly sure that I can create a
> test-case, but fixing it is another matter.
>
> There are of course other bugs, but the RT used to work, so it would
> be good if it could be fixed.
>
> I still want to do some more fixes on HTTPsamplers and SampleResult
> etc, but they can wait.
>
> BTW, the test load and save tests are failing because various extra
> fields are being saved.
>
> S.
> On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > I will finish writing the jms topic how-to and update the index number
> > this weekend.
> >
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > we're ready for at least a release candidate. Sebb - any todos
> > > outstanding?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Michael Stover <ms...@apache.org>.
Furthermore, about the Runtime Controller - it might be best to change
it so that its behavior mimics what one would expect Runtime+Loop
Forever to do. Ie, Runtime is a loop controller that stops looping when
time runs out.
-Mike
On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> Various JMS test elements have no documentation - Peter, are you doing
> all of these ?
> - Messaging Request
> - JNDI Default Configuration
> - LDAPArgument List
>
> I can create empty place-holders, but I don't know enough to be able
> to document them.
>
> There's a "new" bug in Runtime Controller - see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
>
> I must have broken that when I fixed various other problems with the
> If, While and Once only controllers. Unfortunately I don't know how to
> fix it without breaking the others ...
>
> AFAIK, there's no test case for the RT C, which is presumably why the
> problem was not noticed earlier. I'm fairly sure that I can create a
> test-case, but fixing it is another matter.
>
> There are of course other bugs, but the RT used to work, so it would
> be good if it could be fixed.
>
> I still want to do some more fixes on HTTPsamplers and SampleResult
> etc, but they can wait.
>
> BTW, the test load and save tests are failing because various extra
> fields are being saved.
>
> S.
> On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> > I will finish writing the jms topic how-to and update the index number
> > this weekend.
> >
> >
> > peter
> >
> >
> > On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > > What needs doing before we can release 2.1? As far as I'm concerned,
> > > we're ready for at least a release candidate. Sebb - any todos
> > > outstanding?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by sebb <se...@gmail.com>.
Various JMS test elements have no documentation - Peter, are you doing
all of these ?
- Messaging Request
- JNDI Default Configuration
- LDAPArgument List
I can create empty place-holders, but I don't know enough to be able
to document them.
There's a "new" bug in Runtime Controller - see
http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
I must have broken that when I fixed various other problems with the
If, While and Once only controllers. Unfortunately I don't know how to
fix it without breaking the others ...
AFAIK, there's no test case for the RT C, which is presumably why the
problem was not noticed earlier. I'm fairly sure that I can create a
test-case, but fixing it is another matter.
There are of course other bugs, but the RT used to work, so it would
be good if it could be fixed.
I still want to do some more fixes on HTTPsamplers and SampleResult
etc, but they can wait.
BTW, the test load and save tests are failing because various extra
fields are being saved.
S.
On 6/15/05, Peter Lin <wo...@gmail.com> wrote:
> I will finish writing the jms topic how-to and update the index number
> this weekend.
>
>
> peter
>
>
> On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> > What needs doing before we can release 2.1? As far as I'm concerned,
> > we're ready for at least a release candidate. Sebb - any todos
> > outstanding?
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: 2.1 release
Posted by Peter Lin <wo...@gmail.com>.
I will finish writing the jms topic how-to and update the index number
this weekend.
peter
On 6/15/05, Michael Stover <ms...@apache.org> wrote:
> What needs doing before we can release 2.1? As far as I'm concerned,
> we're ready for at least a release candidate. Sebb - any todos
> outstanding?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org