I'll take a look and try to get that fixed by the weekend. peter
On 6/21/05, sebb <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > What else do we need to do for the 2.1 release :) > > > > peter > > > > > > On 6/15/05, Michael Stover <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > I will finish writing the jms topic how-to and update the index number > > > > > this weekend. > > > > > > > > > > > > > > > peter > > > > > > > > > > > > > > > On 6/15/05, Michael Stover <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
