Re: config httpclient.localaddress

[sebb]

On 2 December 2011 10:02, sbos-61  wrote:
> Hi, I'm in the same situation:
>
> I config httpclient.localaddress launchingJmeter, with no effect!
>
> bin\jmeter.sh -t .jmx -n -Jhttpclient.localaddress=1.3.4.1 -J
> jmeterengine.nongui.port=4848
>
> working on Windows 2008R2
>
> any suggestion?

Do not cross-post.
This is off-topic for the JMeter developer list.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] - Request to add a tutorial link to the wiki page

[sebb]

On 26 November 2011 20:08, Greg Roodt  wrote:
> Hi
>
> I would like to add a tutorial/how-to link to the JMeter wiki. I can add it
> myself if I am given permission to edit the page, or I can give the details

Create yourself a Wiki login and e-mail d...@jmeter.apache.org asking
to be added to the ContributorsGroup.

> to somebody else for inclusion on the wiki if everybody thinks it is ok.
>
> The tutorial/blog post I would like to link to can be found here:
> http://tech.mindcandy.com/2011/11/99-bottles-of-jmeter-on-the-wall/
>
> with code here:https://github.com/groodt/99bottles-jmeter
>
> Kind Regards
> Greg Roodt
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Issue 49463

[sebb]

Added new JMeter dev list - please use that in future.

On 8 November 2011 21:34, Philippe Mouawad  wrote:
> Hello Sebb,
> Did you have some time to look at these issues:
>
>   - 49463 : Is it really an issue or a feature ?

Not sure - the Counter is a config item, which is treated a bit differently.

The handling of cached function results is a bit tricky.
Changing the code might break lots of scripts.

I think we need some more test scripts that exercise functions in
combination with nested controllers etc.

>   - 43294 <https://issues.apache.org/bugzilla/show_bug.cgi?id=43294> : Do
>   you agree with proposition ? I wonder what would be the best to configure
>   namespace prefixes ? a dedicated new component to avoid having to repeat
>   declarations ?

I've updated the issue.

>
> Regards
> Philippe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] evolution request - handle BeanDescriptor.hidden flag in JMeter

[sebb]

2011/11/9 Stéphane Hoblingre :
> Thank you Sebb for your quick response!
>
> I know about not_in_menu configuration, but we would like to avoid JMeter
> users to edit propertie file from JMeter to install the plugins. So this is
> why we would like to do it from the plugin code itself. I did the
> modification in MenuFactory.java from trunk (r1199633), please find attached
> the patch / file.
>
> The modification is very light (in bold):
>
> if (name.endsWith("JMeterTreeNode") // $NON-NLS-1$
>     || name.endsWith("TestBeanGUI")) {// $NON-NLS-1$
>     continue;// Don't try to instantiate these
> }
>
>>//Handle BeanDescriptor hidden property
>>boolean isHiddenBean = false;
>
> JMeterGUIComponent item;
> try {
>     Class c = Class.forName(name);
>     if (TestBean.class.isAssignableFrom(c)) {
>     item = new TestBeanGUI(c);
>>    try {
>>   isHiddenBean =
>> Introspector.getBeanInfo(c).getBeanDescriptor().isHidden();
>>    } catch (IntrospectionException e) {
>>    log.warn("Cannot get bean info from class " + name + ".");
>>    }
>
>     } else {
>     item = (JMeterGUIComponent) c.newInstance();
>     }
> } catch (NoClassDefFoundError e) {
>     log.warn("Missing jar? Could not create " + name + ". " + e);
>     continue;
> } catch (Throwable e) {
>     log.warn("Could not instantiate " + name, e);
>     if (e instanceof Error){
>     throw (Error) e;
>     }
>     if (e instanceof RuntimeException){
>     throw (RuntimeException) e;
>     }
>     continue;
> }
>> if (elementsToSkip.contains(name) ||
>> elementsToSkip.contains(item.getStaticLabel()) || isHiddenBean) {
>     log.info("Skipping " + name);
>     continue;
> }
>
> Could this be added in the next version of JMeter?

If you provide a patch as a Bugzilla enhancement we will take a look.

> Thanks,
>
> Stef
>
> On Wed, Nov 9, 2011 at 12:06 AM, sebb  wrote:
>>
>> 2011/11/8 Stéphane Hoblingre :
>> > Dear JMeter dev team,
>> >
>> > I have an evolution request for JMeter which will help plugin
>> > developers.
>> > In our plugins, we implemented one component using TestBeans. We have
>> > now
>> > rewrote this component and use regular test elements, so we need to hide
>> > the previous one from jmeter add menus (backward jmx compatibility). The
>> > only way I found is very dirty, that is setting its name to null. But in
>>
>> You can also edit the JMeter property:
>>
>> not_in_menu
>>
>> see jmeter.properties.
>>
>> You might also be able to make use of upgrade.properties and dispense
>> with the old class altogether.
>>
>> > BeanDescriptor class, there is one attribute:
>> >
>> > isHidden
>> > public boolean isHidden()
>> >    The "hidden" flag is used to identify features that are intended only
>> > for tool use, and which should not be exposed to humans.
>> >
>> > While building the add component menu, could you check the hidden flag
>> > and
>> > if true not add it in the menu? That would allow to plugin developers to
>> > hide properly it.
>> >
>> > Is it possible? Do you want me to open a bug for it?
>>
>> If it can be done without affecting the existing API, then I suppose
>> it would be possible to interpret the isHidden() status as meaning
>> that the TestBean is not added to the display.
>>
>> If you provide a patch as a Bugzilla enhancement we will take a look.
>>
>> > Thanks,
>> >
>> > Stef
>> > JMeter Plugins - http://code.google.com/p/jmeter-plugins
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] evolution request - handle BeanDescriptor.hidden flag in JMeter

[sebb]

2011/11/8 Stéphane Hoblingre :
> Dear JMeter dev team,
>
> I have an evolution request for JMeter which will help plugin developers.
> In our plugins, we implemented one component using TestBeans. We have now
> rewrote this component and use regular test elements, so we need to hide
> the previous one from jmeter add menus (backward jmx compatibility). The
> only way I found is very dirty, that is setting its name to null. But in

You can also edit the JMeter property:

not_in_menu

see jmeter.properties.

You might also be able to make use of upgrade.properties and dispense
with the old class altogether.

> BeanDescriptor class, there is one attribute:
>
> isHidden
> public boolean isHidden()
>    The "hidden" flag is used to identify features that are intended only
> for tool use, and which should not be exposed to humans.
>
> While building the add component menu, could you check the hidden flag and
> if true not add it in the menu? That would allow to plugin developers to
> hide properly it.
>
> Is it possible? Do you want me to open a bug for it?

If it can be done without affecting the existing API, then I suppose
it would be possible to interpret the isHidden() status as meaning
that the TestBean is not added to the display.

If you provide a patch as a Bugzilla enhancement we will take a look.

> Thanks,
>
> Stef
> JMeter Plugins - http://code.google.com/p/jmeter-plugins

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

JMeter TLP changes

[sebb]

JMeter is in the process of becoming an independent Apache project,
rather than a sub-project of Jakarta.

SVN has already moved:
http://svn.apache.org/repos/asf/jakarta/jmeter/ =>
http://svn.apache.org/repos/asf/jmeter/

The Wiki has already moved:
http://wiki.apache.org/jakarta-jmeter/ => http://wiki.apache.org/jmeter/

The website will soon move:
http://jakarta.apache.org/jmeter/ => http://jmeter.apache.org/

Mailing lists are changing:

jmeter-u...@jakarta.apache.org has been renamed to u...@jmeter.apache.org
Existing subscribers are not affected.

There are 3 new mailing lists:
comm...@jmeter.apache.org (SVN mails)
d...@jmeter.apache.org (general developer mails, and Wiki updates)
iss...@jmeter.apache.org (Bugzilla)

It is not possible to rename the Jakarta mailing lists as they are
shared with other projects.
JMeter developers should subscribe to commits, dev, and issues.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMeter SVN move completed

[sebb]

On 1 November 2011 22:12, Philippe Mouawad  wrote:
> Hello Sebb,
> Congratulations for TLP.
>
> Is Jenkins build setup with this change ? Do nightly builds still get
> generated or we need to wait some time.

Yes, Jenkins should be OK.

Also, buildbot generates nightly builds at:

http://ci.apache.org/projects/jmeter/nightlies/index.html

> Regards
> Philippe
>
> On Tue, Nov 1, 2011 at 10:36 PM, sebb  wrote:
>
>> JMeter has been voted as a TLP, and is in the process of being reorganised.
>>
>> The JMeter SVN URLs have changed.
>>
>> http[s]://svn.apache.org/repos/asf/jakarta/jmeter/
>>
>> has become
>>
>> http[s]://svn.apache.org/repos/asf/jmeter/
>>
>>
>> So for example trunk has changed from
>> https://svn.apache.org/repos/asf/jakarta/jmeter/trunk
>> to
>> https://svn.apache.org/repos/asf//jmeter/trunk
>>
>> Developers need to change to the top-level of their working copy and
>> run the following commands:
>>
>> $ svn info
>> Path: .
>> URL: https://svn.apache.org/repos/asf/jakarta/jmeter/trunk
>>
>> For the above URL, use the folllowing command:
>>
>> svn switch https://svn.apache.org/repos/asf/jmeter/trunk/
>>
>> This will adjust all the repo references and you should be ready to go
>> again.
>>
>> Please ensure that you use the same scheme (https or perhaps http).
>>
>> Any problems, please ask here.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

JMeter SVN move completed

[sebb]

JMeter has been voted as a TLP, and is in the process of being reorganised.

The JMeter SVN URLs have changed.

http[s]://svn.apache.org/repos/asf/jakarta/jmeter/

has become

http[s]://svn.apache.org/repos/asf/jmeter/


So for example trunk has changed from
https://svn.apache.org/repos/asf/jakarta/jmeter/trunk
to
https://svn.apache.org/repos/asf//jmeter/trunk

Developers need to change to the top-level of their working copy and
run the following commands:

$ svn info
Path: .
URL: https://svn.apache.org/repos/asf/jakarta/jmeter/trunk

For the above URL, use the folllowing command:

svn switch https://svn.apache.org/repos/asf/jmeter/trunk/

This will adjust all the repo references and you should be ready to go again.

Please ensure that you use the same scheme (https or perhaps http).

Any problems, please ask here.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

** JMeter SVN move about to start **

[sebb]

Please don't use JMeter SVN for the next 10 minutes or so.

I will advise when the move has been completed.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

JMeter SVN move

[sebb]

In 10 minutes (at 21:20 GMT) I propose to move JMeter SVN from Jakarta
to the new top-level directory.

Please refrain from checking in any code until further notice.

I will send another e-mail when the move has been completed (should
only take a few minutes) with details of how to access the new URLs.

Thanks!

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: ISSUE 52033

[sebb]

On 1 November 2011 19:32, Philippe Mouawad  wrote:
> Hello Sebb,
> I implemented a KeystorePreloader component that can be added to Test Plan
> (it implements TestBean).
> This way, no additionnal jmeter.properties property and preloading only
> occurs when you explicitely add component to TestPlan.
>
> Do you agree with it ? can I commit it ? or do you find it too heavy for
> this ?

This seems like a good idea, though I think I would just call it KeystoreConfig

Perhaps it could also be used to define the
KEY_STORE_START_INDEX/KEY_STORE_END_INDEX values - easier to use than
the properties.

> Thank
> Regards
> Philippe
>
> On Tue, Nov 1, 2011 at 4:49 PM,  wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52033
>>
>> --- Comment #14 from Julian Cesar  2011-11-01
>> 15:49:28 UTC ---
>> if you create a option to load key store on start jmeter would be perfect.
>> We would like a nightly builds for the final tests, when we have it?
>>
>> --
>> Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> --- You are receiving this mail because: ---
>> You are the assignee for the bug.
>>
>> -
>> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)

[sebb]

On 1 November 2011 14:46, Philippe Mouawad  wrote:
> Sorry about top post, I don't know how to change it .

You did change for this reply ...

> On Tue, Nov 1, 2011 at 3:41 PM, sebb  wrote:
>
>> Please don't top post; it's easier to follow the thread if it is in order.
>>
>> On 1 November 2011 14:34, Philippe Mouawad 
>> wrote:
>> > I wanted to add a property called keystore_eager_load=false (by default).
>>
>> That seems reasonable.
>>
>> But would it make sense to only load the keystore if it was requested,
>> e.g. via another property?
>>
>
> What do you mean ?

Rather than always load the keystore, we would only load it of the
property was present.

The method SSLManager.getKeyStore() already reads the System property
javax.net.ssl.keyStore.
However, the code defaults to loading the file user.home/.keystore
which may well be present on a user system.
We could just drop the default, in which case the user would need to
specify the system property.

This would be an incompatible change, but would affect very few people.

>>
>> Seems to me that the keystore is very rarely needed, or am I missing
>> something?
>>
>
> Yes it's true.
>
>>
>> > On Tue, Nov 1, 2011 at 3:32 PM, sebb  wrote:
>> >
>> >> On 1 November 2011 14:25, Philippe Mouawad 
>> >> wrote:
>> >> > Hello Sebb,
>> >> > Do you think JsseSSLManager should implement TestListener or is there
>> a
>> >> > better way to achieve this:
>> >> >
>> >> >   - Make JmeterKeyStore load Keystore at startup (in my proposition it
>> >> >   will load it at Test startup)
>> >> >
>> >>
>> >> The problem is that the keystore is only needed for some tests.
>> >> Ideally it should only be loaded when necessary.
>> >>
>> >>
>> >> > Thank you
>> >> > Regards
>> >> > Philippe
>> >> >
>> >> > On Tue, Nov 1, 2011 at 3:18 PM,  wrote:
>> >> >
>> >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=52033
>> >> >>
>> >> >> --- Comment #13 from Philippe Mouawad > >
>> >> >> 2011-11-01 14:18:19 UTC ---
>> >> >> Hello,
>> >> >> You can achieve the first by setting:
>> >> >> - HTTPClient 3.1 or 4 as implementation
>> >> >> - setting https.use.cached.ssl.context=false
>> >> >>
>> >> >>
>> >> >> For the second , we will make it an option.
>> >> >> Regards
>> >> >> Philippe
>> >> >>
>> >> >> --
>> >> >> Configure bugmail:
>> >> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> >> >> --- You are receiving this mail because: ---
>> >> >> You are the assignee for the bug.
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> >> >> For additional commands, e-mail:
>> notifications-h...@jakarta.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Cordialement.
>> >> > Philippe Mouawad.
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> >> For additional commands, e-mail: dev-h...@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)

[sebb]

Please don't top post; it's easier to follow the thread if it is in order.

On 1 November 2011 14:34, Philippe Mouawad  wrote:
> I wanted to add a property called keystore_eager_load=false (by default).

That seems reasonable.

But would it make sense to only load the keystore if it was requested,
e.g. via another property?

Seems to me that the keystore is very rarely needed, or am I missing something?

> On Tue, Nov 1, 2011 at 3:32 PM, sebb  wrote:
>
>> On 1 November 2011 14:25, Philippe Mouawad 
>> wrote:
>> > Hello Sebb,
>> > Do you think JsseSSLManager should implement TestListener or is there a
>> > better way to achieve this:
>> >
>> >   - Make JmeterKeyStore load Keystore at startup (in my proposition it
>> >   will load it at Test startup)
>> >
>>
>> The problem is that the keystore is only needed for some tests.
>> Ideally it should only be loaded when necessary.
>>
>>
>> > Thank you
>> > Regards
>> > Philippe
>> >
>> > On Tue, Nov 1, 2011 at 3:18 PM,  wrote:
>> >
>> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=52033
>> >>
>> >> --- Comment #13 from Philippe Mouawad 
>> >> 2011-11-01 14:18:19 UTC ---
>> >> Hello,
>> >> You can achieve the first by setting:
>> >> - HTTPClient 3.1 or 4 as implementation
>> >> - setting https.use.cached.ssl.context=false
>> >>
>> >>
>> >> For the second , we will make it an option.
>> >> Regards
>> >> Philippe
>> >>
>> >> --
>> >> Configure bugmail:
>> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> >> --- You are receiving this mail because: ---
>> >> You are the assignee for the bug.
>> >>
>> >> -
>> >> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> >> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)

[sebb]

On 1 November 2011 14:25, Philippe Mouawad  wrote:
> Hello Sebb,
> Do you think JsseSSLManager should implement TestListener or is there a
> better way to achieve this:
>
>   - Make JmeterKeyStore load Keystore at startup (in my proposition it
>   will load it at Test startup)
>

The problem is that the keystore is only needed for some tests.
Ideally it should only be loaded when necessary.


> Thank you
> Regards
> Philippe
>
> On Tue, Nov 1, 2011 at 3:18 PM,  wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52033
>>
>> --- Comment #13 from Philippe Mouawad 
>> 2011-11-01 14:18:19 UTC ---
>> Hello,
>> You can achieve the first by setting:
>> - HTTPClient 3.1 or 4 as implementation
>> - setting https.use.cached.ssl.context=false
>>
>>
>> For the second , we will make it an option.
>> Regards
>> Philippe
>>
>> --
>> Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> --- You are receiving this mail because: ---
>> You are the assignee for the bug.
>>
>> -
>> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Start Next Loop fix

[sebb]

On 31 October 2011 10:59, Philippe Mouawad  wrote:
> Hello Sebb, All,
> I commited the fix to this feature implementing your proposal.
> My tests show it fixes the 3 issues:
>
>   - 51865
>   - 51866
>   - 51868
>
> The think I dislike about it is the cast to LoopController in ThreadGroup
> (but I think it is OK).

Probably.

> As code is a bit complex it would be great if you could also test on you
> side with all your knowledge of JMeter usages and internals.

Looks OK, but I have not examined it in detail.

> I don't think regressions can be introduced because it is only when Start
> Next loop is used that changes do their job.
> So regression would be on an already broken feature.

Agreed.

> I didn't mark issues as fixed yet nor did I change the comment in
> changes.xml:
> "Start next Loop option in Thread Group is broken, see Bugs (51868, 51866,
> 51865)"

Might be worth changing the bugs to "NEEDINFO" and asking the
originators if the nightly builds have fixed the problems.

> --
> Regards.
> Philippe.
>
>
>
>
>
> On Tue, Oct 25, 2011 at 6:24 PM, sebb  wrote:
>
>> On 25 October 2011 17:14, Philippe Mouawad
>>  wrote:
>> > Hello Sebb,
>> > I am looking at how to fix issues with "Start Next Loop".
>> > Is there a way to get parent controller from child ? I don't see how ?
>>
>> Sorry, don't know offhand.
>>
>> > Would it be through a call to testTree.traverse and a SearchClass
>> Controller
>> > ? but we would also take into account controller that are down the
>> > hierarchy.
>>
>> No idea - this part of JMeter is very complicated and not particularly
>> well documented; I never fully got my head around it.
>>
>> The first stage might be to improve the Javadocs ...
>>
>> > Regards
>> > Philippe
>> >
>> >
>> >
>> > On Wed, Oct 5, 2011 at 6:06 PM,  wrote:
>> >
>> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51866
>> >>
>> >> --- Comment #8 from Sebb  2011-10-05 16:06:50 UTC ---
>> >> (In reply to comment #7)
>> >> > If I put JMeterContextService.getContext().isWithinRestartNextLoop()
>> test
>> >> > in fireIterEvents() instead,
>> >> > do you see a case where it could fail ?
>> >>
>> >> Yes, if fireIterationStart() is called directly.
>> >> But adding it to both won't necessarily help either, as that only fixes
>> the
>> >> issue with iteration listeners.
>> >>
>> >> But as I pointed out in Comment 3, it's not just the counter that
>> >> misbehaves;
>> >> the counter problem is just one symptom.
>> >>
>> >> I think the whole "Start next loop" code needs rewriting.
>> >>
>> >> Effectively the option means "go to end of loop" for each controller up
>> to
>> >> the
>> >> Thread Group. [At least I assume this is the intention, as the option
>> only
>> >> appears on the Thread Group controller.]
>> >>
>> >> So we need to code the feature as if this has happened, and then
>> everything
>> >> else should happen naturally.
>> >>
>> >> --
>> >> Configure bugmail:
>> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> >> --- You are receiving this mail because: ---
>> >> You voted for the bug.
>> >> You are on the CC list for the bug.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> > Ubik-Ingénierie
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 51866] [PATCH] Counter under loop doesn't work properly if "Start next loop on error" option set for thread group

[sebb]

On 25 October 2011 17:14, Philippe Mouawad
 wrote:
> Hello Sebb,
> I am looking at how to fix issues with "Start Next Loop".
> Is there a way to get parent controller from child ? I don't see how ?

Sorry, don't know offhand.

> Would it be through a call to testTree.traverse and a SearchClass Controller
> ? but we would also take into account controller that are down the
> hierarchy.

No idea - this part of JMeter is very complicated and not particularly
well documented; I never fully got my head around it.

The first stage might be to improve the Javadocs ...

> Regards
> Philippe
>
>
>
> On Wed, Oct 5, 2011 at 6:06 PM,  wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51866
>>
>> --- Comment #8 from Sebb  2011-10-05 16:06:50 UTC ---
>> (In reply to comment #7)
>> > If I put JMeterContextService.getContext().isWithinRestartNextLoop() test
>> > in fireIterEvents() instead,
>> > do you see a case where it could fail ?
>>
>> Yes, if fireIterationStart() is called directly.
>> But adding it to both won't necessarily help either, as that only fixes the
>> issue with iteration listeners.
>>
>> But as I pointed out in Comment 3, it's not just the counter that
>> misbehaves;
>> the counter problem is just one symptom.
>>
>> I think the whole "Start next loop" code needs rewriting.
>>
>> Effectively the option means "go to end of loop" for each controller up to
>> the
>> Thread Group. [At least I assume this is the intention, as the option only
>> appears on the Thread Group controller.]
>>
>> So we need to code the feature as if this has happened, and then everything
>> else should happen naturally.
>>
>> --
>> Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> --- You are receiving this mail because: ---
>> You voted for the bug.
>> You are on the CC list for the bug.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Toolbar suggested changes

[sebb]

The icons look really good, and should make JMeter easier to use.

But I think the code could be improved further:

1) IconToolbarBean uses ";" to separate most icon fields, but uses " "
to separate the optional pressed icon.

I think it might be clearer to use a single separator for all the
fields; it would also simplify the code slightly.

The toolbar property uses "," as a separator, whereas the icons use ";".

Might be better to use "," throughout - it's very slightly easier to
see the gaps between comma-separated items, compare:

a,b,c,d
a;b;c;d

WDYT?

2) JMeterToolBar.getIconMappings() supports overriding the toolbar
properties file.

However, if the user provides a property file, as far as I can tell
they have to provide all the icon definitions as well as the toolbar
layout.

That is a lot of work if all the user wants to do is to override the
toolbar order.

I think the code should load the default set, and then load any
customisation file.

Alternatively (or perhaps in addition), the user should be able to
provide the toolbar list as a separate JMeter property - i.e. they
could add it to user.properties.

Thoughts?

3) Just noticed something else: JMeterToolBar uses a LinkedHashMap to
collect the icon details.
AFAICT this prevents the user from duplicating any icons - I think it
would be better to just use a plain List and allow the user to
duplicate icons if they want.

==

I'm happy to do the changes once agreed.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1187840 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/core/org/apache/jmeter/util/keystore/ xdocs/

[sebb]

On 23 October 2011 12:34, Philippe Mouawad  wrote:
> Kind of getNextAlias method in DefaultKeyStore ?

Yes, or just getAlias() as we had originally.

>
> On Sun, Oct 23, 2011 at 1:23 PM, sebb  wrote:
>
>> On 23 October 2011 12:05, Philippe Mouawad 
>> wrote:
>> > But In this case , alias will run in the same order for different callers
>> > during the test no ?
>>
>> I had assumed that as the parent is a singleton, the nested class
>> would be a singleton too, but I see now that is not correct.
>>
>> This needs futher investigation.
>>
>> It somehow feels wrong to have the code in this class - maybe it would
>> be better in JmeterKeyStore/DefaultKeyStore?
>> After all, that is where the aliases are held.
>>
>> WDYT?
>>
>> > While currently as field is static there is more randomizing .
>> >
>> > On Sun, Oct 23, 2011 at 1:01 PM, sebb  wrote:
>> >
>> >> On 23 October 2011 11:53, Philippe Mouawad 
>> >> wrote:
>> >> > I looked in a bit more detail,
>> >> > static is needed
>> >>
>> >> Not if one moves the field to the WrappedX509KeyManager class, which
>> >> is what I will do.
>> >>
>> >> > I think AtomicInteger won't do it because we need to increment and %
>> >> > aliasCount in the same time, don't know if we can do that  so maybe
>> just
>> >> a
>> >> > custom lock for this static field would do it.
>> >>
>> >> > On Sun, Oct 23, 2011 at 12:49 PM, sebb  wrote:
>> >> >
>> >> >> On 23 October 2011 11:38, Philippe Mouawad <
>> philippe.moua...@gmail.com>
>> >> >> wrote:
>> >> >> > Hello,
>> >> >> > Regarding this last commit,  I think there is an issue in last_user
>> >> >> either
>> >> >> > being static or being synchronized on this.
>> >> >> >
>> >> >> > In my opinion, as it seems JsseSSLManager is a singleton, last_user
>> >> >> should
>> >> >> > be instance variable.
>> >> >> > If it's not the case, then synchronized block in getNextIndex
>> should
>> >> be
>> >> >> on
>> >> >> > JsseSSLManager.class or field should use AtomicInteger .
>> >> >>
>> >> >> Good catch indeed!
>> >> >>
>> >> >> I originally was going to use AtomicInteger, but would still have had
>> >> >> to protect the wrap-around code.
>> >> >>
>> >> >> I'll fix it shortly.
>> >> >>
>> >> >> > Regards
>> >> >> > Philippe
>> >> >> >
>> >> >> > On Sun, Oct 23, 2011 at 3:50 AM,  wrote:
>> >> >> >
>> >> >> >> Author: sebb
>> >> >> >> Date: Sun Oct 23 01:50:55 2011
>> >> >> >> New Revision: 1187840
>> >> >> >>
>> >> >> >> URL: http://svn.apache.org/viewvc?rev=1187840&view=rev
>> >> >> >> Log:
>> >> >> >> Bug 52033 - Allowing multiple certificates (JKS)
>> >> >> >>
>> >> >> >> Modified:
>> >> >> >>    jakarta/jmeter/trunk/bin/jmeter.properties
>> >> >> >>
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> >> >> >>
>> >>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/SSLManager.java
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/DefaultKeyStore.java
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/JmeterKeyStore.java
>> >> >> >>    jakarta/jmeter/trunk/xdocs/changes.xml
>> >> >> >>
>> >> >> >> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
>> >> >> >> URL:
>> >> >> >>
>> >> >>
>> >>
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1187840&r1=1187839&r2=1187840&

Re: Question about our use of HttpClient

[sebb]

On 23 October 2011 12:19, Philippe Mouawad  wrote:
> Hello,
> I was wondering why we chose in the different implementations of Samplers
> using HttpClient 3 and 4 to use an instance per Thread in ThreadLocal zone
> instead of using :
>
>   - ThreadSafeClientConnManager for HC4
>   - MultiThreadedHttpConnectionManager for HC3.1 (see
>   
> http://pro-programmers.blogspot.com/2009/06/apache-httpclient-multi-threads.html
>   )
>
> It is just a question not a change proposition (It works fine for me as it
> is implemented now)

The intention is to ensure that JMeter threads behave like independent
users - no sharing of connections.

If JMeter were to share a connection manager between threads, then I
think that would no longer be the case.

However, we might perhaps need to use those connection managers to
sort out the parallel download issues.

Note that this is one of the problems with the Java HTTP
implementation - there is no control over connection re-use.

> --
> Regards
> Philippe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1187840 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/core/org/apache/jmeter/util/keystore/ xdocs/

[sebb]

On 23 October 2011 12:05, Philippe Mouawad  wrote:
> But In this case , alias will run in the same order for different callers
> during the test no ?

I had assumed that as the parent is a singleton, the nested class
would be a singleton too, but I see now that is not correct.

This needs futher investigation.

It somehow feels wrong to have the code in this class - maybe it would
be better in JmeterKeyStore/DefaultKeyStore?
After all, that is where the aliases are held.

WDYT?

> While currently as field is static there is more randomizing .
>
> On Sun, Oct 23, 2011 at 1:01 PM, sebb  wrote:
>
>> On 23 October 2011 11:53, Philippe Mouawad 
>> wrote:
>> > I looked in a bit more detail,
>> > static is needed
>>
>> Not if one moves the field to the WrappedX509KeyManager class, which
>> is what I will do.
>>
>> > I think AtomicInteger won't do it because we need to increment and %
>> > aliasCount in the same time, don't know if we can do that  so maybe just
>> a
>> > custom lock for this static field would do it.
>>
>> > On Sun, Oct 23, 2011 at 12:49 PM, sebb  wrote:
>> >
>> >> On 23 October 2011 11:38, Philippe Mouawad 
>> >> wrote:
>> >> > Hello,
>> >> > Regarding this last commit,  I think there is an issue in last_user
>> >> either
>> >> > being static or being synchronized on this.
>> >> >
>> >> > In my opinion, as it seems JsseSSLManager is a singleton, last_user
>> >> should
>> >> > be instance variable.
>> >> > If it's not the case, then synchronized block in getNextIndex should
>> be
>> >> on
>> >> > JsseSSLManager.class or field should use AtomicInteger .
>> >>
>> >> Good catch indeed!
>> >>
>> >> I originally was going to use AtomicInteger, but would still have had
>> >> to protect the wrap-around code.
>> >>
>> >> I'll fix it shortly.
>> >>
>> >> > Regards
>> >> > Philippe
>> >> >
>> >> > On Sun, Oct 23, 2011 at 3:50 AM,  wrote:
>> >> >
>> >> >> Author: sebb
>> >> >> Date: Sun Oct 23 01:50:55 2011
>> >> >> New Revision: 1187840
>> >> >>
>> >> >> URL: http://svn.apache.org/viewvc?rev=1187840&view=rev
>> >> >> Log:
>> >> >> Bug 52033 - Allowing multiple certificates (JKS)
>> >> >>
>> >> >> Modified:
>> >> >>    jakarta/jmeter/trunk/bin/jmeter.properties
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> >> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/SSLManager.java
>> >> >>
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/DefaultKeyStore.java
>> >> >>
>> >> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/JmeterKeyStore.java
>> >> >>    jakarta/jmeter/trunk/xdocs/changes.xml
>> >> >>
>> >> >> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
>> >> >> URL:
>> >> >>
>> >>
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1187840&r1=1187839&r2=1187840&view=diff
>> >> >>
>> >> >>
>> >>
>> ==
>> >> >> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
>> >> >> +++ jakarta/jmeter/trunk/bin/jmeter.properties Sun Oct 23 01:50:55
>> 2011
>> >> >> @@ -78,6 +78,11 @@ xml.parser=org.apache.xerces.parsers.SAX
>> >> >>  # set the value to 'false' to reset the SSL context each iteration
>> >> >>  #https.use.cached.ssl.context=true
>> >> >>
>> >> >> +# Start and end index to be used with keystores with many entries
>> >> >> +# The default is to use entry 0, i.e. the first
>> >> >> +#https.keyStoreStartIndex=0
>> >> >> +#https.keyStoreEndIndex=0
>> >> >> +
>> >> >>
>> >> >>
>> >>
>>  #---
>> >> >>  # Look and Feel config

Re: svn commit: r1187840 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/core/org/apache/jmeter/util/keystore/ xdocs/

[sebb]

On 23 October 2011 11:53, Philippe Mouawad  wrote:
> I looked in a bit more detail,
> static is needed

Not if one moves the field to the WrappedX509KeyManager class, which
is what I will do.

> I think AtomicInteger won't do it because we need to increment and %
> aliasCount in the same time, don't know if we can do that  so maybe just a
> custom lock for this static field would do it.

> On Sun, Oct 23, 2011 at 12:49 PM, sebb  wrote:
>
>> On 23 October 2011 11:38, Philippe Mouawad 
>> wrote:
>> > Hello,
>> > Regarding this last commit,  I think there is an issue in last_user
>> either
>> > being static or being synchronized on this.
>> >
>> > In my opinion, as it seems JsseSSLManager is a singleton, last_user
>> should
>> > be instance variable.
>> > If it's not the case, then synchronized block in getNextIndex should be
>> on
>> > JsseSSLManager.class or field should use AtomicInteger .
>>
>> Good catch indeed!
>>
>> I originally was going to use AtomicInteger, but would still have had
>> to protect the wrap-around code.
>>
>> I'll fix it shortly.
>>
>> > Regards
>> > Philippe
>> >
>> > On Sun, Oct 23, 2011 at 3:50 AM,  wrote:
>> >
>> >> Author: sebb
>> >> Date: Sun Oct 23 01:50:55 2011
>> >> New Revision: 1187840
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1187840&view=rev
>> >> Log:
>> >> Bug 52033 - Allowing multiple certificates (JKS)
>> >>
>> >> Modified:
>> >>    jakarta/jmeter/trunk/bin/jmeter.properties
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> >>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/SSLManager.java
>> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/DefaultKeyStore.java
>> >>
>> >>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/JmeterKeyStore.java
>> >>    jakarta/jmeter/trunk/xdocs/changes.xml
>> >>
>> >> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
>> >> URL:
>> >>
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1187840&r1=1187839&r2=1187840&view=diff
>> >>
>> >>
>> ==
>> >> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
>> >> +++ jakarta/jmeter/trunk/bin/jmeter.properties Sun Oct 23 01:50:55 2011
>> >> @@ -78,6 +78,11 @@ xml.parser=org.apache.xerces.parsers.SAX
>> >>  # set the value to 'false' to reset the SSL context each iteration
>> >>  #https.use.cached.ssl.context=true
>> >>
>> >> +# Start and end index to be used with keystores with many entries
>> >> +# The default is to use entry 0, i.e. the first
>> >> +#https.keyStoreStartIndex=0
>> >> +#https.keyStoreEndIndex=0
>> >> +
>> >>
>> >>
>>  #---
>> >>  # Look and Feel configuration
>> >>
>> >>
>>  #---
>> >>
>> >> Modified:
>> >> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> >> URL:
>> >>
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java?rev=1187840&r1=1187839&r2=1187840&view=diff
>> >>
>> >>
>> ==
>> >> ---
>> >> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> >> (original)
>> >> +++
>> >> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> Sun
>> >> Oct 23 01:50:55 2011
>> >> @@ -70,6 +70,9 @@ public class JsseSSLManager extends SSLM
>> >>
>> >>     private static final int cps;
>> >>
>> >> +    //@GuardedBy("this")
>> >> +    private static int  last_user;
>> >> +
>> >>     static {
>> >>         log.info("Using default SSL protocol: "+DEFAULT_SSL_PROTOCOL);
>> >>         log.info("SSL session context: "+(SHARED_SESSION_CONTEXT ?
>&

Re: svn commit: r1187840 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/core/org/apache/jmeter/util/keystore/ xdocs/

[sebb]

On 23 October 2011 11:38, Philippe Mouawad  wrote:
> Hello,
> Regarding this last commit,  I think there is an issue in last_user either
> being static or being synchronized on this.
>
> In my opinion, as it seems JsseSSLManager is a singleton, last_user should
> be instance variable.
> If it's not the case, then synchronized block in getNextIndex should be on
> JsseSSLManager.class or field should use AtomicInteger .

Good catch indeed!

I originally was going to use AtomicInteger, but would still have had
to protect the wrap-around code.

I'll fix it shortly.

> Regards
> Philippe
>
> On Sun, Oct 23, 2011 at 3:50 AM,  wrote:
>
>> Author: sebb
>> Date: Sun Oct 23 01:50:55 2011
>> New Revision: 1187840
>>
>> URL: http://svn.apache.org/viewvc?rev=1187840&view=rev
>> Log:
>> Bug 52033 - Allowing multiple certificates (JKS)
>>
>> Modified:
>>    jakarta/jmeter/trunk/bin/jmeter.properties
>>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/SSLManager.java
>>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/DefaultKeyStore.java
>>
>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/keystore/JmeterKeyStore.java
>>    jakarta/jmeter/trunk/xdocs/changes.xml
>>
>> Modified: jakarta/jmeter/trunk/bin/jmeter.properties
>> URL:
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1187840&r1=1187839&r2=1187840&view=diff
>>
>> ==
>> --- jakarta/jmeter/trunk/bin/jmeter.properties (original)
>> +++ jakarta/jmeter/trunk/bin/jmeter.properties Sun Oct 23 01:50:55 2011
>> @@ -78,6 +78,11 @@ xml.parser=org.apache.xerces.parsers.SAX
>>  # set the value to 'false' to reset the SSL context each iteration
>>  #https.use.cached.ssl.context=true
>>
>> +# Start and end index to be used with keystores with many entries
>> +# The default is to use entry 0, i.e. the first
>> +#https.keyStoreStartIndex=0
>> +#https.keyStoreEndIndex=0
>> +
>>
>>  #---
>>  # Look and Feel configuration
>>
>>  #---
>>
>> Modified:
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> URL:
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java?rev=1187840&r1=1187839&r2=1187840&view=diff
>>
>> ==
>> ---
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java
>> (original)
>> +++
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JsseSSLManager.java Sun
>> Oct 23 01:50:55 2011
>> @@ -70,6 +70,9 @@ public class JsseSSLManager extends SSLM
>>
>>     private static final int cps;
>>
>> +    //@GuardedBy("this")
>> +    private static int  last_user;
>> +
>>     static {
>>         log.info("Using default SSL protocol: "+DEFAULT_SSL_PROTOCOL);
>>         log.info("SSL session context: "+(SHARED_SESSION_CONTEXT ?
>> "shared" : "per-thread"));
>> @@ -314,8 +317,12 @@ public class JsseSSLManager extends SSLM
>>          */
>>         public String[] getClientAliases(String keyType, Principal[]
>> issuers) {
>>             log.debug("WrappedX509Manager: getClientAliases: ");
>> -            log.debug(this.store.getAlias());
>> -            return new String[] { this.store.getAlias() };
>> +            int count = this.store.getAliasCount();
>> +            String[] aliases = new String[count];
>> +            for(int i = 0; i < aliases.length; i++) {
>> +                aliases[i] = this.store.getAlias(i);
>> +            }
>> +             return aliases;
>>         }
>>
>>         /**
>> @@ -343,7 +350,7 @@ public class JsseSSLManager extends SSLM
>>          */
>>         public X509Certificate[] getCertificateChain(String alias) {
>>             log.debug("WrappedX509Manager: getCertificateChain(" + alias +
>> ")");
>> -            return this.store.getCertificateChain();
>> +            return this.store.getCertificateChain(alias);
>>         }
>>
>>         /**
>> @@ -354,8 +361,9 @@ public class JsseSSLManager extends SSLM
>>      

Re: CacheManager OOM risk

[sebb]

On 20 October 2011 11:17, Philippe Mouawad  wrote:
> Hello,
> I am doing some tests on an application that uses GET requests with a
> parameter nocache generated for each request.
> This application generates this request every second.
>
> So I simulated this and ran an endurance test.
>
> I noticed JMeter memory increased during the test.
> I made a Heap Dump and saw that CacheManager was overwhelmed by this
> request.
>
> There is of course an issue with WebServer config that should add Expires
> Header but I think we sould protect JMeter from this by limiting size on
> Cachemanager HashMap,
> as it is the case for a real browser that has a limited memory size for
> cache.
>
> Should I open an issue regarding this ?

Please.

> Thanks.
> Regards
> Philippe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Issue 51861

[sebb]

On 20 October 2011 11:18, Philippe Mouawad  wrote:
> Hello Sebb,
> Did you have some time to review patch for issue 51861 ? If yes Are you OK
> if I commit it ?

I had a look, and I think it is better, but I suspect that there are
still some edge cases that may cause issues.

As there are no immediate plans for a new release, I think it is OK
this time round to commit the code and then fix any issues that arise.

Nightly builds don't have to maintain compatibility, so if the
implementation needs to be changed we can do so.

Probably sensible to put a note in the docs that the feature is still
under development; we can remove that before the next release if we
are happy all the issues have been resolved.

> In fact I am doing some load tests on GWT and it is really difficult to work
> without it.
>
> Hope you have some time to take it into account.
>
> Regards
> Philippe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Issue 52044

[sebb]

On 18 October 2011 22:21, sebb  wrote:
> On 18 October 2011 19:50, Philippe Mouawad
>  wrote:
>> Hello Sebb, Milamber , All,
>> I investigated this issue, particularly this part of issue
>>
>>> stramge error for "JMS Subscriber - 001" - Response message:
>>> javax.naming.NamingException: Something already bound at 
>>> Elite_To_MorphoTrak;
>>
>> I created a simple test case and tried not to cache Context and it works
>> fine.
>> and in fact it is due to the fact that we cache Context and use it by many
>> threads.
>> From this:
>> http://download.oracle.com/javase/jndi/tutorial/beyond/misc/sync.html
>>
>> I conclude we should not do caching as it is not mandatory that context is
>> Thread Safe (and it's not the case for AMQ one).
>>
>> Do you remember why Context were cached ? was it because of bad performances
>> if not cached ?
>
> I think that was before my time.
>
>> There are 2 solutions for that:
>>
>>   - We remove caching
>>   - We add an  option in GUI to let user select if Context will be cached
>>   or not
>
> Or we cache per thread, e.g. using ThreadLocal.

I've just realised there is a reason why the Context was being cached.

The Context holds execution context, so needs to be maintained between
samplers in the same thread.

One easy way to fix the context sharing across threads would be to
include the thread name in the context key.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1185853 - in /jakarta/jmeter/trunk: src/protocol/jms/org/apache/jmeter/protocol/jms/ src/protocol/jms/org/apache/jmeter/protocol/jms/client/ src/protocol/jms/org/apache/jmeter/protoco

[sebb]

On 18 October 2011 21:58,   wrote:
> Author: pmouawad
> Date: Tue Oct 18 20:58:08 2011
> New Revision: 1185853
>
> URL: http://svn.apache.org/viewvc?rev=1185853&view=rev
> Log:
> Bug 52044 - JMS Subscriber used with many threads leads to 
> javax.naming.NamingException: Something already bound with ActiveMQ
>
> Performances impact of No Caching of InitialContext are low.

-1

I now think this is the wrong solution, and could have a negative impact.

Please revert these changes; we need to discuss further on the dev list.

> Modified:
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/Utils.java
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/InitialContextFactory.java
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/Publisher.java
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/ReceiveSubscriber.java
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/sampler/PublisherSampler.java
>    
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/sampler/SubscriberSampler.java
>    jakarta/jmeter/trunk/xdocs/changes.xml
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/Utils.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/Utils.java?rev=1185853&r1=1185852&r2=1185853&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/Utils.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/Utils.java
>  Tue Oct 18 20:58:08 2011
> @@ -39,6 +39,21 @@ import org.apache.log.Logger;
>  */
>  public final class Utils {
>
> +    /**
> +     * Close context
> +     * @param closeable {@link Context}
> +     * @param log {@link Logger}
> +     */
> +    public static void close(Context closeable, Logger log) {
> +        if (closeable != null){
> +            try {
> +                closeable.close();
> +            } catch (Exception e) {
> +                log.error("Error during close: ", e);
> +            }
> +        }
> +    }
> +
>     public static void close(MessageConsumer closeable, Logger log){
>         if (closeable != null){
>             try {
> @@ -162,5 +177,4 @@ public final class Utils {
>         }
>         throw new NamingException("Expected javax.jms.ConnectionFactory, 
> found "+objfac.getClass().getName());
>     }
> -
>  }
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/InitialContextFactory.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/InitialContextFactory.java?rev=1185853&r1=1185852&r2=1185853&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/InitialContextFactory.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/client/InitialContextFactory.java
>  Tue Oct 18 20:58:08 2011
> @@ -48,7 +48,9 @@ public class InitialContextFactory {
>      * @param securityCredentials used to set the property {@link 
> Context#SECURITY_CREDENTIALS}
>      * @return the context, never null
>      * @throws NamingException
> +     * @{@link Deprecated}  No more caching of {@link Context}s
>      */
> +    @Deprecated
>     public static Context lookupContext(String initialContextFactory,
>             String providerUrl, boolean useAuth, String securityPrincipal, 
> String securityCredentials) throws NamingException {
>         String cacheKey = createKey(initialContextFactory ,providerUrl, 
> securityPrincipal, securityCredentials);
> @@ -88,13 +90,47 @@ public class InitialContextFactory {
>     }
>
>     /**
> +     * Create context
> +     *
> +     * @param initialContextFactory used to set the property {@link 
> Context#INITIAL_CONTEXT_FACTORY}
> +     * @param providerUrl used to set the property {@link 
> Context#PROVIDER_URL}
> +     * @param useAuth set true if security is to be used.
> +     * @param securityPrincipal used to set the property {@link 
> Context#SECURITY_PRINCIPAL}
> +     * @param securityCredentials used to set the property {@link 
> Context#SECURITY_CREDENTIALS}
> +     * @return the context, never null
> +     * @throws NamingException
> +     */
> +    private static Context lookupContextNoCache(String initialContextFactory,
> +            String providerUrl, boolean useAuth, String securityPrincipal, 
> String securityCredentials) throws NamingException {
> +        Properties props = new Properties();
> +        props.setProperty(Context.INITIAL_CONTEXT_FACTORY, 
> initialContextFactory);
> +        props.setProperty(Context.PROVIDER_URL, providerUrl);
> +        if (useAuth && s

Re: Issue 52044

[sebb]

On 18 October 2011 19:50, Philippe Mouawad
 wrote:
> Hello Sebb, Milamber , All,
> I investigated this issue, particularly this part of issue
>
>> stramge error for "JMS Subscriber - 001" - Response message:
>> javax.naming.NamingException: Something already bound at Elite_To_MorphoTrak;
>
> I created a simple test case and tried not to cache Context and it works
> fine.
> and in fact it is due to the fact that we cache Context and use it by many
> threads.
> From this:
> http://download.oracle.com/javase/jndi/tutorial/beyond/misc/sync.html
>
> I conclude we should not do caching as it is not mandatory that context is
> Thread Safe (and it's not the case for AMQ one).
>
> Do you remember why Context were cached ? was it because of bad performances
> if not cached ?

I think that was before my time.

> There are 2 solutions for that:
>
>   - We remove caching
>   - We add an  option in GUI to let user select if Context will be cached
>   or not

Or we cache per thread, e.g. using ThreadLocal.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Seemingly incorrect short-circuiting logic

[sebb]

Wrong mailing list?

This is Jakarta, not Jackrabbit ...

On 17 October 2011 00:44, Dave Brosius  wrote:
> Greetings,
>
> org.apache.jackrabbit.webdav.security.report.AclPrincipalReport.java
>
> does the following
>
> This logic seems wrong to me
>
> *if (href == null && respMap.containsKey(href)) {*
>
>
> i'd expect it should be ||
>
> correct?
>
>
>  @Override
>    public void init(DavResource resource, ReportInfo info) throws
> DavException {
>        super.init(resource, info);
>        // build the DAV:responses objects.
>        DavProperty acl = resource.getProperty(SecurityConstants.ACL);
>        if (!(acl instanceof AclProperty)) {
>            throw new
> DavException(DavServletResponse.SC_INTERNAL_SERVER_ERROR, "DAV:acl property
> expected.");
>        }
>
>        DavResourceLocator loc = resource.getLocator();
>        Map respMap = new HashMap MultiStatusResponse>();
>        List list = (List)
> ((AclProperty)acl).getValue();
>        for (AclProperty.Ace ace : list) {
>            String href = ace.getPrincipal().getHref();
> *if (href == null && respMap.containsKey(href)) {*
>                // ignore non-href principals and principals that have been
> listed before
>                continue;
>            }
>            // href-principal that has not been found before
>            DavResourceLocator princLocator =
> loc.getFactory().createResourceLocator(loc.getPrefix(), href);
>            DavResource principalResource =
> resource.getFactory().createResource(princLocator, resource.getSession());
>            respMap.put(href, new MultiStatusResponse(principalResource,
> info.getPropertyNameSet()));
>        }
>        this.responses = respMap.values().toArray(new
> MultiStatusResponse[respMap.size()]);
>    }
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Apache JMeter TLP

[sebb]

On 13 October 2011 19:04, Rahul Akolkar  wrote:
> [This vote is being held on dev@jakarta, please reply there. This
> message is being sent to multiple lists to make sure most at Jakarta
> are informed.]
>
> This is a vote for proposing an Apache JMeter TLP resolution to the
> board, with sebb nominated as the first Chair. The full text appears
> below [1] and is also on the wiki [2]. Vote will remain open for
> atleast 72 hours.
>
> 8<
> [ X ] +1, its time for an Apache JMeter TLP
> [  ] +/- 0
> [  ] -1, because ...
> 8<
>
> Cheers,
> -Rahul
>
> [1] Establish the Apache JMeter Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software related to a Java desktop
> application designed to load test functional behavior and
> measure performance, for distribution at no charge to the
> public.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache JMeter Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache JMeter Project be and hereby is
> responsible for the creation and maintenance of software
> that provides a Java desktop application designed to load
> test functional behavior and measure performance; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache JMeter" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache JMeter Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache JMeter Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache JMeter Project:
>
>  * Sebastian Bazley (sebb AT a.o)
>  * Milamber (milamber AT a.o)
>  * Peter Lin (woolfel AT a.o)
>  * Henri Yandell (bayard AT a.o)
>  * Rahul Akolkar (rahul AT a.o)
>  * Oleg Kalnichevski (olegk AT a.o)
>  * Rainer Jung (rjung AT a.o)
>  * Philippe Mouawad (pmouawad AT a.o)
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sebastian Bazley
> be appointed to the office of Vice President, Apache JMeter, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the initial Apache JMeter PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache JMeter Project; and be it further
>
> RESOLVED, that the Apache JMeter Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Jakarta JMeter sub-project; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Jakarta JMeter sub-project encumbered upon the Apache Jakarta
> Project are hereafter discharged.
>
>
> [2] http://wiki.apache.org/jakarta/TLPJMeter (version 7 of wiki page)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1183065 - in /jakarta/jmeter/trunk: src/core/org/apache/jmeter/engine/ src/core/org/apache/jmeter/gui/action/ src/core/org/apache/jmeter/gui/util/ src/core/org/apache/jmeter/resources

[sebb]

On 13 October 2011 21:44, Philippe Mouawad  wrote:
> I changed implementation a little.

That's much clearer.
However the method private final void addLast(Object node) is no
longer needed and could be inlined.

Sorry, I was confused by the addLast(); thought it was adding to the
new tree, rather than keeping track of the current one.

> Added @Override (as I didn't see it in other classes, didn't add it)

OK

> About negative condition, Start should generally be called more frequently
> that the new option so put it first.

There is only one condition check.

Surely the following have the same performance.

Positive:

if (node instanceof Timer) {
   return node;
} else {
  return super.addNodeToTree(node);
}

Negative:

if (!(node instanceof Timer)) {
  return super.addNodeToTree(node);
} else {
  return node;
}

I agree where there are multiple conditions, best to check the
cheapest first, but here there is only one check.

It's important for code to be readable.

> Regards
> Philippe
>
> On Thu, Oct 13, 2011 at 10:29 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 13, 2011 at 10:26 PM, sebb  wrote:
>>
>>> On 13 October 2011 21:12,   wrote:
>>> > Author: pmouawad
>>> > Date: Thu Oct 13 20:12:23 2011
>>> > New Revision: 1183065
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1183065&view=rev
>>> > Log:
>>> > Bug 52019 - Add menu option to Start a test ignoring Pause Timers
>>> >
>>> > Added:
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java
>>>   (with props)
>>> > Modified:
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/action/ActionNames.java
>>> >    jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/action/Start.java
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/JMeterMenuBar.java
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_es.properties
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>>> >
>>>  jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_pt_BR.properties
>>> >    jakarta/jmeter/trunk/xdocs/changes.xml
>>> >
>>> > Modified:
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java
>>> > URL:
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java?rev=1183065&r1=1183064&r2=1183065&view=diff
>>> >
>>> ==
>>> > ---
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java
>>> (original)
>>> > +++
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java Thu
>>> Oct 13 20:12:23 2011
>>> > @@ -56,7 +56,6 @@ public class TreeCloner implements HashT
>>> >     }
>>> >
>>> >     public void addNode(Object node, HashTree subTree) {
>>> > -
>>> >         if ( (node instanceof TestElement) // Check can cast for clone
>>> >            // Don't clone NoThreadClone unless honourNoThreadClone ==
>>> false
>>> >           && (!honourNoThreadClone || !(node instanceof NoThreadClone))
>>> > @@ -66,6 +65,14 @@ public class TreeCloner implements HashT
>>> >         } else {
>>> >             newTree.add(objects, node);
>>> >         }
>>> > +        addLast(node);
>>> > +    }
>>> > +
>>> > +    /**
>>> > +     * add node to objects LinkedList
>>> > +     * @param node Object
>>> > +     */
>>> > +    protected final void addLast(Object node) {
>>> >         objects.addLast(node);
>>> >     }
>>>
>>> OK, so subclasses can override this to skip adding a node.
>>>
>>> >
>>> > Added:
>>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java
>>> > URL:
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java?rev=1183065&view=auto
>>> >
>>> 

Re: svn commit: r1183065 - in /jakarta/jmeter/trunk: src/core/org/apache/jmeter/engine/ src/core/org/apache/jmeter/gui/action/ src/core/org/apache/jmeter/gui/util/ src/core/org/apache/jmeter/resources

[sebb]

On 13 October 2011 21:12,   wrote:
> Author: pmouawad
> Date: Thu Oct 13 20:12:23 2011
> New Revision: 1183065
>
> URL: http://svn.apache.org/viewvc?rev=1183065&view=rev
> Log:
> Bug 52019 - Add menu option to Start a test ignoring Pause Timers
>
> Added:
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java 
>   (with props)
> Modified:
>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java
>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/action/ActionNames.java
>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/action/Start.java
>    jakarta/jmeter/trunk/src/core/org/apache/jmeter/gui/util/JMeterMenuBar.java
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_es.properties
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
>    
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_pt_BR.properties
>    jakarta/jmeter/trunk/xdocs/changes.xml
>
> Modified: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java?rev=1183065&r1=1183064&r2=1183065&view=diff
> ==
> --- jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java 
> (original)
> +++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeCloner.java 
> Thu Oct 13 20:12:23 2011
> @@ -56,7 +56,6 @@ public class TreeCloner implements HashT
>     }
>
>     public void addNode(Object node, HashTree subTree) {
> -
>         if ( (node instanceof TestElement) // Check can cast for clone
>            // Don't clone NoThreadClone unless honourNoThreadClone == false
>           && (!honourNoThreadClone || !(node instanceof NoThreadClone))
> @@ -66,6 +65,14 @@ public class TreeCloner implements HashT
>         } else {
>             newTree.add(objects, node);
>         }
> +        addLast(node);
> +    }
> +
> +    /**
> +     * add node to objects LinkedList
> +     * @param node Object
> +     */
> +    protected final void addLast(Object node) {
>         objects.addLast(node);
>     }

OK, so subclasses can override this to skip adding a node.

>
> Added: 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java?rev=1183065&view=auto
> ==
> --- 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java 
> (added)
> +++ 
> jakarta/jmeter/trunk/src/core/org/apache/jmeter/engine/TreeClonerNoTimer.java 
> Thu Oct 13 20:12:23 2011
> @@ -0,0 +1,59 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *   http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + *
> + */
> +
> +package org.apache.jmeter.engine;
> +
> +import org.apache.jmeter.timers.Timer;
> +import org.apache.jorphan.collections.HashTree;
> +import org.apache.jorphan.logging.LoggingManager;
> +import org.apache.log.Logger;
> +
> +/**
> + * Clones the test tree,  skipping test elements that implement {@link 
> Timer} by default.
> + */
> +public class TreeClonerNoTimer extends TreeCloner{
> +    private Logger logger = LoggingManager.getLoggerForClass();
> +
> +    /**
> +     * {@inheritDoc}
> +     */
> +    public TreeClonerNoTimer() {
> +        super();
> +    }
> +
> +    /**
> +     * {@inheritDoc}
> +     */
> +    public TreeClonerNoTimer(boolean honourNoThreadClone) {
> +        super(honourNoThreadClone);
> +    }
> +
> +    /**
> +     * {@inheritDoc}
> +     */

@Override?

> +    public void addNode(Object node, HashTree subTree) {
> +        if(!(node instanceof Timer)) {

It's confusing to use negative conditions

> +            super.addNode(node, subTree);
> +        } else {
> +            if(logger.isDebugEnabled()) {
> +                logger.debug("Ignoring timer node:"+ node);
> +            }
> +            addLast(node);

This looks wrong, surely you don't want to add the nod

Re: DO NOT REPLY [Bug 52019] Add menu option to enable/disable timers when running Plan

[sebb]

On 13 October 2011 18:34, Philippe Mouawad
 wrote:
> Hello Sebb,
> Do you agree with this proposition :
>
>   - Add an Menu Option called "Run with timers disabled"

I see - so it would only apply to GUI runs - that's reasonable.

>   - This option will set a boolean on GuiPackage#getinstance() called
>   noTimersPause
>   - Timers will consult this option to decide whether to run or not pause

That would require changing all timers; what happens about 3rd party timers?
See below for simpler option.

>   - At end of run option will be reset (what would be the best way to
>   detect end, StandardJMeterEngine#run after waitThreadsStopped ?)
>

The GUI Start code has to clone and traverse the tree before passing
it to the engine, so it could remove the Timers there.
Disabled elements are removed anyway, so it could alternatively
disable them if that was easier.

Perhaps create a subclass of TreeCloner that skips Timers.

No need to reset the option afterwards.

> If you are Ok, I can implement it.
>
> Regards
> Philippe
>
> On Thu, Oct 13, 2011 at 1:09 PM, Philippe Mouawad <
> p.moua...@ubik-ingenierie.com> wrote:
>
>> Hello Sebb,
>> In my opinion this option would be useful only in Scripting Phase so
>> through GUI.
>> That's why I wanted it as a Menu Option or maybe "Run with timers disabled"
>> .
>>
>> My implementation idea was to test in parent delay() method a check for
>> this option and return immediately if it is on.
>>
>> This would make it simple to implement and would not be persisted in Test
>> Plan nor disabling of Timers would occur.
>> What do you think ?
>>
>> Regards
>> Philippe
>>
>>
>> On Thu, Oct 13, 2011 at 12:59 PM,  wrote:
>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52019
>>>
>>> --- Comment #1 from Sebb  2011-10-13 10:59:33 UTC ---
>>> Rather than a Menu item, perhaps it should be a Test Plan option, which
>>> would
>>> mean checking for it in the engine code. But I think it would be simpler
>>> overall.
>>>
>>> If done via a Menu option, disabling is easy.
>>>
>>> However, I assume there would be a re-enable option - what about timers
>>> that
>>> were originally disabled? Seems wrong to enable those, so the code would
>>> have
>>> to keep track of which Timers did not need re-enabling.
>>>
>>> What if the Test Plan were updated in the mean-time? How could one keep
>>> track
>>> of which Timers to re-enable?
>>>
>>> Using a Test Plan option would mean it would also work in non-GUI and
>>> client-server mode.
>>>
>>> --
>>> Configure bugmail:
>>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>>> --- You are receiving this mail because: ---
>>> You reported the bug.
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>> Ubik-Ingénierie
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Patch 52001

[sebb]

On 13 October 2011 18:47, Philippe Mouawad  wrote:
> I agree with you.

By the way, please don't top-post; it's harder to follow the thread
when it appears in reverse order.

> Do we close the issue or we wait for other opinions ?

We can wait a while, and then close it.

> Thanks
> Regards
> Philippe
>
> On Thu, Oct 13, 2011 at 7:45 PM, sebb  wrote:
>
>> On 13 October 2011 18:28, Philippe Mouawad  wrote:
>> > Hello Sebb,
>> > Do you think we should  implement issue
>> > 52001<https://issues.apache.org/bugzilla/show_bug.cgi?id=52001>
>> > :
>> >
>> >   - Add scroll automatically to Summary Report
>> >
>> > The only use case I see is when you label sampler with a variable name,
>> > otherwise you may scroll but it won't last after some time number of
>> lines
>> > will stay the same.
>>
>> Yes, it's only needed in limited circumstances, which is why I don't
>> really see the need for it.
>>
>> > If you give me the go, I will patch it.
>>
>> It's not my personal decision; we make decisions by consensus.
>> Any committer can veto a change on a technical basis (e.g. it would
>> break something else) but that is probably not the case here.
>>
>> If it were me, I would not apply the patch as I cannot see the point;
>> more code to test and maintain with little benefit.
>>
>> So I don't support the patch, but if you feel it would be useful I
>> won't veto it.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Patch 52001

[sebb]

On 13 October 2011 18:28, Philippe Mouawad  wrote:
> Hello Sebb,
> Do you think we should  implement issue
> 52001<https://issues.apache.org/bugzilla/show_bug.cgi?id=52001>
> :
>
>   - Add scroll automatically to Summary Report
>
> The only use case I see is when you label sampler with a variable name,
> otherwise you may scroll but it won't last after some time number of lines
> will stay the same.

Yes, it's only needed in limited circumstances, which is why I don't
really see the need for it.

> If you give me the go, I will patch it.

It's not my personal decision; we make decisions by consensus.
Any committer can veto a change on a technical basis (e.g. it would
break something else) but that is probably not the case here.

If it were me, I would not apply the patch as I cannot see the point;
more code to test and maintain with little benefit.

So I don't support the patch, but if you feel it would be useful I
won't veto it.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1182664 - /jakarta/jmeter/trunk/eclipse.classpath

[sebb]

Good catch!

On 13 October 2011 06:39,   wrote:
> Author: pmouawad
> Date: Thu Oct 13 05:39:35 2011
> New Revision: 1182664
>
> URL: http://svn.apache.org/viewvc?rev=1182664&view=rev
> Log:
> Bug 52016 - It would be useful to support Jexl2
>
> Add jar to eclipse.classpath
>
> Modified:
>    jakarta/jmeter/trunk/eclipse.classpath
>
> Modified: jakarta/jmeter/trunk/eclipse.classpath
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/eclipse.classpath?rev=1182664&r1=1182663&r2=1182664&view=diff
> ==
> --- jakarta/jmeter/trunk/eclipse.classpath (original)
> +++ jakarta/jmeter/trunk/eclipse.classpath Thu Oct 13 05:39:35 2011
> @@ -50,6 +50,7 @@
>        
>        
>        
> +       
>        
>        
>        
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 52013] View Results Tree does not take into account proxy excluded URLs

[sebb]

On 12 October 2011 13:37, Philippe Mouawad  wrote:
> Hello Sebb,
> I am recording a scenario for scripting.
> I configure a proxy server with some exluded URLs and put a Results Tree
> View under it to see samples request/results of recording (need them to
> variabilize).
>
> When I record, URLs are correctly filtered in Recording Controller but not
> in results Tree view (which I think is a feature now).

OK, I understand now.

> My issue is that in this application, we have a Polling URL that goes to
> server every 1s so I get hundreds of these URLs in Results Tree which I
> would like to remove in this case because they make it more complexe to find
> the good samples.
>
> Is it clearer ?

Yes.

Not sure how easy this would be to do, though.

> Regards
> Philippe
>
> On Wed, Oct 12, 2011 at 2:15 PM,  wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52013
>>
>> --- Comment #1 from Sebb  2011-10-12 12:15:12 UTC ---
>> No idea what View results tree has to do with proxy excluded URLs.
>>
>> Please discuss this on the mailing list first, and then update or resolve
>> this
>> issue.
>>
>> --
>> Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> --- You are receiving this mail because: ---
>> You reported the bug.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)

[sebb]

On 9 October 2011 10:41, Philippe Mouawad  wrote:
> Hello Sebb,
> Regarding this, if we add a checkbox in Request Sampler GUI to indicate to
> user that merge will occur on request.
> This would be checked by default unless user switches to RAW body, if switch
> is accepted, checkbox is unchecked
>
> So we would have this behaviour:
>
>   - RAW body used, no merge
>   - Post Parameter , merge occurs
>
>
> What's your opinion, do you see other issues ?

I'm not sure I want to see yet another checkbox on that screen.
Seems to me we should try to use the raw body flag to control the behaviour.

So if the raw flag is set, we don't do a merge; otherwise keep current
behaviour.

I think we should probably disable the raw option entirely for Http
Defaults, otherwise I think it will be treated as an unnamed parameter
and merged with any non-raw samplers. That would be quite confusing.

Another possibility would be to use a separate JMX attribute for the
raw body (default omitted if empty).
This would make switching easier, as the panes would not share storage areas.

Also need to look at whether the samplers can share common code for
generating the request body.
We need to look at that whether or not we use a separate JMX
atttribute, because that is where any merging is done currently.

The samples currently use
HTTPSamplerBase.getSendParameterValuesAsPostBody() to check if the
request body is being generated from param values.

Perhaps the first stage should be to try to extract all the common
code that builds the body and move that into the parent class.

> Thanks
>
> Regards
> Philippe
>
> On Wed, Sep 28, 2011 at 4:52 PM, sebb  wrote:
>
>> If HttpDefaults and HttpRequest both use Parameters, then the body is
>> created from both sets of parameters.
>>
>> When the body is being built, if any of the parameters have names,
>> only named parameters are kept.
>> Any unnamed parameters are ignored.
>> It's not possible to mix named and unnamed parameters; named
>> parameters take precedence.
>>
>> If both test elements have unnamed variables only, then the body is
>> created from the merging of the two sets of values.
>>
>> That is existing behaviour, and cannot be changed without potentially
>> affecting users.
>>
>> Now the raw body option is currently handled as an un-named parameter.
>> This means that the a Raw HTTP Request will be ignored if there is a
>> named default parameter, and unnamed default parameters will be
>> appended to the body.
>>
>> That does not seem right; I would expect the raw option to provide the
>> complete body.
>>
>> This will mean a change to the way defaults are handled.
>>
>> I think this needs more discussion.
>>
>> It could take a while to resolve the issues and debug the code, so I
>> think it will have to wait for a later version of JMeter; I've held up
>> the current one long enough!
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Issue 51876

[sebb]

On 10 October 2011 21:45, Philippe Mouawad  wrote:
> Hello All,
> Did you have some time to look at issue
> 51876?
>
> I am doing some scripting these days and I find it useful but It's just my
> opinion and it can be impacting.
> If you think it is, is it possible to include it like this and then enhance
> feature or must we implement it
> on all sampler before including it ?
>

No need to implement for all samplers initially.

Let's see how it works out in the initial implementation.

> Thank you
> Regards
> Philippe
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 9 October 2011 10:50, Philippe Mouawad  wrote:
> Hello Sebb,
> Regarding the cloning of a Sampler you mention in you mail "Unfortunately,
> cloning the sampler is not easy.",
> could you give more explanations on why it is not easy to clone the sampler
> ?

It's easy to call clone on the sampler.
However, the fields are not all simple objects; it's not clear if
nested objects in collections etc  will clone properly.

However, it's worth a try to see it it works, because it would be the
simplest solution to the mutable fields.

Still need to check things like http connections to make sure they are
being used correctly and cleared when the new thread exits.

The JMeter design allows samplers to rely on events such as
TestStarted etc. These won't automatically be generated for the
mini-threads used for concurrent downloads.

Or perhaps we could take the concurrent download setting into account
when creating the initial httpclient instances (i.e. make it part of
the key) so we can generate enough pool entries. The mini-threads
would then use the parent pool, and the parent can be responsible for
tidying up at end of run.

But then, what about connection close? Would that need to be delayed
until subsamples had completed?

As I wrote earlier, the JMeter design is predicated on single-threaded
samplers, so changes here need careful consideration.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1180004 - in /jakarta/jmeter/trunk: src/components/org/apache/jmeter/config/CSVDataSet.java xdocs/changes.xml

[sebb]

On 7 October 2011 13:01, sebb  wrote:
> On 7 October 2011 12:51, sebb  wrote:
>> On 7 October 2011 12:10,   wrote:
>>> Author: pmouawad
>>> Date: Fri Oct  7 11:10:18 2011
>>> New Revision: 1180004
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1180004&view=rev
>>> Log:
>>> Bug 51988 - CSV Data Set Configuration does not resolve default delimiter 
>>> for header parsing when variables field is empty
>>>
>>> Modified:
>>>    
>>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>>>    jakarta/jmeter/trunk/xdocs/changes.xml
>>>
>>> Modified: 
>>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>>> URL: 
>>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java?rev=1180004&r1=1180003&r2=1180004&view=diff
>>> ==
>>> --- 
>>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>>>  (original)
>>> +++ 
>>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>>>  Fri Oct  7 11:10:18 2011
>>> @@ -100,74 +100,74 @@ public class CSVDataSet extends ConfigTe
>>>     public void iterationStart(LoopIterationEvent iterEvent) {
>>>         FileServer server = FileServer.getFileServer();
>>>         final JMeterContext context = getThreadContext();
>>> +        String delim = getDelimiter();
>>> +        if (delim.startsWith("\\t")) { // $NON-NLS-1$
>>
>> This is a change from the previous code, which uses .equals().
>> I don't think startsWith() is suitable here.
>>
>>> +            delim = "\t";// Make it easier to enter a Tab // $NON-NLS-1$
>>> +        } else if (delim.length() == 0) {
>>> +            log.warn("Empty delimiter converted to ','");
>>> +            delim = ",";
>>> +        }
>>>         if (vars == null) {
>>>             String _fileName = getFilename();
>>>             String mode = getShareMode();
>>>             int modeInt = CSVDataSetBeanInfo.getShareModeAsInt(mode);
>>> -            switch(modeInt){
>>> -                case CSVDataSetBeanInfo.SHARE_ALL:
>>> -                    alias = _fileName;
>>> -                    break;
>>> -                case CSVDataSetBeanInfo.SHARE_GROUP:
>>> -                    alias = 
>>> _fileName+"@"+System.identityHashCode(context.getThreadGroup());
>>> -                    break;
>>> -                case CSVDataSetBeanInfo.SHARE_THREAD:
>>> -                    alias = 
>>> _fileName+"@"+System.identityHashCode(context.getThread());
>>> -                    break;
>>> -                default:
>>> -                    alias = _fileName+"@"+mode; // user-specified key
>>> -                    break;
>>> +            switch (modeInt) {
>>> +            case CSVDataSetBeanInfo.SHARE_ALL:
>>> +                alias = _fileName;
>>> +                break;
>>> +            case CSVDataSetBeanInfo.SHARE_GROUP:
>>> +                alias = _fileName + "@" + 
>>> System.identityHashCode(context.getThreadGroup());
>>> +                break;
>>> +            case CSVDataSetBeanInfo.SHARE_THREAD:
>>> +                alias = _fileName + "@" + 
>>> System.identityHashCode(context.getThread());
>>> +                break;
>>> +            default:
>>> +                alias = _fileName + "@" + mode; // user-specified key
>>> +                break;
>>>             }
>>>             final String names = getVariableNames();
>>> -            if (names == null || names.length()==0) {
>>> +            if (names == null || names.length() == 0) {
>
> Also, please don't change formatting when fixing bugs, unless directly
> related - e.g. adding surrounding try/catch or if statement.
>
> It makes it much harder to see what has actually changed.

I now see that the additional changes were in the original patch.

If a submiited patch includes unnecessary changes, we have a choice:
- either we reject it, and ask the submitter to provide a new patch
- or we apply it, but not the spurious changes.
This is reasonably easy to do in Eclipse, but can be tedious.
Apply the patch, then do a compare against the base re

Re: svn commit: r1179989 - /jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml

[sebb]

On 7 October 2011 11:38,   wrote:
> Author: pmouawad
> Date: Fri Oct  7 10:38:56 2011
> New Revision: 1179989
>
> URL: http://svn.apache.org/viewvc?rev=1179989&view=rev
> Log:
> Last fix to tests failures after renaming HTMLParserTestFile_2.htm to 
> HTMLParserTestFile_2.html

> -Fixed path
> -Fixed by attributes (but maybe platform dependent, on my computer file is 
> 1282 so Ok for me, was it an issue in XML ?)

Problem is that the input files are flagged as native, so have
different EOLs on different systems.

Also, XML output files are always LF; I forgot to fix that.

I'll fix these issues.

> Modified:
>    jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml
>
> Modified: jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml?rev=1179989&r1=1179988&r2=1179989&view=diff
> ==
> --- jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml (original)
> +++ jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml Fri Oct  7 
> 10:38:56 2011
> @@ -1,16 +1,16 @@
>  
>  
>  
> -   rm="OK" tn="Thread Group 1-1" dt="text" de="" by="40174" sc="1" ec="0" ng="0" 
> na="0">
> +   rc="200" rm="OK" tn="Thread Group 1-1" dt="text" de="" by="40174" sc="1" 
> ec="0" ng="0" na="0">
>     
>     
>     
>     
>     GET
>     
> -    file:testfiles/HTMLParserTestFile_2.htm
> +    file:testfiles/HTMLParserTestFile_2.html
>   
> -   lb="file:testfiles/HTMLParserTestFile_2_files/style.css" rc="200" rm="OK" 
> tn="Thread Group 1-1" dt="text" de="" by="1321" sc="1" ec="0" ng="0" na="0">
> +   lb="file:testfiles/HTMLParserTestFile_2_files/style.css" rc="200" rm="OK" 
> tn="Thread Group 1-1" dt="text" de="" by="1282" sc="1" ec="0" ng="0" na="0">
>     
>     
>     
> @@ -106,7 +106,7 @@
>   
>   GET
>   
> -  file:testfiles/HTMLParserTestFile_2.htm
> +  file:testfiles/HTMLParserTestFile_2.html
>  
>
>  
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1180004 - in /jakarta/jmeter/trunk: src/components/org/apache/jmeter/config/CSVDataSet.java xdocs/changes.xml

[sebb]

On 7 October 2011 12:51, sebb  wrote:
> On 7 October 2011 12:10,   wrote:
>> Author: pmouawad
>> Date: Fri Oct  7 11:10:18 2011
>> New Revision: 1180004
>>
>> URL: http://svn.apache.org/viewvc?rev=1180004&view=rev
>> Log:
>> Bug 51988 - CSV Data Set Configuration does not resolve default delimiter 
>> for header parsing when variables field is empty
>>
>> Modified:
>>    
>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>>    jakarta/jmeter/trunk/xdocs/changes.xml
>>
>> Modified: 
>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java?rev=1180004&r1=1180003&r2=1180004&view=diff
>> ==
>> --- 
>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java 
>> (original)
>> +++ 
>> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java 
>> Fri Oct  7 11:10:18 2011
>> @@ -100,74 +100,74 @@ public class CSVDataSet extends ConfigTe
>>     public void iterationStart(LoopIterationEvent iterEvent) {
>>         FileServer server = FileServer.getFileServer();
>>         final JMeterContext context = getThreadContext();
>> +        String delim = getDelimiter();
>> +        if (delim.startsWith("\\t")) { // $NON-NLS-1$
>
> This is a change from the previous code, which uses .equals().
> I don't think startsWith() is suitable here.
>
>> +            delim = "\t";// Make it easier to enter a Tab // $NON-NLS-1$
>> +        } else if (delim.length() == 0) {
>> +            log.warn("Empty delimiter converted to ','");
>> +            delim = ",";
>> +        }
>>         if (vars == null) {
>>             String _fileName = getFilename();
>>             String mode = getShareMode();
>>             int modeInt = CSVDataSetBeanInfo.getShareModeAsInt(mode);
>> -            switch(modeInt){
>> -                case CSVDataSetBeanInfo.SHARE_ALL:
>> -                    alias = _fileName;
>> -                    break;
>> -                case CSVDataSetBeanInfo.SHARE_GROUP:
>> -                    alias = 
>> _fileName+"@"+System.identityHashCode(context.getThreadGroup());
>> -                    break;
>> -                case CSVDataSetBeanInfo.SHARE_THREAD:
>> -                    alias = 
>> _fileName+"@"+System.identityHashCode(context.getThread());
>> -                    break;
>> -                default:
>> -                    alias = _fileName+"@"+mode; // user-specified key
>> -                    break;
>> +            switch (modeInt) {
>> +            case CSVDataSetBeanInfo.SHARE_ALL:
>> +                alias = _fileName;
>> +                break;
>> +            case CSVDataSetBeanInfo.SHARE_GROUP:
>> +                alias = _fileName + "@" + 
>> System.identityHashCode(context.getThreadGroup());
>> +                break;
>> +            case CSVDataSetBeanInfo.SHARE_THREAD:
>> +                alias = _fileName + "@" + 
>> System.identityHashCode(context.getThread());
>> +                break;
>> +            default:
>> +                alias = _fileName + "@" + mode; // user-specified key
>> +                break;
>>             }
>>             final String names = getVariableNames();
>> -            if (names == null || names.length()==0) {
>> +            if (names == null || names.length() == 0) {

Also, please don't change formatting when fixing bugs, unless directly
related - e.g. adding surrounding try/catch or if statement.

It makes it much harder to see what has actually changed.

>>                 String header = server.reserveFile(_fileName, 
>> getFileEncoding(), alias, true);
>>                 try {
>> -                    vars = CSVSaveService.csvSplitString(header, 
>> getDelimiter().charAt(0));
>> +                    vars = CSVSaveService.csvSplitString(header, 
>> delim.charAt(0));
>>                     firstLineIsNames = true;
>>                 } catch (IOException e) {
>> -                    log.warn("Could not split CSV header line",e);
>> +                    log.warn("Could not split CSV header line", e);
>>                 }
>>             } else {
>>                 server.reserveFile(_fileName

Re: svn commit: r1179979 - in /jakarta/jmeter/trunk: bin/testfiles/HTMLParserTestFile_2.htm bin/testfiles/HTMLParserTestFile_2.html test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java

[sebb]

On 7 October 2011 10:27,   wrote:
> Author: pmouawad
> Date: Fri Oct  7 09:27:54 2011
> New Revision: 1179979
>
> URL: http://svn.apache.org/viewvc?rev=1179979&view=rev
> Log:
> Fixed errors in TestCase (6 test failures):
> - Error in baseURL for relative file names (testfiles not needed I think)

Not sure about that - needs further invetigation.

> - FileInputStream not closed

OK

> - Renamed  HTMLParserTestFile_2.htm to HTMLParserTestFile_2.html

I think that was the wrong fix, as you discovered later when the batch
test failed.
But not work reverting now.

> Added:
>    jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.html
>      - copied unchanged from r1179973, 
> jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.htm
> Removed:
>    jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.htm
> Modified:
>    
> jakarta/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java
>
> Modified: 
> jakarta/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java?rev=1179979&r1=1179978&r2=1179979&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/test/src/org/apache/jmeter/protocol/http/parser/TestHTMLParser.java
>  Fri Oct  7 09:27:54 2011
> @@ -22,6 +22,7 @@ import java.io.BufferedReader;
>  import java.io.File;
>  import java.io.FileInputStream;
>  import java.io.FileReader;
> +import java.io.InputStream;
>  import java.net.URL;
>  import java.util.ArrayList;
>  import java.util.Collection;
> @@ -32,12 +33,14 @@ import java.util.Properties;
>  import java.util.TreeSet;
>  import java.util.Vector;
>
> +import org.apache.commons.io.IOUtils;
>  import org.apache.jmeter.junit.JMeterTestCase;
>  import org.apache.jmeter.util.JMeterUtils;
>  import org.apache.jorphan.logging.LoggingManager;
>  import org.apache.log.Logger;
>
>  import junit.framework.TestSuite;
> +import junit.textui.TestRunner;
>
>  public class TestHTMLParser extends JMeterTestCase {
>     private static final Logger log = LoggingManager.getLoggerForClass();
> @@ -135,7 +138,7 @@ public class TestHTMLParser extends JMet
>                         "testfiles/HTMLParserTestFrames.all"),
>                 // Relative filenames
>                 new TestData("testfiles/HTMLParserTestFile_2.html",
> -                        "file:testfiles/HTMLParserTestFile_2.html",
> +                        "file:HTMLParserTestFile_2.html",
>                         "testfiles/HTMLParserTestFile_2.all",
>                         "testfiles/HTMLParserTestFile_2.all"),
>                          };
> @@ -252,8 +255,14 @@ public class TestHTMLParser extends JMet
>             log.debug("file   " + file);
>             File f = findTestFile(file);
>             byte[] buffer = new byte[(int) f.length()];
> -            int len = new FileInputStream(f).read(buffer);
> -            assertEquals(len, buffer.length);
> +            InputStream is = null;
> +            try {
> +                is = new FileInputStream(f);
> +                int len = is.read(buffer);
> +                assertEquals(len, buffer.length);
> +            } finally {
> +                IOUtils.closeQuietly(is);
> +            }
>             Iterator result;
>             if (c == null) {
>                 result = p.getEmbeddedResourceURLs(buffer, new URL(url));
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1180004 - in /jakarta/jmeter/trunk: src/components/org/apache/jmeter/config/CSVDataSet.java xdocs/changes.xml

[sebb]

On 7 October 2011 12:10,   wrote:
> Author: pmouawad
> Date: Fri Oct  7 11:10:18 2011
> New Revision: 1180004
>
> URL: http://svn.apache.org/viewvc?rev=1180004&view=rev
> Log:
> Bug 51988 - CSV Data Set Configuration does not resolve default delimiter for 
> header parsing when variables field is empty
>
> Modified:
>    
> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
>    jakarta/jmeter/trunk/xdocs/changes.xml
>
> Modified: 
> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java?rev=1180004&r1=1180003&r2=1180004&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java 
> (original)
> +++ 
> jakarta/jmeter/trunk/src/components/org/apache/jmeter/config/CSVDataSet.java 
> Fri Oct  7 11:10:18 2011
> @@ -100,74 +100,74 @@ public class CSVDataSet extends ConfigTe
>     public void iterationStart(LoopIterationEvent iterEvent) {
>         FileServer server = FileServer.getFileServer();
>         final JMeterContext context = getThreadContext();
> +        String delim = getDelimiter();
> +        if (delim.startsWith("\\t")) { // $NON-NLS-1$

This is a change from the previous code, which uses .equals().
I don't think startsWith() is suitable here.

> +            delim = "\t";// Make it easier to enter a Tab // $NON-NLS-1$
> +        } else if (delim.length() == 0) {
> +            log.warn("Empty delimiter converted to ','");
> +            delim = ",";
> +        }
>         if (vars == null) {
>             String _fileName = getFilename();
>             String mode = getShareMode();
>             int modeInt = CSVDataSetBeanInfo.getShareModeAsInt(mode);
> -            switch(modeInt){
> -                case CSVDataSetBeanInfo.SHARE_ALL:
> -                    alias = _fileName;
> -                    break;
> -                case CSVDataSetBeanInfo.SHARE_GROUP:
> -                    alias = 
> _fileName+"@"+System.identityHashCode(context.getThreadGroup());
> -                    break;
> -                case CSVDataSetBeanInfo.SHARE_THREAD:
> -                    alias = 
> _fileName+"@"+System.identityHashCode(context.getThread());
> -                    break;
> -                default:
> -                    alias = _fileName+"@"+mode; // user-specified key
> -                    break;
> +            switch (modeInt) {
> +            case CSVDataSetBeanInfo.SHARE_ALL:
> +                alias = _fileName;
> +                break;
> +            case CSVDataSetBeanInfo.SHARE_GROUP:
> +                alias = _fileName + "@" + 
> System.identityHashCode(context.getThreadGroup());
> +                break;
> +            case CSVDataSetBeanInfo.SHARE_THREAD:
> +                alias = _fileName + "@" + 
> System.identityHashCode(context.getThread());
> +                break;
> +            default:
> +                alias = _fileName + "@" + mode; // user-specified key
> +                break;
>             }
>             final String names = getVariableNames();
> -            if (names == null || names.length()==0) {
> +            if (names == null || names.length() == 0) {
>                 String header = server.reserveFile(_fileName, 
> getFileEncoding(), alias, true);
>                 try {
> -                    vars = CSVSaveService.csvSplitString(header, 
> getDelimiter().charAt(0));
> +                    vars = CSVSaveService.csvSplitString(header, 
> delim.charAt(0));
>                     firstLineIsNames = true;
>                 } catch (IOException e) {
> -                    log.warn("Could not split CSV header line",e);
> +                    log.warn("Could not split CSV header line", e);
>                 }
>             } else {
>                 server.reserveFile(_fileName, getFileEncoding(), alias);
>                 vars = JOrphanUtils.split(names, ","); // $NON-NLS-1$
>             }
>         }
> -            String delim = getDelimiter();
> -            if (delim.equals("\\t")) { // $NON-NLS-1$
> -                delim = "\t";// Make it easier to enter a Tab // $NON-NLS-1$
> -            } else if (delim.length()==0){
> -                log.warn("Empty delimiter converted to ','");
> -                delim=",";
> -            }
> -            // TODO: fetch this once as per vars above?
> -            JMeterVariables threadVars = context.getVariables();
> -            String line = null;
> +        // TODO: fetch this once as per vars above?
> +        JMeterVariables threadVars = context.getVariables();
> +        String line = null;
> +        try {
> +            line = server.readLine(alias, getRecycle(), firstLineIsNames);
> +        } catch (IOException e) { // treat the same as EOF
> +            log.error(e.toString());
> +        }
> +        if (line != null) {// i.e. not 

Re: Error In JMS-Subscriber Test Plan

[sebb]

On 7 October 2011 07:19, Naveen Jakad  wrote:
> Hi,
>        I am new user of J-meter.

This is off-topic for the JMeter developer list.

Please subscribe to the JMeter user mailing list and post there - thanks.
See:
http://jakarta.apache.org/site/mail2.html

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 7 October 2011 09:45, Philippe Mouawad  wrote:
> Hello Sebb,
> By proxy do you mean:
> Proxy.newProxyInstance and InvocationHandler, if so aren't we missing an
> Interface (Sampler does not do the job and it does not use Entry parameter).
> If so I agree lot of job.

Yes.

> Regarding the need to clone sampler, why do we need this, is there some data
> that may be corrupted except CookieManager ?

I don't know.
We already discovered problems with CM and CacheManager, but there are
a lot of other data areas that could potentially be affected.
For example, the HC3 and HC4 clients and their connections.

As I wrote earlier, the JMeter design is based on sampler classes
being single-threaded.

Just had a quick look, and for example the HC4 currentRequest (used
for interrupting the sampler) is a potential problem.
Any instance data that can be changed by the sampling process may
cause problems.

> I implemented the approach with CookieManager in ThreadLocal and it works
> without need for thread safety.
> I will attach it to ISSUE to let you review it.

OK, I'll have a look.

However, as I just wrote, I suspect this will only fix the issue we know about.

> Regards
> Philippe
>
> On Fri, Oct 7, 2011 at 2:46 AM, sebb  wrote:
>
>> On 7 October 2011 00:00, sebb  wrote:
>> > On 6 October 2011 22:17, Philippe Mouawad 
>> wrote:
>> >> Hello Sebb,
>> >> My responses below, there is one remaining point and I think we can go
>> for
>> >> implementation (i can do it if you agree).
>> >>
>> >> Regards
>> >> Philippe
>> >>
>> >> On Thu, Oct 6, 2011 at 12:01 AM, sebb  wrote:
>> >>
>> >>> On 5 October 2011 21:46, Philippe Mouawad 
>> >>> wrote:
>> >>> > Hello Sebb, all,
>> >>> > First a note regarding
>> >>> > "If cookies are being ignored, then the cookie manager property can
>> just
>> >>> be
>> >>> > cleared - i.e. there is no cookie manager."
>> >>> >
>> >>> > Just to be sure I understand, you mean "Cookies of embedded resources
>> are
>> >>> > not used", because download of embedded resources may require
>> JSESSIONID
>> >>> > cookie at least or any cookie containing Session information.
>> >>> > In this case can CookieManager be null or shouln't it be cloned from
>> >>> parent
>> >>> > but it's result not used ? Maybe that's what you mean or I missed
>> >>> something.
>> >>>
>> >>> I forgot that cookies might be needed to access the embedded
>> >>> resources, so that won't work.
>> >>>
>> >>> > So, regarding your last comment on 51919 here is an updated
>> >>> implementation
>> >>> > proposition:
>> >>> >
>> >>> >   - Add an option "embedded_resources_use_cookies" to use Cookies we
>> get
>> >>> >   from embedded resources (conc or serial) download,  default value
>> will
>> >>> be
>> >>> >   true (to handle frames by default).
>> >>>
>> >>> I don't think we need the option.
>> >>>
>> >> OK
>> >>
>> >>>
>> >>> >   - Create a Bean AsynSamplerResultHolder that will hold:
>> >>> >      - HTTPSampleResult
>> >>> >      - Cookie[]
>> >>>
>> >>> Yes, something like that.
>> >>>
>> >> OK
>> >>
>> >>>
>> >>> > *Conc download:*
>> >>> >
>> >>> >   - Pass CookieManager to AsynSampler, clone it and add existing
>> cookie,
>> >>> >   and store it in ThreadLocal
>> >>>
>> >>> No need; if the cookie manager is cloned it can be stored in the normal
>> >>> place.
>> >>>
>> >>> I don't think so, because if we clone and set in normal place (call
>> >> setCookieManager() in call() method of AsyncSampler  ) as we are
>>  calling
>> >> HTTPSamplerBase.this.sample(...), we are working on same instance as
>>  Parent
>> >> Sampler (that runs conc)  it will take place of parent Cookie Manager.
>> >> Either I didn't get what you mean otherwise I think we must store it in
>> >> ThreadLocal
>> >
>> > We need to clone the sampler and the cookie manager.

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 7 October 2011 00:00, sebb  wrote:
> On 6 October 2011 22:17, Philippe Mouawad  wrote:
>> Hello Sebb,
>> My responses below, there is one remaining point and I think we can go for
>> implementation (i can do it if you agree).
>>
>> Regards
>> Philippe
>>
>> On Thu, Oct 6, 2011 at 12:01 AM, sebb  wrote:
>>
>>> On 5 October 2011 21:46, Philippe Mouawad 
>>> wrote:
>>> > Hello Sebb, all,
>>> > First a note regarding
>>> > "If cookies are being ignored, then the cookie manager property can just
>>> be
>>> > cleared - i.e. there is no cookie manager."
>>> >
>>> > Just to be sure I understand, you mean "Cookies of embedded resources are
>>> > not used", because download of embedded resources may require JSESSIONID
>>> > cookie at least or any cookie containing Session information.
>>> > In this case can CookieManager be null or shouln't it be cloned from
>>> parent
>>> > but it's result not used ? Maybe that's what you mean or I missed
>>> something.
>>>
>>> I forgot that cookies might be needed to access the embedded
>>> resources, so that won't work.
>>>
>>> > So, regarding your last comment on 51919 here is an updated
>>> implementation
>>> > proposition:
>>> >
>>> >   - Add an option "embedded_resources_use_cookies" to use Cookies we get
>>> >   from embedded resources (conc or serial) download,  default value will
>>> be
>>> >   true (to handle frames by default).
>>>
>>> I don't think we need the option.
>>>
>> OK
>>
>>>
>>> >   - Create a Bean AsynSamplerResultHolder that will hold:
>>> >      - HTTPSampleResult
>>> >      - Cookie[]
>>>
>>> Yes, something like that.
>>>
>> OK
>>
>>>
>>> > *Conc download:*
>>> >
>>> >   - Pass CookieManager to AsynSampler, clone it and add existing cookie,
>>> >   and store it in ThreadLocal
>>>
>>> No need; if the cookie manager is cloned it can be stored in the normal
>>> place.
>>>
>>> I don't think so, because if we clone and set in normal place (call
>> setCookieManager() in call() method of AsyncSampler  ) as we are  calling
>> HTTPSamplerBase.this.sample(...), we are working on same instance as  Parent
>> Sampler (that runs conc)  it will take place of parent Cookie Manager.
>> Either I didn't get what you mean otherwise I think we must store it in
>> ThreadLocal
>
> We need to clone the sampler and the cookie manager.
>
> AsynchSampler needs to be static; it can be passed "this" when it is created.
> Its constructor then clones this, and replaces the Cookie Manager (if
> any) with a copy of the CM, and copy the cookies as well.
>
> Probably need to add a copy constuctor to CM to make this easier.
>
> AsyncSampler then uses the cloned sampler to access the sample method.
>
> I'll do the first bit shortly - converting the AsychSampler to a
> static class - and you can do the rest.

Unfortunately, cloning the sampler is not easy.
I've had a look at wrapping the sampler to intercept calls to
getCookieManager() but AFAICT that would require writing an
interceptor proxy.
Which is potentially a lot of work.

I need to give this some more thought.

>>
>>> >   - At end of sample:
>>> >      - If "embedded_resources_use_cookies" is false =>build
>>> > AsynSamplerResultHolder
>>> >      with HTTPSampleResult and empty cookies array
>>> >      - If "embedded_resources_use_cookies" is true =>build
>>> > AsynSamplerResultHolder
>>> >      with HTTPSampleResult and new cookies
>>> >   - Inside FutureResult#get loop, merge result in CookieManager
>>>
>>> Yes.
>>>
>> OK, getCookieManager.add() will do the job.
>>
>>>
>>> > *Serial Mode:
>>> > *
>>> >
>>> >   - Before start of sample, backup CookieManager
>>> >   - At end of sample:
>>> >      - If "embedded_resources_use_cookies" is false => ignore cookies
>>> >      - If "embedded_resources_use_cookies" is true => add cookies to
>>> backup
>>> >      CookieManager
>>>
>>> No need.
>>>
>> OK
>>
>>>
>>> >
>>> > Modify HTTPSampl

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 6 October 2011 22:17, Philippe Mouawad  wrote:
> Hello Sebb,
> My responses below, there is one remaining point and I think we can go for
> implementation (i can do it if you agree).
>
> Regards
> Philippe
>
> On Thu, Oct 6, 2011 at 12:01 AM, sebb  wrote:
>
>> On 5 October 2011 21:46, Philippe Mouawad 
>> wrote:
>> > Hello Sebb, all,
>> > First a note regarding
>> > "If cookies are being ignored, then the cookie manager property can just
>> be
>> > cleared - i.e. there is no cookie manager."
>> >
>> > Just to be sure I understand, you mean "Cookies of embedded resources are
>> > not used", because download of embedded resources may require JSESSIONID
>> > cookie at least or any cookie containing Session information.
>> > In this case can CookieManager be null or shouln't it be cloned from
>> parent
>> > but it's result not used ? Maybe that's what you mean or I missed
>> something.
>>
>> I forgot that cookies might be needed to access the embedded
>> resources, so that won't work.
>>
>> > So, regarding your last comment on 51919 here is an updated
>> implementation
>> > proposition:
>> >
>> >   - Add an option "embedded_resources_use_cookies" to use Cookies we get
>> >   from embedded resources (conc or serial) download,  default value will
>> be
>> >   true (to handle frames by default).
>>
>> I don't think we need the option.
>>
> OK
>
>>
>> >   - Create a Bean AsynSamplerResultHolder that will hold:
>> >      - HTTPSampleResult
>> >      - Cookie[]
>>
>> Yes, something like that.
>>
> OK
>
>>
>> > *Conc download:*
>> >
>> >   - Pass CookieManager to AsynSampler, clone it and add existing cookie,
>> >   and store it in ThreadLocal
>>
>> No need; if the cookie manager is cloned it can be stored in the normal
>> place.
>>
>> I don't think so, because if we clone and set in normal place (call
> setCookieManager() in call() method of AsyncSampler  ) as we are  calling
> HTTPSamplerBase.this.sample(...), we are working on same instance as  Parent
> Sampler (that runs conc)  it will take place of parent Cookie Manager.
> Either I didn't get what you mean otherwise I think we must store it in
> ThreadLocal

We need to clone the sampler and the cookie manager.

AsynchSampler needs to be static; it can be passed "this" when it is created.
Its constructor then clones this, and replaces the Cookie Manager (if
any) with a copy of the CM, and copy the cookies as well.

Probably need to add a copy constuctor to CM to make this easier.

AsyncSampler then uses the cloned sampler to access the sample method.

I'll do the first bit shortly - converting the AsychSampler to a
static class - and you can do the rest.

>
>> >   - At end of sample:
>> >      - If "embedded_resources_use_cookies" is false =>build
>> > AsynSamplerResultHolder
>> >      with HTTPSampleResult and empty cookies array
>> >      - If "embedded_resources_use_cookies" is true =>build
>> > AsynSamplerResultHolder
>> >      with HTTPSampleResult and new cookies
>> >   - Inside FutureResult#get loop, merge result in CookieManager
>>
>> Yes.
>>
> OK, getCookieManager.add() will do the job.
>
>>
>> > *Serial Mode:
>> > *
>> >
>> >   - Before start of sample, backup CookieManager
>> >   - At end of sample:
>> >      - If "embedded_resources_use_cookies" is false => ignore cookies
>> >      - If "embedded_resources_use_cookies" is true => add cookies to
>> backup
>> >      CookieManager
>>
>> No need.
>>
> OK
>
>>
>> >
>> > Modify HTTPSamplerBase#getCookieManager to get CookieManager first from
>> > Thread Local then from testElement. (as today)
>> >
>> >
>> > Waiting for your comments on this.
>>
>> I was thinking that ignoring cookies would simplify the problem, but
>> it does not seem to.
>>
>> So the only change we would need to do is to clone the cookies for
>> each task, and collect them again at the end.
>>
>> No need to make the cookie storage class thread-safe.
>>
>> OK
>
>
>> > Regards
>> > Philippe
>> >
>> > On Mon, Oct 3, 2011 at 5:02 PM, sebb  wrote:
>> >
>> >> On 3 October 2011 15:39, Philippe Mouawad 
>> >> wrote:
>

Welcome to Jakarta and JMeter!

[sebb]

Welcome to Apache Jakarta and JMeter!

==

[This is a brain dump in no particular order and is open to discussion]

First: decisions are made on the public mailing lists (or occasionally
on Bugzilla issues for technical issues).
Apache code is open source, and so are the related decisions.
The only exception is for reports of security issues, but that is
unlikely to be relevant for JMeter.
Also personnel matters - election of new committers etc - happen on
the PMC private list.

The developer list (this list) is for development issues; usage
questions should be confined to the JMeter User list.

Code layout: follow the existing conventions of classes; generally 4
spaces indentation (never any tabs).
We don't use @author tags in source code. Credit can be given in the
changes list if required.
Don't use the $Date: $ SVN tag - it is displayed in the default
Locale, which causes problems when comparing source code with SVN.

Make sure you have configured SVN defaults correctly, see [1]

Each commit should deal with a single issue.
Ideally all the updates needed to fix an issue or implement a new
feature should be added in a single commit, including the
documentation and test cases.
However, sometimes this would result in a very large commit, in which
case try to break it down into smaller self-contained commits.

Remember that the commit messages may be reviewed by many people, so
- use a log message that helps the reader understand the reason for the commit
- don't mix different fixes in a single commit

When fixing a Bugzilla issue, remember to include the Bugzilla details
in the commit message, and it helps to add the SVN commit message
summary to the Bugzilla issue when resolving it.

SVN log messages should be regarded as temporary, as a means to
understand the reason for the commit.
They should not be used to document the code.
ASF code is released as source code, and it should not be necessary to
have to read the SVN logs to understand the code.
The SVN logs might not be available to the end-user - and SVN log
messages can be modified; any previous log message is lost.

Change logs should not be added to source files; that's what SVN history is for.
Nor do Bugzilla ids need to be added to the source code except where
it helps explain the code.

Code layout fixes such as tab removal and indentation fixes should
generally be done in a separate commit.

Javadoc can be omitted for trivial getter/setter methods, but
otherwise should be present. (yes, there are lots of methods which
need Javadoc still!)

All new files created at the ASF should have the AL header.
If you have not created the code yourself, please check that it is OK
to commit it.
Short patches submitted via Bugzilla are OK, but anything substantial
may need additional documentation.

If you want to work on a new feature that changes a lot of files, it
might be worth doing so in a branch; just e-mail the dev list first to
say what you are proposing.

JMeter-specific issues


It is important to maintain upwards compatibility of JMX files, so
don't change any constants that are used to define the JMX attributes.
When adding new attributes, ensure that the default value is also
defined as a constant; this can then be used to ensure the attribute
is omitted if using the default value.

Likewise, the output sample result XML files have a specific format.
These files may be read back by JMeter listeners, and may be processed
by various different 3rd party tools and scripts.
Changes to the fomat need to be upwards compatible or a lot of JMeter
users will be seriously inconvenienced.

JMeter runs in GUI, non-GUI, and in client-server mode. GUI classes
should only do processing that is relevant to the GUI, or problems may
occur when the test plan is run non-GUI.

The JMeter code is split into several different source trees, which
are combined into different jars.
These are built in a specific order; care must be taken not to
reference "later" methods from "earlier" classes otherwise a clean
build will fail.

JMeter code is 100% Java, and should run on any OS with a compatible JVM.
OS-specific code should only be used to fix problems on that specific
OS; code that only works on a specific OS - OS-specific extensions -
are out of scope for JMeter.

The Ant build script has a "test" target which exercises most of the
code; if making a non-trivial change please run this before
committing.
However if you do manage to break the code, the Gump test run will
find it soon enough.

[1] http://www.apache.org/dev/version-control.html#https-svn-config

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 5 October 2011 21:46, Philippe Mouawad  wrote:
> Hello Sebb, all,
> First a note regarding
> "If cookies are being ignored, then the cookie manager property can just be
> cleared - i.e. there is no cookie manager."
>
> Just to be sure I understand, you mean "Cookies of embedded resources are
> not used", because download of embedded resources may require JSESSIONID
> cookie at least or any cookie containing Session information.
> In this case can CookieManager be null or shouln't it be cloned from parent
> but it's result not used ? Maybe that's what you mean or I missed something.

I forgot that cookies might be needed to access the embedded
resources, so that won't work.

> So, regarding your last comment on 51919 here is an updated implementation
> proposition:
>
>   - Add an option "embedded_resources_use_cookies" to use Cookies we get
>   from embedded resources (conc or serial) download,  default value will be
>   true (to handle frames by default).

I don't think we need the option.

>   - Create a Bean AsynSamplerResultHolder that will hold:
>      - HTTPSampleResult
>      - Cookie[]

Yes, something like that.

> *Conc download:*
>
>   - Pass CookieManager to AsynSampler, clone it and add existing cookie,
>   and store it in ThreadLocal

No need; if the cookie manager is cloned it can be stored in the normal place.

>   - At end of sample:
>      - If "embedded_resources_use_cookies" is false =>build
> AsynSamplerResultHolder
>      with HTTPSampleResult and empty cookies array
>      - If "embedded_resources_use_cookies" is true =>build
> AsynSamplerResultHolder
>      with HTTPSampleResult and new cookies
>   - Inside FutureResult#get loop, merge result in CookieManager

Yes.

> *Serial Mode:
> *
>
>   - Before start of sample, backup CookieManager
>   - At end of sample:
>      - If "embedded_resources_use_cookies" is false => ignore cookies
>      - If "embedded_resources_use_cookies" is true => add cookies to backup
>      CookieManager

No need.

>
> Modify HTTPSamplerBase#getCookieManager to get CookieManager first from
> Thread Local then from testElement. (as today)
>
>
> Waiting for your comments on this.

I was thinking that ignoring cookies would simplify the problem, but
it does not seem to.

So the only change we would need to do is to clone the cookies for
each task, and collect them again at the end.

No need to make the cookie storage class thread-safe.

> Regards
> Philippe
>
> On Mon, Oct 3, 2011 at 5:02 PM, sebb  wrote:
>
>> On 3 October 2011 15:39, Philippe Mouawad 
>> wrote:
>> > On Mon, Oct 3, 2011 at 4:31 PM, sebb  wrote:
>> >
>> >> On 3 October 2011 14:04, Philippe Mouawad 
>> >> wrote:
>> >> > You are right,
>> >> > Patch was just about quick fix before the more impacting fix.
>> >> >
>> >> > Here are my propositions regarding this more impacting fix:
>> >> >
>> >> >   - Add an option to make conc download use or not cookie, default
>> value
>> >> >   will be false.
>> >> >   - In AsyncSampler make a Clone with current cookies of Parent
>> >> >   CookieManager (the one that is calling Executor) and store it in
>> >> ThreadLocal
>> >> >   - Change HttpSamplerBase#getCookieManager to retrieve first in
>> Thread
>> >> >   Local then in instance
>> >> >   - If option is true, when reading res in Future
>> loop,
>> >> >   reinject cookies inside ParentCookie otherwise ignore them
>> >>
>> >> As I wrote earlier, I'm not sure it ever makes sense to handle cookies
>> >> from embedded resources, so it would be simpler just to ignore them.
>> >>
>> >> I am not sure Frame couldn't be concerned by this case, so in my opinion
>> it
>> > should be a parameter not ignored by default.
>>
>> I'd overlooked frame.
>>
>> >
>> >> I'm looking at passing the current sampler to the AsyncSampler class,
>> >> which can then clone it.
>> >> I think that will create an independent set of cookies, so there can
>> >> be no need to protect against concurrent updates.
>> >>
>> > Agree, that's how I imagined it, but then you agree you have to store
>> > CookieManager in thread local ?
>>
>> If cookies are being ignored, then the cookie manager property can
>> just be cleared - i.e. there is no cookie manager.
>>
>> Alternatively, it will

Re: Issue in "ant test" when Locale is not en/EN

[sebb]

On 5 October 2011 14:17, Philippe Mouawad  wrote:
> Hello,
>
> Just to tell you that when I run *ant test* in my default locale (fr/FR) I
> get a failure with this:
>     [echo] BatchTestLocal output files compared OK
>   [concat] 2011/10/05 15:00:03 WARN  - jmeter.util.JMeterUtils: Could not
> find resources for 'fr_FR', using 'fr'
>
> BUILD FAILED
> /data/decathlon/workspace/jmeter/build.xml:1946: Error detected in log file.
> See above.
>
>
> As i get a warning in file, it is not empty so it fails.
>
> I fixed it by adding this to at line 1895:
>        
>           

I'd rather the build file did not set the Locale; that way we are more
likely to find incorrect assumptions about the locale.

In this case, I think a better fix is to change the message to INFO
level - it should probably have not been WARN in the first place.

I'll fix that shortly.

> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: DO NOT REPLY [Bug 51876] [PATCH] Functionnality to search in Samplers TreeView

[sebb]

On 4 October 2011 15:51,   wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51876
>
> Philippe Mouawad  changed:
>
>           What    |Removed                     |Added
> 
>            Summary|Functionnality to search in |[PATCH] Functionnality to
>                   |Samplers TreeView           |search in Samplers TreeView

It's not necessary to change the summary when a patch is added.

But leave it for now.

> --
> Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are the assignee for the bug.
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Running ant test fails

[sebb]

On 3 October 2011 16:39, Philippe Mouawad  wrote:
> Apache Ant version 1.7.1 compiled on June 27 2008

You need to update to at least 1.8.

I added a check for that for the download_jars target, but the check
obviously needs to be done for other targets too.
Or simpler, we just require it for all builds.

> On Mon, Oct 3, 2011 at 5:30 PM, sebb  wrote:
>
>> On 3 October 2011 16:12, Philippe Mouawad 
>> wrote:
>> > Hello,
>> > I just updated and I get:
>> > BUILD FAILED
>> > */data/decathlon/workspace/jmeter/build.xml:1882: The following error
>> > occurred while executing this line:
>> > /data/decathlon/workspace/jmeter/build.xml:1875: Problem: failed to
>> create
>> > task or type local
>> > Cause: The name is undefined.
>> > Action: Check the spelling.
>> > Action: Check that any custom tasks/types have been declared.
>> > Action: Check that any / declarations have taken
>> place.
>> > *
>> >
>> >
>> > Total time: 32 seconds
>> >
>> >
>> > I think local macro is missing
>>
>> What version of Ant are you using?
>>
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Running ant test fails

[sebb]

On 3 October 2011 16:12, Philippe Mouawad  wrote:
> Hello,
> I just updated and I get:
> BUILD FAILED
> */data/decathlon/workspace/jmeter/build.xml:1882: The following error
> occurred while executing this line:
> /data/decathlon/workspace/jmeter/build.xml:1875: Problem: failed to create
> task or type local
> Cause: The name is undefined.
> Action: Check the spelling.
> Action: Check that any custom tasks/types have been declared.
> Action: Check that any / declarations have taken place.
> *
>
>
> Total time: 32 seconds
>
>
> I think local macro is missing

What version of Ant are you using?

> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 3 October 2011 16:07, Shmuel Krakower  wrote:
> Hi,
> Why isn't Cookie manager implemented the way Cache manager is (using a
> thread local hash map)?

Probably mainly historical.

Cookies are currently stored in an ArrayList, but one could perhaps
use a HashMap instead.
Though that won't work if cookie names can change - the current
implementation does allow pre-defined cookies to be defined in terms
of variables/functions.

Is there a use-case for variable cookie names? Perhaps; it seems quite
likely that variable values would be useful.

I don't know off-hand if that would still work if the code switched to
(Inheritable)ThreadLocal.

> If it would be implemented the same way - the fix should be the same as on
> the Cache manager case (
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51752)
>
> Regards,
> Shmuel Krakower.
>
>
> On Mon, Oct 3, 2011 at 5:02 PM, sebb  wrote:
>
>> On 3 October 2011 15:39, Philippe Mouawad 
>> wrote:
>> > On Mon, Oct 3, 2011 at 4:31 PM, sebb  wrote:
>> >
>> >> On 3 October 2011 14:04, Philippe Mouawad 
>> >> wrote:
>> >> > You are right,
>> >> > Patch was just about quick fix before the more impacting fix.
>> >> >
>> >> > Here are my propositions regarding this more impacting fix:
>> >> >
>> >> >   - Add an option to make conc download use or not cookie, default
>> value
>> >> >   will be false.
>> >> >   - In AsyncSampler make a Clone with current cookies of Parent
>> >> >   CookieManager (the one that is calling Executor) and store it in
>> >> ThreadLocal
>> >> >   - Change HttpSamplerBase#getCookieManager to retrieve first in
>> Thread
>> >> >   Local then in instance
>> >> >   - If option is true, when reading res in Future
>> loop,
>> >> >   reinject cookies inside ParentCookie otherwise ignore them
>> >>
>> >> As I wrote earlier, I'm not sure it ever makes sense to handle cookies
>> >> from embedded resources, so it would be simpler just to ignore them.
>> >>
>> >> I am not sure Frame couldn't be concerned by this case, so in my opinion
>> it
>> > should be a parameter not ignored by default.
>>
>> I'd overlooked frame.
>>
>> >
>> >> I'm looking at passing the current sampler to the AsyncSampler class,
>> >> which can then clone it.
>> >> I think that will create an independent set of cookies, so there can
>> >> be no need to protect against concurrent updates.
>> >>
>> > Agree, that's how I imagined it, but then you agree you have to store
>> > CookieManager in thread local ?
>>
>> If cookies are being ignored, then the cookie manager property can
>> just be cleared - i.e. there is no cookie manager.
>>
>> Alternatively, it will also need to be cloned.
>>
>> >>
>> >> We then need to consider if non-concurrent downloads should still be
>> >> processed for cookies.
>> >>
>> >>
>> > Conc and serial should have the same behaviour
>>
>> >
>> > PS : Does it mean that you are working on issue and will fix it on your
>> side
>>
>> Not yet decided; we need to agree on the approach first.
>>
>> >
>> >>
>> >> > Regards
>> >> > Philippe
>> >> >
>> >> > On Mon, Oct 3, 2011 at 2:29 PM, sebb  wrote:
>> >> >
>> >> >> On 3 October 2011 13:14, Philippe Mouawad <
>> philippe.moua...@gmail.com>
>> >> >> wrote:
>> >> >> > Sebb,
>> >> >> > Do you want me to provide a patch with ConcurrentHashMap where I
>> will
>> >> >> have
>> >> >> > to handle null keys and values (not same behaviour as HashMap) or
>> we
>> >> >> forget
>> >> >> > about this approach ?
>> >> >>
>> >> >> I don't think we have yet decided how best to handle concurrent
>> >> downloads.
>> >> >>
>> >> >> e.g. should they even be setting cookies?
>> >> >>
>> >> >> > Regards
>> >> >> > Philippe
>> >> >> >
>> >> >> > On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad <
>> >> >> philippe.moua...@gmail.com
>> >> >> >> wrote

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 3 October 2011 15:39, Philippe Mouawad  wrote:
> On Mon, Oct 3, 2011 at 4:31 PM, sebb  wrote:
>
>> On 3 October 2011 14:04, Philippe Mouawad 
>> wrote:
>> > You are right,
>> > Patch was just about quick fix before the more impacting fix.
>> >
>> > Here are my propositions regarding this more impacting fix:
>> >
>> >   - Add an option to make conc download use or not cookie, default value
>> >   will be false.
>> >   - In AsyncSampler make a Clone with current cookies of Parent
>> >   CookieManager (the one that is calling Executor) and store it in
>> ThreadLocal
>> >   - Change HttpSamplerBase#getCookieManager to retrieve first in Thread
>> >   Local then in instance
>> >   - If option is true, when reading res in Future loop,
>> >   reinject cookies inside ParentCookie otherwise ignore them
>>
>> As I wrote earlier, I'm not sure it ever makes sense to handle cookies
>> from embedded resources, so it would be simpler just to ignore them.
>>
>> I am not sure Frame couldn't be concerned by this case, so in my opinion it
> should be a parameter not ignored by default.

I'd overlooked frame.

>
>> I'm looking at passing the current sampler to the AsyncSampler class,
>> which can then clone it.
>> I think that will create an independent set of cookies, so there can
>> be no need to protect against concurrent updates.
>>
> Agree, that's how I imagined it, but then you agree you have to store
> CookieManager in thread local ?

If cookies are being ignored, then the cookie manager property can
just be cleared - i.e. there is no cookie manager.

Alternatively, it will also need to be cloned.

>>
>> We then need to consider if non-concurrent downloads should still be
>> processed for cookies.
>>
>>
> Conc and serial should have the same behaviour

>
> PS : Does it mean that you are working on issue and will fix it on your side

Not yet decided; we need to agree on the approach first.

>
>>
>> > Regards
>> > Philippe
>> >
>> > On Mon, Oct 3, 2011 at 2:29 PM, sebb  wrote:
>> >
>> >> On 3 October 2011 13:14, Philippe Mouawad 
>> >> wrote:
>> >> > Sebb,
>> >> > Do you want me to provide a patch with ConcurrentHashMap where I will
>> >> have
>> >> > to handle null keys and values (not same behaviour as HashMap) or we
>> >> forget
>> >> > about this approach ?
>> >>
>> >> I don't think we have yet decided how best to handle concurrent
>> downloads.
>> >>
>> >> e.g. should they even be setting cookies?
>> >>
>> >> > Regards
>> >> > Philippe
>> >> >
>> >> > On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad <
>> >> philippe.moua...@gmail.com
>> >> >> wrote:
>> >> >
>> >> >> Hello,
>> >> >> Just a little update on my test.
>> >> >> I added a clear and gc before each Map instanciation and results are
>> >> >> different:
>> >> >>
>> >> >>    - HashMapput:645
>> >> >>    - ConcurrentHashMapput:832
>> >> >>    - ConcurrentReaderHashMapput:620
>> >> >>    - HashMap get:17
>> >> >>    - ConcurrentHashMap get:32
>> >> >>    - ConcurrentReaderHashMap get:60
>> >> >>
>> >> >>
>> >> >> So it kind of closes the debate, sorry for disturbance.
>> >> >> Regards
>> >> >> Philippe
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> public class TestMap {
>> >> >>
>> >> >>     public static void main(String[] args) {
>> >> >>         StopWatch timer = new StopWatch();
>> >> >>
>> >> >>         Map map = new HashMap();
>> >> >>         testPut(timer, map, "HashMap");
>> >> >>         timer.reset();
>> >> >>
>> >> >>         map.clear();
>> >> >>         System.gc();
>> >> >>
>> >> >>         map = new ConcurrentHashMap();
>> >> >>         testPut(timer, map, "ConcurrentHashMap");
>> >> >>         timer.reset();
>> >> >>
>> >> >>         map.clear();
>> >&

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 3 October 2011 14:04, Philippe Mouawad  wrote:
> You are right,
> Patch was just about quick fix before the more impacting fix.
>
> Here are my propositions regarding this more impacting fix:
>
>   - Add an option to make conc download use or not cookie, default value
>   will be false.
>   - In AsyncSampler make a Clone with current cookies of Parent
>   CookieManager (the one that is calling Executor) and store it in ThreadLocal
>   - Change HttpSamplerBase#getCookieManager to retrieve first in Thread
>   Local then in instance
>   - If option is true, when reading res in Future loop,
>   reinject cookies inside ParentCookie otherwise ignore them

As I wrote earlier, I'm not sure it ever makes sense to handle cookies
from embedded resources, so it would be simpler just to ignore them.

I'm looking at passing the current sampler to the AsyncSampler class,
which can then clone it.
I think that will create an independent set of cookies, so there can
be no need to protect against concurrent updates.

We then need to consider if non-concurrent downloads should still be
processed for cookies.

>
> Regards
> Philippe
>
> On Mon, Oct 3, 2011 at 2:29 PM, sebb  wrote:
>
>> On 3 October 2011 13:14, Philippe Mouawad 
>> wrote:
>> > Sebb,
>> > Do you want me to provide a patch with ConcurrentHashMap where I will
>> have
>> > to handle null keys and values (not same behaviour as HashMap) or we
>> forget
>> > about this approach ?
>>
>> I don't think we have yet decided how best to handle concurrent downloads.
>>
>> e.g. should they even be setting cookies?
>>
>> > Regards
>> > Philippe
>> >
>> > On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad <
>> philippe.moua...@gmail.com
>> >> wrote:
>> >
>> >> Hello,
>> >> Just a little update on my test.
>> >> I added a clear and gc before each Map instanciation and results are
>> >> different:
>> >>
>> >>    - HashMapput:645
>> >>    - ConcurrentHashMapput:832
>> >>    - ConcurrentReaderHashMapput:620
>> >>    - HashMap get:17
>> >>    - ConcurrentHashMap get:32
>> >>    - ConcurrentReaderHashMap get:60
>> >>
>> >>
>> >> So it kind of closes the debate, sorry for disturbance.
>> >> Regards
>> >> Philippe
>> >>
>> >>
>> >>
>> >>
>> >> public class TestMap {
>> >>
>> >>     public static void main(String[] args) {
>> >>         StopWatch timer = new StopWatch();
>> >>
>> >>         Map map = new HashMap();
>> >>         testPut(timer, map, "HashMap");
>> >>         timer.reset();
>> >>
>> >>         map.clear();
>> >>         System.gc();
>> >>
>> >>         map = new ConcurrentHashMap();
>> >>         testPut(timer, map, "ConcurrentHashMap");
>> >>         timer.reset();
>> >>
>> >>         map.clear();
>> >>         System.gc();
>> >>
>> >>         map = new ConcurrentReaderHashMap();
>> >>         testPut(timer, map, "ConcurrentReaderHashMap");
>> >>         timer.reset();
>> >>
>> >>
>> >>         map.clear();
>> >>         System.gc();
>> >>
>> >>         map = new HashMap();
>> >>         testGet(timer, map, "HashMap");
>> >>         timer.reset();
>> >>
>> >>         map.clear();
>> >>         System.gc();
>> >>
>> >>         map = new ConcurrentHashMap();
>> >>         testGet(timer, map, "ConcurrentHashMap");
>> >>         timer.reset();
>> >>
>> >>         map.clear();
>> >>         System.gc();
>> >>
>> >>         map = new ConcurrentReaderHashMap();
>> >>         testGet(timer, map, "ConcurrentReaderHashMap");
>> >>         timer.reset();
>> >>     }
>> >>
>> >>     /**
>> >>      * @param timer
>> >>      */
>> >>     private static void testGet(StopWatch timer, Map map, String type) {
>> >>         timer.start();
>> >>         for (int i = 0; i < 100; i++) {
>> >>             map.get(i);
>> >>         }
>> >>         timer.stop();
>> >>         System.out.println(type+" get

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 3 October 2011 13:14, Philippe Mouawad  wrote:
> Sebb,
> Do you want me to provide a patch with ConcurrentHashMap where I will have
> to handle null keys and values (not same behaviour as HashMap) or we forget
> about this approach ?

I don't think we have yet decided how best to handle concurrent downloads.

e.g. should they even be setting cookies?

> Regards
> Philippe
>
> On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad > wrote:
>
>> Hello,
>> Just a little update on my test.
>> I added a clear and gc before each Map instanciation and results are
>> different:
>>
>>    - HashMapput:645
>>    - ConcurrentHashMapput:832
>>    - ConcurrentReaderHashMapput:620
>>    - HashMap get:17
>>    - ConcurrentHashMap get:32
>>    - ConcurrentReaderHashMap get:60
>>
>>
>> So it kind of closes the debate, sorry for disturbance.
>> Regards
>> Philippe
>>
>>
>>
>>
>> public class TestMap {
>>
>>     public static void main(String[] args) {
>>         StopWatch timer = new StopWatch();
>>
>>         Map map = new HashMap();
>>         testPut(timer, map, "HashMap");
>>         timer.reset();
>>
>>         map.clear();
>>         System.gc();
>>
>>         map = new ConcurrentHashMap();
>>         testPut(timer, map, "ConcurrentHashMap");
>>         timer.reset();
>>
>>         map.clear();
>>         System.gc();
>>
>>         map = new ConcurrentReaderHashMap();
>>         testPut(timer, map, "ConcurrentReaderHashMap");
>>         timer.reset();
>>
>>
>>         map.clear();
>>         System.gc();
>>
>>         map = new HashMap();
>>         testGet(timer, map, "HashMap");
>>         timer.reset();
>>
>>         map.clear();
>>         System.gc();
>>
>>         map = new ConcurrentHashMap();
>>         testGet(timer, map, "ConcurrentHashMap");
>>         timer.reset();
>>
>>         map.clear();
>>         System.gc();
>>
>>         map = new ConcurrentReaderHashMap();
>>         testGet(timer, map, "ConcurrentReaderHashMap");
>>         timer.reset();
>>     }
>>
>>     /**
>>      * @param timer
>>      */
>>     private static void testGet(StopWatch timer, Map map, String type) {
>>         timer.start();
>>         for (int i = 0; i < 100; i++) {
>>             map.get(i);
>>         }
>>         timer.stop();
>>         System.out.println(type+" get:"+timer.getTime());
>>     }
>>
>>     /**
>>      * @param timer
>>      */
>>     private static void testPut(StopWatch timer, Map map, String type) {
>>         timer.start();
>>         for (int i = 0; i < 100; i++) {
>>             map.put(i,i);
>>         }
>>         timer.stop();
>>         System.out.println(type+"put:"+timer.getTime());
>>     }
>>
>>
>> Regards
>> Philippe
>>
>>
>> On Mon, Oct 3, 2011 at 1:37 PM, sebb  wrote:
>>
>>> On 3 October 2011 12:15, Rainer Jung  wrote:
>>> > On 02.10.2011 23:17, Philippe Mouawad wrote:
>>> >> Ok, hope we can do the same.
>>> >
>>> > See https://issues.apache.org/jira/browse/XMLBEANS-447
>>> >
>>> > We are not the only people, who doubt it's correct to include that class
>>> ...
>>> >
>>> > There was also a discussion some time ago in another ASF project,
>>> > because the Sun license which is cited by Doug Lea has a "no use in
>>> > nuclear facilities clause", which make it non-usable as an Open Source
>>> > license.
>>> >
>>> > It looks like we are stuck here.
>>>
>>> Yes, apart from the binary option which brings in lots of unneeded code.
>>>
>>> > And the mentioning of the Harmony class in the above cited issue is a
>>> > red herring. Diffing it with the JDK 5 standard ConcurrentHashMap shows
>>> > little difference, so I doubt it will be much faster (though I didn't
>>> > inspect the delta in detail).
>>>
>>> I think the Harmony class was only mentioned as a means of supporting
>>> Java 1.4, not as an alternative faster implementation.
>>>
>>> >> I must say I don't understand why ConcurrentReaderHashMap is not in
>>> JDK.
>>> >
>>> > There

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 3 October 2011 12:15, Rainer Jung  wrote:
> On 02.10.2011 23:17, Philippe Mouawad wrote:
>> Ok, hope we can do the same.
>
> See https://issues.apache.org/jira/browse/XMLBEANS-447
>
> We are not the only people, who doubt it's correct to include that class ...
>
> There was also a discussion some time ago in another ASF project,
> because the Sun license which is cited by Doug Lea has a "no use in
> nuclear facilities clause", which make it non-usable as an Open Source
> license.
>
> It looks like we are stuck here.

Yes, apart from the binary option which brings in lots of unneeded code.

> And the mentioning of the Harmony class in the above cited issue is a
> red herring. Diffing it with the JDK 5 standard ConcurrentHashMap shows
> little difference, so I doubt it will be much faster (though I didn't
> inspect the delta in detail).

I think the Harmony class was only mentioned as a means of supporting
Java 1.4, not as an alternative faster implementation.

>> I must say I don't understand why ConcurrentReaderHashMap is not in JDK.
>
> There's a discussion list for JSR166 (the concurrency stuff lead by Doug
> Lea) mentioned on the JSR 166 page maintained by Doug Lea. So maybe you
> can post a technical question there (what's the right class that solve
> the following problem ... and doesn't have sun licensing restrictions).
>
> Regards,
>
> Rainer
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC3

[sebb]

On 29 September 2011 00:52, Milamber  wrote:
> Hello,
>
> The third release candidate for JMeter 2.5.1 has been prepared, and your
> votes are solicited.
>
> This release fixes mainly some bugs appeared since JMeter 2.5, and
> contains few improvements.
>
> Tests (load tests and/or functional tests) with JVM 5/6/7 on
> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
> 4.1 request, Http request with parallels embedded resources, View
> results tree, WebServices (SOAP) request, Async sample sending mode, etc.)
>
> List of changes:
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs/changes.html
>
>
> I hope that this 3rd RC will corrects all majors bugs.
> *I would like send special congratulations for Philippe M. and Sebb for
> their work and their improving the future version of JMeter. Thanks.*
>
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version is targeted at
> Java 1.5+.
>
> Archives/hashes/sigs and RAT report:
>
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/dist
>
> MD5 hashes of archives for this vote:
>
> e72f17c352fa4d3469d042e6542dd36d *jakarta-jmeter-2.5.1.tgz
> 2ed9e7ef8c225a416fd58de1124b7242 *jakarta-jmeter-2.5.1.zip
> 7423d3eebbdf11c28b3aebcd8ed2e78a *jakarta-jmeter-2.5.1_src.tgz
> 2b5ab9e599ac08880f85f61dab899a53 *jakarta-jmeter-2.5.1_src.zip
>
> Site Docs are here:
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs
>
> Tag:
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC3 (r1176908)
>
> Keys are here:
> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
> also
> http://people.apache.org/~milamber/
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 2.5 requires Java 1.5 or later.
>
> Note that there is a bug in Java on some Linux systems that manifests
> itself as the following error when running the test cases or JMeter itself:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
> This does not affect JMeter operation.
>
>
> All feedback (and votes!) welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0   OK, but
> [  ] -1   I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber

The 72 hours are up.

Although some additional bugs have surfaced, as far as I know these
aren't regressions, so users are no worse off running 2.5.1, and in
many respects it is better than 2.5.

Therefore I think we should continue with the release.

However, the known bugs section does not mention Bug 51918 and Bug
51919 so we should probably mention those in the announcement.
Something like:

"Version 2.5 introduced a concurrent download feature for embedded
HTML resources. Unfortunately this may result in corrupted downloads
or other errors (bugs 51918 and 51919). We will fix these bugs as soon
as possible; meanwhile the feature should not be used".

OK?

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: JMeter TLP - draft resolution and first chair

[sebb]

On 1 October 2011 15:36, Rahul Akolkar  wrote:
> On Wed, Sep 21, 2011 at 8:31 PM, sebb  wrote:
>> On 22 September 2011 01:15, Rahul Akolkar  wrote:
>>> On Wed, Sep 21, 2011 at 7:33 PM, Henri Yandell
>>>  wrote:
>>>> On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar  
>>>> wrote:
>>>>> On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell
>>>>>  wrote:
>>>>>> Happy to be on the PMC :) I'm not sure I'll be that active, but
>>>>>> hopefully can help with any setup items.
>>>>>>
>>>>>> +1 for Sebb as Chair.
>>>>>>
>>>>>
>>>>> I've updated the resolution to reflect the nomination.
>>>>>
>>>>> If there are no further changes to the proposal in a couple of days,
>>>>> I'll start the TLP vote.
>>>>
>>>> We shouldn't vote until Sebb, or someone else, is signed up to be the 
>>>> chair.
>>>>
>>> 
>>>
>>> Thats reasonable too :-) Sebb?
>>
>> I would have preferred to see JMeter as part of HC, but perhaps it
>> would be better as a TLP.
> 
>
> IMO, yes.
>
>
>> However I think we need some more PMC members first.
>>
> 
>
> I see you added olegk, which is goodness. We can always add others

I also added Rainer Jung who has kindly agreed to help.

> later. I think we're good for a vote on the resolution as is on the
> wiki. WDYT?

Yes.

> -Rahul
>
>
>> I can think of some Jakarta PMC members who have been involved with
>> JMeter recently, and I think some of the Tomcat PMC use JMeter.
>>
>> Is it OK just to add them, or should they be asked first?
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 2 October 2011 19:39, Philippe Mouawad  wrote:
> Hello Sebb,
> XMLBeans which is an Apache project under Apache Licence has included it :
>
>   -
>   
> http://massapi.com/source/xmlbeans-2.5.0/src/common/org/apache/xmlbeans/impl/common/ConcurrentReaderHashMap.java.html
>
>
> Couldn't we do the same ?

Possibly; but we would need to be sure that their reading of the rules
was correct; we don't want to propagate a mistake if it is one.

I'm pretty sure that they should not have added the AL header to the
file, so I wonder if they should have included the file at all.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1178129 | Latency/readBuffer

[sebb]

On 2 October 2011 08:51, Milamber  wrote:
> Hello,
>
> I will work on a patch which introduce a property to change the
> readBuffer size (default 8192B).

I'm OK with making the buffer size configurable.

> That me seems important because this buffer size is the calculation base
> for the latency time.
> I would like for some bandwidth tests, change the buffer size to ~1400
> or 1500B (i.e. ip packet size).
>
> Sebb, have you a special opinion (or history) on this buffer size?

I think it would be useful to be able to configure the buffer size,
but I question whether it is really necessary to change the buffer
size to improve the accuracy of the latency figure.

Perhaps there's a better way to achieve the goal which does not
involve artificially changing the buffer size.

Maybe via override of the input stream methods, or perhaps by using a
shorter initial read?

The buffer size may affect subsequent read performance, so it seems
wrong to change it just to improve the latency accuracy.

> Thanks
>
> Milamber
>
>
>
> Le 02/10/2011 07:49, milam...@apache.org a ecrit :
>> Author: milamber
>> Date: Sun Oct  2 05:49:57 2011
>> New Revision: 1178129
>>
>> URL: http://svn.apache.org/viewvc?rev=1178129&view=rev
>> Log:
>> Bug 51918 - GZIP compressed traffic produces errors, when multiple 
>> connections allowed
>>
>> Modified:
>>     
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java
>>     
>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>>     jakarta/jmeter/trunk/xdocs/changes.xml
>>
>> Modified: 
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java?rev=1178129&r1=1178128&r2=1178129&view=diff
>> ==
>> --- 
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java 
>> (original)
>> +++ 
>> jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java 
>> Sun Oct  2 05:49:57 2011
>> @@ -47,8 +47,6 @@ public class JMeterContext {
>>
>>      private int threadNum;
>>
>> -    private byte[] readBuffer = null;
>> -
>>      private boolean isReinitSubControllers = false;
>>
>>      JMeterContext() {
>> @@ -66,7 +64,6 @@ public class JMeterContext {
>>          previousSampler = null;
>>          samplingStarted = false;
>>          threadNum = 0;
>> -        readBuffer = null;
>>          thread = null;
>>          isReinitSubControllers = false;
>>      }
>> @@ -80,18 +77,6 @@ public class JMeterContext {
>>          return variables;
>>      }
>>
>> -    /**
>> -     * A temporary buffer that can be shared between samplers in a thread.
>> -     *
>> -     * @return the shared read buffer
>> -     */
>> -    public byte[] getReadBuffer() {
>> -        if (readBuffer == null) {
>> -            readBuffer = new byte[8192];
>> -        }
>> -        return readBuffer;
>> -    }
>> -
>>      public void setVariables(JMeterVariables vars) {
>>          this.variables = vars;
>>      }
>>
>> Modified: 
>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>> URL: 
>> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java?rev=1178129&r1=1178128&r2=1178129&view=diff
>> ==
>> --- 
>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>>  (original)
>> +++ 
>> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>>  Sun Oct  2 05:49:57 2011
>> @@ -1548,7 +1548,7 @@ public abstract class HTTPSamplerBase ex
>>       */
>>      public byte[] readResponse(SampleResult sampleResult, InputStream in, 
>> int length) throws IOException {
>>
>> -        byte[] readBuffer = getThreadContext().getReadBuffer();
>> +        byte[] readBuffer = new byte[8192]; // 8kB is the (max) size to 
>> have the latency ('the first packet')
>>          int bufferSize=32;// Enough for MD5
>>
>>          MessageDigest md=null;
>>
>> Modified: jakarta/jmeter/trunk/xdocs/changes.xml
>> URL: 
>> http://svn.ap

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 2 October 2011 15:20, Rainer Jung  wrote:
> On 02.10.2011 15:49, sebb wrote:
>> On 1 October 2011 14:33, Philippe Mouawad  wrote:
>>> A little additional note,
>>> There is an implementation of Concurrent map by doug lea in concurrent.jar
>>> called ConcurrentReaderHashMap
>>> that has same performance as HashMap in read and a little less on write.
>>> But performances are much better than ConcurrentHashMap.
>>> So maybe a better alternative but requires concurrent-1.3.4.jar from:
>>>
>>>   -
>>>   http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>>>
>>
>> That looks interesting, however the licensing is not at all clear to
>> me, and AFAICT we would only want the one class, not the entire jar.
>>
>> So it's quite a lot of extra complication for what is just a local 
>> optimisation.
>
> Concerning license the page says:
>
> "All classes are released to the public domain and may be used for any
> purpose whatsoever without permission or acknowledgment. Portions of the
> CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted
> from Sun JDK source code. These are copyright of Sun Microsystems, Inc,
> and are used with their kind permission, as described in this license."
>
> and "this license" is another link to a PDF.
>
> Legal has already resolved that one:
>
> http://www.apache.org/legal/resolved.html#concurrent

Thanks! Very useful.

That would allow us to use the class as part of the concurrent library.
However, we cannot use that particular source file, because it is one
of the Sun-licensed ones.
Not sure if there is any other way to include just the class that we need.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 1 October 2011 14:33, Philippe Mouawad  wrote:
> A little additional note,
> There is an implementation of Concurrent map by doug lea in concurrent.jar
> called ConcurrentReaderHashMap
> that has same performance as HashMap in read and a little less on write.
> But performances are much better than ConcurrentHashMap.
> So maybe a better alternative but requires concurrent-1.3.4.jar from:
>
>   -
>   http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>

That looks interesting, however the licensing is not at all clear to
me, and AFAICT we would only want the one class, not the entire jar.

So it's quite a lot of extra complication for what is just a local optimisation.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 1 October 2011 12:38, Philippe Mouawad  wrote:
> On Sat, Oct 1, 2011 at 12:57 PM, sebb  wrote:
>
>> On 1 October 2011 10:53, Philippe Mouawad 
>> wrote:
>> > Hello Milamber, Sebb, All,
>> > Regarding 51919 <
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919>,
>> > I wonder if there is not an issue in JMeterVariables access introduced by
>> > concurrent download.
>> > Initially I think JMeterVariables were not supposed to be shared so
>> object
>> > not thread safe, today they are due to Conc download.
>> > Maybe JMeterVariables#variables should be replaced by a
>> ConcurrentHashMap.
>> > If so CONTEXT_VARIABLES_LOCK should be removed in my patch.
>> > What do you think?
>>
>> Yes, a lot of JMeter code assumes that samplers and thread variables
>> are not shared.
>>
>> So either we remove those assumptions, which might prove more
>> expensive in the non-concurrent case;
>
>
> => Performance impact is around 3 times more between ConcurrentHashMap and
> HashMap
> when only one thread is using Map (ie case when no concurrent downloads
> occur) but maybe
> it is not that important regarding other parts of code, needs some study.

Indeed, study is needed.

>
>> or we change the way the
>> concurrent downloads are handled so they don't directly access the
>> main thread variables.
>>
>> => Don't you think code will be hard to maintain ? today AsyncSampler uses
> same sample() method as others

That is presumably broken as well, then.

> won't there be lot of special cases ?
>

Potentially yes, but the alternative is to revisit and potentially
rewrite large chunks of JMeter code.

That needs a proper strategy first, as well as loads of tests to check
the behaviour.

>> One way might be to clone the sampler so it effectively becomes a new
>> JMeterThread; I don't know how easy that would be, we would also need
>> to recover the updates at the end of the sub-samples.
>>
>> Another way would be to intercept the writes to the objects that are
>> not thread-safe and store them up for the main sample thread to do at
>> the end.
>>
>> Either way, at present the concurrent downloads unfortunately have
>> problems with cookie handling (and with buffer handling, but that is
>> trivial to fix).
>>
>> So a short-term approach might be to ignore cookies when performing
>> sub-samples - I think it is only the cookies that require updates to
>> the thread variables.
>>
>> Are there any use-cases where the web application relies on cookies
>> that are set by resources embedded in the main page?
>> I know some sites set cookies on embedded resources, but is that
>> necessary, or is it a by-product?
>>
>
> => I agree, I have never met this case in my load tests but if it is met
> load testing application will be hard
>
>>
>> If not, then ignoring such cookies would be a long-term solution.
>>
>> > Regards
>> > Philippe
>> >
>> >
>> > On Sat, Oct 1, 2011 at 9:34 AM,  wrote:
>> >
>> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919
>> >>
>> >> --- Comment #2 from Milamber  2011-10-01 07:34:04
>> UTC
>> >> ---
>> >> A better way is to synchronize only the code section referred to the
>> >> variables
>> >> from JMeterContext
>> >> (in add() and removeMatchingCookies() methods, I thinks)
>> >>
>> >> --
>> >> Configure bugmail:
>> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> >> --- You are receiving this mail because: ---
>> >> You are on the CC list for the bug.
>> >> You reported the bug.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> > Ubik-Ingénierie
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download

[sebb]

On 1 October 2011 10:53, Philippe Mouawad  wrote:
> Hello Milamber, Sebb, All,
> Regarding 51919 <https://issues.apache.org/bugzilla/show_bug.cgi?id=51919>,
> I wonder if there is not an issue in JMeterVariables access introduced by
> concurrent download.
> Initially I think JMeterVariables were not supposed to be shared so object
> not thread safe, today they are due to Conc download.
> Maybe JMeterVariables#variables should be replaced by a ConcurrentHashMap.
> If so CONTEXT_VARIABLES_LOCK should be removed in my patch.
> What do you think?

Yes, a lot of JMeter code assumes that samplers and thread variables
are not shared.

So either we remove those assumptions, which might prove more
expensive in the non-concurrent case; or we change the way the
concurrent downloads are handled so they don't directly access the
main thread variables.

One way might be to clone the sampler so it effectively becomes a new
JMeterThread; I don't know how easy that would be, we would also need
to recover the updates at the end of the sub-samples.

Another way would be to intercept the writes to the objects that are
not thread-safe and store them up for the main sample thread to do at
the end.

Either way, at present the concurrent downloads unfortunately have
problems with cookie handling (and with buffer handling, but that is
trivial to fix).

So a short-term approach might be to ignore cookies when performing
sub-samples - I think it is only the cookies that require updates to
the thread variables.

Are there any use-cases where the web application relies on cookies
that are set by resources embedded in the main page?
I know some sites set cookies on embedded resources, but is that
necessary, or is it a by-product?

If not, then ignoring such cookies would be a long-term solution.

> Regards
> Philippe
>
>
> On Sat, Oct 1, 2011 at 9:34 AM,  wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919
>>
>> --- Comment #2 from Milamber  2011-10-01 07:34:04 UTC
>> ---
>> A better way is to synchronize only the code section referred to the
>> variables
>> from JMeterContext
>> (in add() and removeMatchingCookies() methods, I thinks)
>>
>> --
>> Configure bugmail:
>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
>> --- You are receiving this mail because: ---
>> You are on the CC list for the bug.
>> You reported the bug.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC3

[sebb]

On 29 September 2011 00:52, Milamber  wrote:
> Hello,
>
> The third release candidate for JMeter 2.5.1 has been prepared, and your
> votes are solicited.
>
> This release fixes mainly some bugs appeared since JMeter 2.5, and
> contains few improvements.
>
> Tests (load tests and/or functional tests) with JVM 5/6/7 on
> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
> 4.1 request, Http request with parallels embedded resources, View
> results tree, WebServices (SOAP) request, Async sample sending mode, etc.)
>
> List of changes:
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs/changes.html
>
>
> I hope that this 3rd RC will corrects all majors bugs.
> *I would like send special congratulations for Philippe M. and Sebb for
> their work and their improving the future version of JMeter. Thanks.*
>
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version is targeted at
> Java 1.5+.
>
> Archives/hashes/sigs and RAT report:
>
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/dist
>
> MD5 hashes of archives for this vote:
>
> e72f17c352fa4d3469d042e6542dd36d *jakarta-jmeter-2.5.1.tgz
> 2ed9e7ef8c225a416fd58de1124b7242 *jakarta-jmeter-2.5.1.zip
> 7423d3eebbdf11c28b3aebcd8ed2e78a *jakarta-jmeter-2.5.1_src.tgz
> 2b5ab9e599ac08880f85f61dab899a53 *jakarta-jmeter-2.5.1_src.zip
>
> Site Docs are here:
> http://people.apache.org/~milamber/jmeter-2.5.1RC3/docs
>
> Tag:
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC3 (r1176908)
>
> Keys are here:
> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
> also
> http://people.apache.org/~milamber/
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 2.5 requires Java 1.5 or later.
>
> Note that there is a bug in Java on some Linux systems that manifests
> itself as the following error when running the test cases or JMeter itself:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
> This does not affect JMeter operation.
>
>
> All feedback (and votes!) welcome.
>
> [X] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0   OK, but
> [  ] -1   I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC3

[sebb]

On 30 September 2011 16:52, Philippe Mouawad  wrote:
> I don't think I can vote, but +1 for me as an "unofficial" vote :-)

Anyone can vote.

Only PMC votes are binding, however all votes are read and recorded in
the result e-mail.


> On Fri, Sep 30, 2011 at 5:47 PM, sebb  wrote:
>
>> On 29 September 2011 21:37, Philippe Mouawad 
>> wrote:
>> > Hello Milamber, All,
>> > Thank you Milamber for your release and "thanks" message..
>> >
>> > I may have a bad news regarding release.
>> > Working on new issue
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=51918
>> > I discovered a synchronization issue I think related to Pool of Executor
>> > that enables concurrent download of resources.
>> > There seems to be a corruption on CookieManager because I get randomly:
>> > 2011/09/29 21:59:12 WARN  - jmeter.protocol.http.sampler.HTTPSamplerBase:
>> > Execution issue when fetching embedded resources
>> > java.util.concurrent.ExecutionException: java.util.NoSuchElementException
>> >    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>> >    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.downloadPageResources(HTTPSamplerBase.java:1213)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1428)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:244)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.sample(HTTPHC3Impl.java:327)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1019)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1005)
>> >    at
>> >
>> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:411)
>> >    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:297)
>> >    at java.lang.Thread.run(Thread.java:680)
>> > Caused by: java.util.NoSuchElementException
>> >    at java.util.AbstractList$Itr.next(AbstractList.java:350)
>> >    at
>> >
>> org.apache.jmeter.testelement.property.PropertyIteratorImpl.next(PropertyIteratorImpl.java:39)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.control.CookieManager.removeMatchingCookies(CookieManager.java:466)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.control.CookieManager.add(CookieManager.java:258)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.control.CookieManager.addCookieFromHeader(CookieManager.java:430)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.saveConnectionCookies(HTTPHC3Impl.java:1071)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.sample(HTTPHC3Impl.java:319)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1709)
>> >    at
>> >
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1)
>> >    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> >    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> >    at
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> >    at
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> >    ... 1 more
>> >
>> >
>> > I have created a new Issue:
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=51919
>> >
>> > Note that this issue also exists in 2.5 release so maybe it's not a
>> blocker
>>
>> I agree, not a blocker on its own.
>>
>> The reason we abandoned the previous release vote was the problems
>> were either much more serious, or were regressions from a previous
>> release.
>>
>> I think we should continue with this release vote.
>> We need to get this release out if at all possible.
>>
>> We can do another one 

Re: [VOTE] Release JMeter 2.5.1 RC3

[sebb]

On 29 September 2011 21:37, Philippe Mouawad  wrote:
> Hello Milamber, All,
> Thank you Milamber for your release and "thanks" message..
>
> I may have a bad news regarding release.
> Working on new issue
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51918
> I discovered a synchronization issue I think related to Pool of Executor
> that enables concurrent download of resources.
> There seems to be a corruption on CookieManager because I get randomly:
> 2011/09/29 21:59:12 WARN  - jmeter.protocol.http.sampler.HTTPSamplerBase:
> Execution issue when fetching embedded resources
> java.util.concurrent.ExecutionException: java.util.NoSuchElementException
>    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
>    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.downloadPageResources(HTTPSamplerBase.java:1213)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1428)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:244)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.sample(HTTPHC3Impl.java:327)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1019)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1005)
>    at
> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:411)
>    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:297)
>    at java.lang.Thread.run(Thread.java:680)
> Caused by: java.util.NoSuchElementException
>    at java.util.AbstractList$Itr.next(AbstractList.java:350)
>    at
> org.apache.jmeter.testelement.property.PropertyIteratorImpl.next(PropertyIteratorImpl.java:39)
>    at
> org.apache.jmeter.protocol.http.control.CookieManager.removeMatchingCookies(CookieManager.java:466)
>    at
> org.apache.jmeter.protocol.http.control.CookieManager.add(CookieManager.java:258)
>    at
> org.apache.jmeter.protocol.http.control.CookieManager.addCookieFromHeader(CookieManager.java:430)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.saveConnectionCookies(HTTPHC3Impl.java:1071)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.sample(HTTPHC3Impl.java:319)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1709)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1)
>    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>    at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>    at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>    ... 1 more
>
>
> I have created a new Issue:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919
>
> Note that this issue also exists in 2.5 release so maybe it's not a blocker

I agree, not a blocker on its own.

The reason we abandoned the previous release vote was the problems
were either much more serious, or were regressions from a previous
release.

I think we should continue with this release vote.
We need to get this release out if at all possible.

We can do another one in a month or so.

> for release, although it can happen wery simply:
> - With One thread
> - Put a breakpoint in CookieManager#removeMatchingCookies
> - Let first thread go
> - then you will get parallel calls to function
> - enter loop
> - make one thread remove
> - the second one will get ConcurrentModificationException
>
> I will propose a patch as soon as possible to this.
> But this parallel download may happen on other shared component, maybe you
> or sebb know better than me which components may be concerned.
>
> Regards
> Philippe
>
> On Thu, Sep 29, 2011 at 1:54 AM, Milamber  wrote:
>
>> My vote :
>> +1
>>
>> Le 28/09/2011 23:52, Milamber a ecrit :
>> > Hello,
>> >
>> > The third release candidate for JMeter 2.5.1 has been prepared, and your
>> > votes are solicited.
>> >
>> > This release fixes mainly some bugs appeared since JMeter 2.5, and
>> > contains few improvements.
>> >
>> > Tests (load tests and/or functional tests) with JVM 5/6/7 on
>> > Linux/Windows/Mac OS on functionality changes are

Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)

[sebb]

On 28 September 2011 19:59, Philippe Mouawad  wrote:
> Hello Sebb,
> Thanks for the analysis.
> I agree with you and will try to handle these cases, do you prefer a
> discussion in mailing list or in issue ?

Mailing list.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[JMeter] resume release vote?

[sebb]

I've updated the nightly build to the latest source from trunk: r1176908

Builds and tests OK for me (and Jenkins).

Anyone is welcome to try and break the nightly ... otherwise I hope we
are ready to try again to do the release.

Milamber - are you still OK to be the RM?

S///
P.S. Apologies for the long delay in resolving the problems with RC1 and RC2.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)

[sebb]

If HttpDefaults and HttpRequest both use Parameters, then the body is
created from both sets of parameters.

When the body is being built, if any of the parameters have names,
only named parameters are kept.
Any unnamed parameters are ignored.
It's not possible to mix named and unnamed parameters; named
parameters take precedence.

If both test elements have unnamed variables only, then the body is
created from the merging of the two sets of values.

That is existing behaviour, and cannot be changed without potentially
affecting users.

Now the raw body option is currently handled as an un-named parameter.
This means that the a Raw HTTP Request will be ignored if there is a
named default parameter, and unnamed default parameters will be
appended to the body.

That does not seem right; I would expect the raw option to provide the
complete body.

This will mean a change to the way defaults are handled.

I think this needs more discussion.

It could take a while to resolve the issues and debug the code, so I
think it will have to wait for a later version of JMeter; I've held up
the current one long enough!

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

[CANCELLED][VOTE] Release JMeter 2.5.1 RC2

[sebb]

Sorry, but we have found some problems with the way that 2.5.1 RC2
handles the stopping of tests, as well as an error in the HttpClient4
sampler.

We need to fix the bugs and create a new RC.

On 25 September 2011 13:01, Milamber  wrote:
> Hello,
>
> The second release candidate for JMeter 2.5.1 has been prepared, and your
> votes are solicited.
>
> This release fixes mainly some bugs appeared since JMeter 2.5, but
> contains few improvements.
>
> Tests (load tests or functional tests) with JVM 5/6/7 on
> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
> 4.1 request, Http request with parallels embedded resources, View
> results tree, WebServices (SOAP) request, Async sample sending mode, etc)
>
> List of changes:
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs/changes.html
>
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version is targeted at
> Java 1.5+.
>
> Archives/hashes/sigs and RAT report:
>
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/dist
>
> MD5 hashes of archives for this vote:
>
> abc0d327d19f3e138955de5082c000b3 *jakarta-jmeter-2.5.1.tgz
> 3e69786253880a1293e245519cba4ad3 *jakarta-jmeter-2.5.1.zip
> cdc73f4db83dee52d216c74c2a323721 *jakarta-jmeter-2.5.1_src.tgz
> 3f294979e6c696bba91d62c2ec5f0473 *jakarta-jmeter-2.5.1_src.zip
>
> Site Docs are here:
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs
>
> Tag:
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC2 (r1175373)
>
> Keys are here:
> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
> also
> http://people.apache.org/~milamber/
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 2.5 requires Java 1.5 or later.
>
> Note that there is a bug in Java on some Linux systems that manifests
> itself as the following error when running the test cases or JMeter itself:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
> This does not affect JMeter operation.
>
>
> All feedback (and votes!) welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0   OK, but
> [  ] -1   I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC2

[sebb]

On 26 September 2011 21:45, Oleg Kalnichevski  wrote:
> On Mon, 2011-09-26 at 21:00 +0100, sebb wrote:
>
> ...
>
>> >
>> > I am seeing this error while trying to get all requisite dependencies
>> > with 'ant download_jars'
>> >
>> > _get_jarfile:
>> >
>> > _get_zipfile:
>> >      [get] Getting:
>> > http://prdownloads.sourceforge.net/htmlparser/HTMLParser-2.0-SNAPSHOT-bin.zip
>> >      [get]
>> > To: 
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build/HTMLParser-2.0-SNAPSHOT-bin.zip
>> >      [get] Not modified - so not downloaded
>> >
>> > BUILD FAILED
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2202: The following
>> > error occurred while executing this line:
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2172: The following
>> > error occurred while executing this line:
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2064: The following
>> > error occurred while executing this line:
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2093: The following
>> > error occurred while executing this line:
>> > /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2101: The 
>> > type doesn't support the nested "mapper" element.
>> >
>> > Is this a common issue?
>>
>> Not seen it before.
>>
>> What version of Ant are you using?
>>
>
> Good call. Problem solved by upgrading to Ant 1.8.2

Good - what were you using?
It might make sense for the Ant script to check for a minimum version.

> Now I am getting a batchtest failure. I guess this has something to do
> with my network configuration. I am not sure how severe this failure is.

Yes, it looks like the default host name "ubuntu" is being resolved as
a loopback address.

This causes problems for client-server mode.

Though client-server mode would probably work for the unit test, it
would not work if the client and server were on different nodes, so
the server refuses to start.

> Otherwise, building from source worked and all unit tests passed for me.

Great, thanks for all the tests.

Unfortunately, we have found some bugs in the handling of thread
interrupts, which mean we will have to cancel the RC vote.

> batchtest:
>     [echo] Starting BatchTestLocal using -X
>   [jmeter] Created the tree successfully using
> testfiles/BatchTestLocal.jmx
>   [jmeter] Starting the test @ Mon Sep 26 22:32:52 CEST 2011
> (1317069172892)
>   [jmeter] Waiting for possible shutdown message on port 4445
>   [jmeter] Tidying up ...    @ Mon Sep 26 22:33:28 CEST 2011
> (1317069208987)
>   [jmeter] ... end of run
>     [echo] BatchTestLocal output files compared OK
>
> batchtestserver:
>   [server] Created remote object: UnicastServerRef [liveRef:
> [endpoint:[127.0.1.1:36010](local),objID:[6b66acdf:132a7714332:-7fff,
> -2840269162966433815]]]
>   [server] An error occurred: Cannot start. ubuntu is a loopback
> address.
>   [server] Server failed to start: java.rmi.RemoteException: Cannot
> start. ubuntu is a loopback address.
>
> batchtest:
>     [echo] Starting BatchTestLocal using -Rlocalhost:2099
>   [server] Java Result: 1
>   [client] Created the tree successfully using
> testfiles/BatchTestLocal.jmx
>   [client] Configuring remote engine for localhost:2099
>   [client] Failed to configure localhost:2099
>   [client] No remote engines were started.
>   [client] Failure connecting to remote host: localhost:2099
> java.rmi.ConnectException: Connection refused to host: localhost; nested
> exception is:
>   [client]     java.net.ConnectException: Connection refused
>     [echo] BatchTestLocal output files compared OK
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC2

[sebb]

On 26 September 2011 20:04, Oleg Kalnichevski  wrote:
> On Sun, 2011-09-25 at 12:01 +, Milamber wrote:
>> Hello,
>>
>> The second release candidate for JMeter 2.5.1 has been prepared, and your
>> votes are solicited.
>>
>> This release fixes mainly some bugs appeared since JMeter 2.5, but
>> contains few improvements.
>>
>> Tests (load tests or functional tests) with JVM 5/6/7 on
>> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
>> 4.1 request, Http request with parallels embedded resources, View
>> results tree, WebServices (SOAP) request, Async sample sending mode, etc)
>>
>> List of changes:
>> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs/changes.html
>>
>>
>> JMeter is a Java desktop application designed to load test functional
>> behavior and measure performance. The current version is targeted at
>> Java 1.5+.
>>
>> Archives/hashes/sigs and RAT report:
>>
>> http://people.apache.org/~milamber/jmeter-2.5.1RC2/dist
>>
>> MD5 hashes of archives for this vote:
>>
>> abc0d327d19f3e138955de5082c000b3 *jakarta-jmeter-2.5.1.tgz
>> 3e69786253880a1293e245519cba4ad3 *jakarta-jmeter-2.5.1.zip
>> cdc73f4db83dee52d216c74c2a323721 *jakarta-jmeter-2.5.1_src.tgz
>> 3f294979e6c696bba91d62c2ec5f0473 *jakarta-jmeter-2.5.1_src.zip
>>
>> Site Docs are here:
>> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs
>>
>> Tag:
>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC2 (r1175373)
>>
>> Keys are here:
>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>> also
>> http://people.apache.org/~milamber/
>>
>> N.B.
>> To download the dependencies: "ant download_jars"
>>
>> To create the jars and test JMeter: "ant package test".
>>
>> JMeter 2.5 requires Java 1.5 or later.
>>
>> Note that there is a bug in Java on some Linux systems that manifests
>> itself as the following error when running the test cases or JMeter itself:
>>
>>  [java] WARNING: Couldn't flush user prefs:
>>  java.util.prefs.BackingStoreException:
>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>
>> This does not affect JMeter operation.
>>
>>
>> All feedback (and votes!) welcome.
>>
>> [  ] +1  I support this release
>> [  ] +0  I am OK with this release
>> [  ] -0   OK, but
>> [  ] -1   I do not support this release (please indicate why)
>>
>> The vote will remain open for at least 72 hours.
>>
>> Note: If the vote passes, the intention is to release the archive files
>> and rename the RC tag as the release tag.
>>
>> Thanks in advance!
>>
>> Milamber
>>
>
>
> I am seeing this error while trying to get all requisite dependencies
> with 'ant download_jars'
>
> _get_jarfile:
>
> _get_zipfile:
>      [get] Getting:
> http://prdownloads.sourceforge.net/htmlparser/HTMLParser-2.0-SNAPSHOT-bin.zip
>      [get]
> To: 
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build/HTMLParser-2.0-SNAPSHOT-bin.zip
>      [get] Not modified - so not downloaded
>
> BUILD FAILED
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2202: The following
> error occurred while executing this line:
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2172: The following
> error occurred while executing this line:
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2064: The following
> error occurred while executing this line:
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2093: The following
> error occurred while executing this line:
> /home/oleg/Downloads/jakarta-jmeter-2.5.1/build.xml:2101: The 
> type doesn't support the nested "mapper" element.
>
> Is this a common issue?

Not seen it before.

What version of Ant are you using?

> Oleg
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

2011/9/26 Stéphane Hoblingre :
> Yes true, the bug happens also with the DummySampler of our plugins (
> http://code.google.com/p/jmeter-plugins/) and appeared from 2.5.1 only.

Not sure that has the same cause; as far as I can tell DummySampler
does not support interrupt(), which is the origin of the deadlocks in
HC4.

Please could you attach a thread dump and jmeter log file to the bug?

> Stef
>
> On Mon, Sep 26, 2011 at 9:18 PM, sebb  wrote:
>
>> On 26 September 2011 09:32, Philippe Mouawad 
>> wrote:
>> > Hello I attached all infos on ISSUE:
>> >
>> >   - Test case
>> >   - Log file in DEBUG
>> >   - Thread Dump
>> >
>> > Note that I reproduced it every time with what I described in issue.
>>
>> I can also now reproduce the deadlock easily with HC4 and mirror server.
>> I was using a simplified test case that had caused the deadlock prior
>> to my fix, but was not causing the dealock afterwards.
>> This was because it only had one sample - that had been sufficient
>> originally, but was not sufficient later.
>> Sorry, that's my fault; should have stayed with the original test case.
>>
>> The fix I made to HC4 - overriding the retryRequest() method -
>> actually only works for a single sampler, because the "interrupted"
>> variable is fetched from the class instance that was used to create
>> the override. I introduced the "interrupted" variable, because the fix
>> from https://issues.apache.org/jira/browse/HTTPCLIENT-1120 did not
>> seem to work. I need to look at that again. This is needed to stop HC4
>> from retrying aborted requests, which I think is a separate issue from
>> the deadlocks.
>>
>> I now think there's a subtle bug in JMeterThread.
>> I had expected the interrupt to complete, and then the sample to
>> complete, thus the shutdown code would run after the interrupt code.
>> However, it looks as though the sample can complete before the
>> interrupt method returns.
>> This allows the thread to run the shutdown code whilst the interrupt
>> is still in progress.
>>
>> In turn this triggers the deadlock issue in HC4, but could equally
>> cause issues with other samplers.
>> The code needs to ensure that shutdown cannot happen whilst an
>> interrupt is in progress.
>>
>> I'll commit a fix to SVN ASAP.
>>
>> Sorry Milamber, but I think we need to cancel this RC vote.
>>
>> > I also attached a patch that works on my tests.
>> > I let you check.
>> >
>> > Regards
>> > Philippe Mouawad
>> >
>> > On Sun, Sep 25, 2011 at 1:46 PM, sebb  wrote:
>> >
>> >> On 25 September 2011 12:22, sebb  wrote:
>> >> > On 25 September 2011 01:45, Milamber  wrote:
>> >> >>
>> >> >>
>> >> >> Le 25/09/2011 00:08, sebb a ecrit :
>> >> >>> On 25 September 2011 01:03, Milamber  wrote:
>> >> >>>
>> >> >>>>
>> >> >>>> Le 23/09/2011 23:38, sebb a ecrit :
>> >> >>>>
>> >> >>>>> On 23 September 2011 23:17, sebb  wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> On 23 September 2011 18:14, sebb  wrote:
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>> On 23 September 2011 17:15, Milamber 
>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>> Hello,
>> >> >>>>>>>>
>> >> >>>>>>>> It's seems all open bugs with 2.5.1RC1 are closed.
>> >> >>>>>>>> I will start the RC2 process tomorrow.
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>> OK.
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>> Just found a problem with the HC4 retries - they prevent StopTest
>> >> from working.
>> >> >>>>>>
>> >> >>>>>> There's a deadlock in the code that prevents the interrupt from
>> >> >>>>>> working when there is a retry.
>> >> >>>>>> [At the back of my mind, I thought there was another reason why I
>> >> set
>> >>

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 26 September 2011 09:32, Philippe Mouawad  wrote:
> Hello I attached all infos on ISSUE:
>
>   - Test case
>   - Log file in DEBUG
>   - Thread Dump
>
> Note that I reproduced it every time with what I described in issue.

I can also now reproduce the deadlock easily with HC4 and mirror server.
I was using a simplified test case that had caused the deadlock prior
to my fix, but was not causing the dealock afterwards.
This was because it only had one sample - that had been sufficient
originally, but was not sufficient later.
Sorry, that's my fault; should have stayed with the original test case.

The fix I made to HC4 - overriding the retryRequest() method -
actually only works for a single sampler, because the "interrupted"
variable is fetched from the class instance that was used to create
the override. I introduced the "interrupted" variable, because the fix
from https://issues.apache.org/jira/browse/HTTPCLIENT-1120 did not
seem to work. I need to look at that again. This is needed to stop HC4
from retrying aborted requests, which I think is a separate issue from
the deadlocks.

I now think there's a subtle bug in JMeterThread.
I had expected the interrupt to complete, and then the sample to
complete, thus the shutdown code would run after the interrupt code.
However, it looks as though the sample can complete before the
interrupt method returns.
This allows the thread to run the shutdown code whilst the interrupt
is still in progress.

In turn this triggers the deadlock issue in HC4, but could equally
cause issues with other samplers.
The code needs to ensure that shutdown cannot happen whilst an
interrupt is in progress.

I'll commit a fix to SVN ASAP.

Sorry Milamber, but I think we need to cancel this RC vote.

> I also attached a patch that works on my tests.
> I let you check.
>
> Regards
> Philippe Mouawad
>
> On Sun, Sep 25, 2011 at 1:46 PM, sebb  wrote:
>
>> On 25 September 2011 12:22, sebb  wrote:
>> > On 25 September 2011 01:45, Milamber  wrote:
>> >>
>> >>
>> >> Le 25/09/2011 00:08, sebb a ecrit :
>> >>> On 25 September 2011 01:03, Milamber  wrote:
>> >>>
>> >>>>
>> >>>> Le 23/09/2011 23:38, sebb a ecrit :
>> >>>>
>> >>>>> On 23 September 2011 23:17, sebb  wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On 23 September 2011 18:14, sebb  wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> On 23 September 2011 17:15, Milamber  wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Hello,
>> >>>>>>>>
>> >>>>>>>> It's seems all open bugs with 2.5.1RC1 are closed.
>> >>>>>>>> I will start the RC2 process tomorrow.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>> OK.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Just found a problem with the HC4 retries - they prevent StopTest
>> from working.
>> >>>>>>
>> >>>>>> There's a deadlock in the code that prevents the interrupt from
>> >>>>>> working when there is a retry.
>> >>>>>> [At the back of my mind, I thought there was another reason why I
>> set
>> >>>>>> the retry count to 0!]
>> >>>>>>
>> >>>>>> Shutdown works fine, because it does not try to interrupt the
>> sample.
>> >>>>>>
>> >>>>>> I think there's a work-round I can use in the JMeter code, but I
>> don't
>> >>>>>> think we should release the code as is.
>> >>>>>>
>> >>>>>> Sorry.
>> >>>>>>
>> >>>>>> The Java and HC3.1 samplers work fine; it's only HC4 that has the
>> problem.
>> >>>>>>
>> >>>>>> I'll let you know if there's a solution ASAP.
>> >>>>>>
>> >>>>>>
>> >>>>> URL: http://svn.apache.org/viewvc?rev=1175069&view=rev
>> >>>>> Log:
>> >>>>> Temporary hack to work round
>> >>>>>
>> >>>>>
>> >>>> This temporary hack don't always work for me. When I call Stop command
>> >>>> at the beginning of a test (before en

Re: [VOTE] Release JMeter 2.5.1 RC2

[sebb]

On 25 September 2011 13:01, Milamber  wrote:
> Hello,
>
> The second release candidate for JMeter 2.5.1 has been prepared, and your
> votes are solicited.
>
> This release fixes mainly some bugs appeared since JMeter 2.5, but
> contains few improvements.
>
> Tests (load tests or functional tests) with JVM 5/6/7 on
> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
> 4.1 request, Http request with parallels embedded resources, View
> results tree, WebServices (SOAP) request, Async sample sending mode, etc)
>
> List of changes:
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs/changes.html
>
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version is targeted at
> Java 1.5+.
>
> Archives/hashes/sigs and RAT report:
>
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/dist
>
> MD5 hashes of archives for this vote:
>
> abc0d327d19f3e138955de5082c000b3 *jakarta-jmeter-2.5.1.tgz
> 3e69786253880a1293e245519cba4ad3 *jakarta-jmeter-2.5.1.zip
> cdc73f4db83dee52d216c74c2a323721 *jakarta-jmeter-2.5.1_src.tgz
> 3f294979e6c696bba91d62c2ec5f0473 *jakarta-jmeter-2.5.1_src.zip
>
> Site Docs are here:
> http://people.apache.org/~milamber/jmeter-2.5.1RC2/docs
>
> Tag:
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC2 (r1175373)
>
> Keys are here:
> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
> also
> http://people.apache.org/~milamber/
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 2.5 requires Java 1.5 or later.
>
> Note that there is a bug in Java on some Linux systems that manifests
> itself as the following error when running the test cases or JMeter itself:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
> This does not affect JMeter operation.
>
>
> All feedback (and votes!) welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0   OK, but
> [  ] -1   I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!

All looks OK except for some minor differences between the source
archives and the SVN tag.

The xml files under xdocs/usermanual disagree for me, because the
$Date: $ SVN keyword is resolved using the default Locale.
My Locale is English, whereas the files were built with a French Locale.
So when I check out the SVN tag, I see English days and months, but
the source archive contains French days and months.

I don't think this is a blocker.

The LICENSE file is also slighty different in the zip archives. This
is because it was treated as a UTF-8 file, but in fact one of the
characters is not UTF-8, so the Ant filter task does not copy the
character exactly.

I don't think this is a blocker either.

I'll fix the issues in SVN so they won't happen in future releases.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1175371 - /jakarta/jmeter/tags/v2_5_1_RC2/

[sebb]

On 25 September 2011 12:22,   wrote:
> Author: milamber
> Date: Sun Sep 25 11:22:54 2011
> New Revision: 1175371
>
> URL: http://svn.apache.org/viewvc?rev=1175371&view=rev
> Log:
> Forget to add notice for the deadlock pb.
>
> Removed:
>    jakarta/jmeter/tags/v2_5_1_RC2/

Ideally, tags should be immutable.

i.e. once created, should never be re-created.

This is essential once the tag is used in an RC vote; if the tag was
not yet actually used for a vote it's slightly less important, but
it's still better not to recreate them ever.

Tags are very cheap, so it does not matter if the release vote uses tag RC1001 !

>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 25 September 2011 12:22, sebb  wrote:
> On 25 September 2011 01:45, Milamber  wrote:
>>
>>
>> Le 25/09/2011 00:08, sebb a ecrit :
>>> On 25 September 2011 01:03, Milamber  wrote:
>>>
>>>>
>>>> Le 23/09/2011 23:38, sebb a ecrit :
>>>>
>>>>> On 23 September 2011 23:17, sebb  wrote:
>>>>>
>>>>>
>>>>>> On 23 September 2011 18:14, sebb  wrote:
>>>>>>
>>>>>>
>>>>>>> On 23 September 2011 17:15, Milamber  wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> It's seems all open bugs with 2.5.1RC1 are closed.
>>>>>>>> I will start the RC2 process tomorrow.
>>>>>>>>
>>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>>
>>>>>> Just found a problem with the HC4 retries - they prevent StopTest from 
>>>>>> working.
>>>>>>
>>>>>> There's a deadlock in the code that prevents the interrupt from
>>>>>> working when there is a retry.
>>>>>> [At the back of my mind, I thought there was another reason why I set
>>>>>> the retry count to 0!]
>>>>>>
>>>>>> Shutdown works fine, because it does not try to interrupt the sample.
>>>>>>
>>>>>> I think there's a work-round I can use in the JMeter code, but I don't
>>>>>> think we should release the code as is.
>>>>>>
>>>>>> Sorry.
>>>>>>
>>>>>> The Java and HC3.1 samplers work fine; it's only HC4 that has the 
>>>>>> problem.
>>>>>>
>>>>>> I'll let you know if there's a solution ASAP.
>>>>>>
>>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1175069&view=rev
>>>>> Log:
>>>>> Temporary hack to work round
>>>>>
>>>>>
>>>> This temporary hack don't always work for me. When I call Stop command
>>>> at the beginning of a test (before end of ramp up), I have the same
>>>> deadlock.
>>>> (but sometimes the stop works fine.)
>>>>
>>> Can you do a thread dump when this happens?
>>>
>>
>>
>> Found one Java-level deadlock:
>> =
>> "Thread-205":
>>  waiting to lock monitor 0x00d0bf78 (object 0xe2c89ba8,
>> a org.apache.http.impl.conn.SingleClientConnManager),
>>  which is held by "Thread Group 1-1"
>> "Thread Group 1-1":
>>  waiting to lock monitor 0x0205e638 (object 0xe3425510,
>> a org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter),
>>  which is held by "Thread-205"
>>
>> Java stack information for the threads listed above:
>> ===
>> "Thread-205":
>>    at
>> org.apache.http.impl.conn.SingleClientConnManager.releaseConnection(SingleClientConnManager.java:258)
>>    - waiting to lock <0xe2c89ba8> (a
>> org.apache.http.impl.conn.SingleClientConnManager)
>>    at
>> org.apache.http.impl.conn.AbstractClientConnAdapter.abortConnection(AbstractClientConnAdapter.java:323)
>>    - locked <0xe3425510> (a
>> org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter)
>>    at
>> org.apache.http.client.methods.HttpRequestBase.abort(HttpRequestBase.java:161)
>>    at
>> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.interrupt(HTTPHC4Impl.java:1087)
>>    at
>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.interrupt(HTTPSamplerProxy.java:77)
>>    at
>> org.apache.jmeter.threads.JMeterThread.interrupt(JMeterThread.java:580)
>>    at
>> org.apache.jmeter.engine.StandardJMeterEngine.tellThreadsToStop(StandardJMeterEngine.java:552)
>>    at
>> org.apache.jmeter.engine.StandardJMeterEngine.access$300(StandardJMeterEngine.java:58)
>>    at
>> org.apache.jmeter.engine.StandardJMeterEngine$StopTest.run(StandardJMeterEngine.java:284)
>>    at java.lang.Thread.run(Thread.java:722)
>> "Thread Group 1-1":
>>    at
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.detach(AbstractPooledConnAdapter.java:106)
>>    - waiting to lock <0xe34

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 25 September 2011 01:45, Milamber  wrote:
>
>
> Le 25/09/2011 00:08, sebb a ecrit :
>> On 25 September 2011 01:03, Milamber  wrote:
>>
>>>
>>> Le 23/09/2011 23:38, sebb a ecrit :
>>>
>>>> On 23 September 2011 23:17, sebb  wrote:
>>>>
>>>>
>>>>> On 23 September 2011 18:14, sebb  wrote:
>>>>>
>>>>>
>>>>>> On 23 September 2011 17:15, Milamber  wrote:
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> It's seems all open bugs with 2.5.1RC1 are closed.
>>>>>>> I will start the RC2 process tomorrow.
>>>>>>>
>>>>>>>
>>>>>> OK.
>>>>>>
>>>>>>
>>>>> Just found a problem with the HC4 retries - they prevent StopTest from 
>>>>> working.
>>>>>
>>>>> There's a deadlock in the code that prevents the interrupt from
>>>>> working when there is a retry.
>>>>> [At the back of my mind, I thought there was another reason why I set
>>>>> the retry count to 0!]
>>>>>
>>>>> Shutdown works fine, because it does not try to interrupt the sample.
>>>>>
>>>>> I think there's a work-round I can use in the JMeter code, but I don't
>>>>> think we should release the code as is.
>>>>>
>>>>> Sorry.
>>>>>
>>>>> The Java and HC3.1 samplers work fine; it's only HC4 that has the problem.
>>>>>
>>>>> I'll let you know if there's a solution ASAP.
>>>>>
>>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1175069&view=rev
>>>> Log:
>>>> Temporary hack to work round
>>>>
>>>>
>>> This temporary hack don't always work for me. When I call Stop command
>>> at the beginning of a test (before end of ramp up), I have the same
>>> deadlock.
>>> (but sometimes the stop works fine.)
>>>
>> Can you do a thread dump when this happens?
>>
>
>
> Found one Java-level deadlock:
> =
> "Thread-205":
>  waiting to lock monitor 0x00d0bf78 (object 0xe2c89ba8,
> a org.apache.http.impl.conn.SingleClientConnManager),
>  which is held by "Thread Group 1-1"
> "Thread Group 1-1":
>  waiting to lock monitor 0x0205e638 (object 0xe3425510,
> a org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter),
>  which is held by "Thread-205"
>
> Java stack information for the threads listed above:
> ===
> "Thread-205":
>    at
> org.apache.http.impl.conn.SingleClientConnManager.releaseConnection(SingleClientConnManager.java:258)
>    - waiting to lock <0xe2c89ba8> (a
> org.apache.http.impl.conn.SingleClientConnManager)
>    at
> org.apache.http.impl.conn.AbstractClientConnAdapter.abortConnection(AbstractClientConnAdapter.java:323)
>    - locked <0xe3425510> (a
> org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter)
>    at
> org.apache.http.client.methods.HttpRequestBase.abort(HttpRequestBase.java:161)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.interrupt(HTTPHC4Impl.java:1087)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.interrupt(HTTPSamplerProxy.java:77)
>    at
> org.apache.jmeter.threads.JMeterThread.interrupt(JMeterThread.java:580)
>    at
> org.apache.jmeter.engine.StandardJMeterEngine.tellThreadsToStop(StandardJMeterEngine.java:552)
>    at
> org.apache.jmeter.engine.StandardJMeterEngine.access$300(StandardJMeterEngine.java:58)
>    at
> org.apache.jmeter.engine.StandardJMeterEngine$StopTest.run(StandardJMeterEngine.java:284)
>    at java.lang.Thread.run(Thread.java:722)
> "Thread Group 1-1":
>    at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.detach(AbstractPooledConnAdapter.java:106)
>    - waiting to lock <0xe3425510> (a
> org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter)
>    at
> org.apache.http.impl.conn.SingleClientConnManager.shutdown(SingleClientConnManager.java:342)
>    - locked <0xe2c89ba8> (a
> org.apache.http.impl.conn.SingleClientConnManager)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.closeThreadLocalConnections(HTTPHC4Impl.java:1072)
>    at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Im

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 25 September 2011 01:03, Milamber  wrote:
>
>
> Le 23/09/2011 23:38, sebb a ecrit :
>> On 23 September 2011 23:17, sebb  wrote:
>>
>>> On 23 September 2011 18:14, sebb  wrote:
>>>
>>>> On 23 September 2011 17:15, Milamber  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> It's seems all open bugs with 2.5.1RC1 are closed.
>>>>> I will start the RC2 process tomorrow.
>>>>>
>>>> OK.
>>>>
>>> Just found a problem with the HC4 retries - they prevent StopTest from 
>>> working.
>>>
>>> There's a deadlock in the code that prevents the interrupt from
>>> working when there is a retry.
>>> [At the back of my mind, I thought there was another reason why I set
>>> the retry count to 0!]
>>>
>>> Shutdown works fine, because it does not try to interrupt the sample.
>>>
>>> I think there's a work-round I can use in the JMeter code, but I don't
>>> think we should release the code as is.
>>>
>>> Sorry.
>>>
>>> The Java and HC3.1 samplers work fine; it's only HC4 that has the problem.
>>>
>>> I'll let you know if there's a solution ASAP.
>>>
>> URL: http://svn.apache.org/viewvc?rev=1175069&view=rev
>> Log:
>> Temporary hack to work round
>>
>
> This temporary hack don't always work for me. When I call Stop command
> at the beginning of a test (before end of ramp up), I have the same
> deadlock.
> (but sometimes the stop works fine.)

Can you do a thread dump when this happens?


> I thinks we must release the version 2.5.1 to correct the others bugs
> already fixed, and add a known problem in documentation for this deadlook?

Yes, that sounds reasonable. It's not clear yet whether this is a
JMeter or HC4 problem; nor is it clear what to do to fix it.
Anyway, it only occurs sometimes, and it only occurs when trying to
stop the test - so the GUI can just be exitted.

> Milamber
>
>
>
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1120
>> Note: copying the code from the patch did not seem to work; it looks
>> like isAborted() was not set.
>> Hopefully that is fixed in 4.1.3
>>
>> That seems to have fixed it for me, or at least improved matters.
>>
>> Still needs more testing to see if the deadlock I found - reported in
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1127 - can still
>> occur.
>>
>> BTW, I found the deadlock testing against the mirror server.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 23 September 2011 23:17, sebb  wrote:
> On 23 September 2011 18:14, sebb  wrote:
>> On 23 September 2011 17:15, Milamber  wrote:
>>> Hello,
>>>
>>> It's seems all open bugs with 2.5.1RC1 are closed.
>>> I will start the RC2 process tomorrow.
>>
>> OK.
>
> Just found a problem with the HC4 retries - they prevent StopTest from 
> working.
>
> There's a deadlock in the code that prevents the interrupt from
> working when there is a retry.
> [At the back of my mind, I thought there was another reason why I set
> the retry count to 0!]
>
> Shutdown works fine, because it does not try to interrupt the sample.
>
> I think there's a work-round I can use in the JMeter code, but I don't
> think we should release the code as is.
>
> Sorry.
>
> The Java and HC3.1 samplers work fine; it's only HC4 that has the problem.
>
> I'll let you know if there's a solution ASAP.

URL: http://svn.apache.org/viewvc?rev=1175069&view=rev
Log:
Temporary hack to work round
https://issues.apache.org/jira/browse/HTTPCLIENT-1120
Note: copying the code from the patch did not seem to work; it looks
like isAborted() was not set.
Hopefully that is fixed in 4.1.3

That seems to have fixed it for me, or at least improved matters.

Still needs more testing to see if the deadlock I found - reported in
https://issues.apache.org/jira/browse/HTTPCLIENT-1127 - can still
occur.

BTW, I found the deadlock testing against the mirror server.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 23 September 2011 18:14, sebb  wrote:
> On 23 September 2011 17:15, Milamber  wrote:
>> Hello,
>>
>> It's seems all open bugs with 2.5.1RC1 are closed.
>> I will start the RC2 process tomorrow.
>
> OK.

Just found a problem with the HC4 retries - they prevent StopTest from working.

There's a deadlock in the code that prevents the interrupt from
working when there is a retry.
[At the back of my mind, I thought there was another reason why I set
the retry count to 0!]

Shutdown works fine, because it does not try to interrupt the sample.

I think there's a work-round I can use in the JMeter code, but I don't
think we should release the code as is.

Sorry.

The Java and HC3.1 samplers work fine; it's only HC4 that has the problem.

I'll let you know if there's a solution ASAP.

> I'm working on a new Asynchronous Sample Listener for client-server mode.
>
> If I get that finished tonight I'll commit it.

I've committed it.

> It should not cause any other issues as the code is mostly new, and is
> optional - if there are problems, it does not have to be used.
>
>> Milamber
>>
>> Le 22/09/2011 22:53, Milamber a ecrit :
>>> Hello,
>>>
>>> The first release candidate for JMeter 2.5.1 has been prepared, and your
>>> votes are solicited.
>>>
>>> This release fixes mainly some bugs appeared since JMeter 2.5, but
>>> contains few improvements.
>>>
>>> Tests (load tests or functional tests) with JVM 5/6/7 on
>>> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
>>> 4.1 request, Http request with parallels embedded resources, View
>>> results tree, WebServices (SOAP) request, etc)
>>> List of changes:
>>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html
>>>
>>>
>>> JMeter is a Java desktop application designed to load test functional
>>> behavior and measure performance. The current version is targeted at
>>> Java 1.5+.
>>>
>>> Archives/hashes/sigs and RAT report:
>>>
>>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist
>>>
>>> MD5 hashes of archives for this vote:
>>>
>>> c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz
>>> 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip
>>> c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz
>>> 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip
>>>
>>> Site Docs are here:
>>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs
>>>
>>> Tag:
>>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1 (r1174408)
>>>
>>> Keys are here:
>>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>>> also
>>> http://people.apache.org/~milamber/
>>>
>>> N.B.
>>> To download the dependencies: "ant download_jars"
>>>
>>> To create the jars and test JMeter: "ant package test".
>>>
>>> JMeter 2.5 requires Java 1.5 or later.
>>>
>>> Note that there is a bug in Java on some Linux systems that manifests
>>> itself as the following error when running the test cases or JMeter itself:
>>>
>>>  [java] WARNING: Couldn't flush user prefs:
>>>  java.util.prefs.BackingStoreException:
>>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>>
>>> This does not affect JMeter operation.
>>>
>>>
>>> All feedback (and votes!) welcome.
>>>
>>> [  ] +1  I support this release
>>> [  ] +0  I am OK with this release
>>> [  ] -0   OK, but
>>> [  ] -1   I do not support this release (please indicate why)
>>>
>>> The vote will remain open for at least 72 hours.
>>>
>>> Note: If the vote passes, the intention is to release the archive files
>>> and rename the RC tag as the release tag.
>>>
>>> Thanks in advance!
>>>
>>> Milamber
>>>
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: request to be added to the contributors list

[sebb]

On 23 September 2011 20:49, Franco Sabadini  wrote:
> Hi,
>
> I helped on resolving *Bug
> 30563*and I
> wanted to add myself to the contributors list on
> http://wiki.apache.org/jakarta-jmeter/JMeterCommitters but I can't seem to
> be able to edit it, can u add me or give me the needed permissions? My wiki
> username is FrancoSabadini.

Try now.

> Thanks.
>
>
> Franco
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1174891 - in /jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler: HTTPHC3Impl.java HTTPHC4Impl.java

[sebb]

On 23 September 2011 18:15,   wrote:
> Author: milamber
> Date: Fri Sep 23 17:15:15 2011
> New Revision: 1174891
>
> URL: http://svn.apache.org/viewvc?rev=1174891&view=rev
> Log:
> Change default retry count to 1

Good catch! Sorry, trying to do too much at once, forgot to change the
most important files!

> Modified:
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC3Impl.java
>    
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC3Impl.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC3Impl.java?rev=1174891&r1=1174890&r2=1174891&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC3Impl.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC3Impl.java
>  Fri Sep 23 17:15:15 2011
> @@ -89,8 +89,8 @@ public class HTTPHC3Impl extends HTTPHCA
>
>     private static final Logger log = LoggingManager.getLoggerForClass();
>
> -    /** retry count to be used (default 3); 0 = disable retries */
> -    private static final int RETRY_COUNT = 
> JMeterUtils.getPropDefault("httpclient3.retrycount", 3);
> +    /** retry count to be used (default 1); 0 = disable retries */
> +    private static final int RETRY_COUNT = 
> JMeterUtils.getPropDefault("httpclient3.retrycount", 1);
>
>     private static final String HTTP_AUTHENTICATION_PREEMPTIVE = 
> "http.authentication.preemptive"; // $NON-NLS-1$
>
>
> Modified: 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
> URL: 
> http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java?rev=1174891&r1=1174890&r2=1174891&view=diff
> ==
> --- 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
>  (original)
> +++ 
> jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
>  Fri Sep 23 17:15:15 2011
> @@ -111,8 +111,8 @@ public class HTTPHC4Impl extends HTTPHCA
>
>     private static final Logger log = LoggingManager.getLoggerForClass();
>
> -    /** retry count to be used; defaults to 0 = disable retries */
> -    private static final int RETRY_COUNT = 
> JMeterUtils.getPropDefault("httpclient4.retrycount", 0);
> +    /** retry count to be used (default 1); 0 = disable retries */
> +    private static final int RETRY_COUNT = 
> JMeterUtils.getPropDefault("httpclient4.retrycount", 1);
>
>     private static final String CONTEXT_METRICS = "jmeter_metrics"; // TODO 
> hack, to be removed later
>
>
>
>
> -
> To unsubscribe, e-mail: notifications-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: notifications-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Nightly builds

[sebb]

On 23 September 2011 18:08, Philippe Mouawad  wrote:
> Hello,
> I have a question regarding nightly builds, when are they built ?
> Why for example do we have one with date 09/21 while there has been patches
> yesterday and today ?
>
> Is there some delay ?

The builds are automatically created by Jenkins about once a day, but
are currently manually copied to the nightly build area.

The  last successful Jenkins build is linked from the bottom of the
nightly page.
[Just fixed the link, which was still set up for Hudson]

> Thanks
> Regards
> Philippe Mouawad
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 23 September 2011 17:15, Milamber  wrote:
> Hello,
>
> It's seems all open bugs with 2.5.1RC1 are closed.
> I will start the RC2 process tomorrow.

OK.

I'm working on a new Asynchronous Sample Listener for client-server mode.

If I get that finished tonight I'll commit it.

It should not cause any other issues as the code is mostly new, and is
optional - if there are problems, it does not have to be used.

> Milamber
>
> Le 22/09/2011 22:53, Milamber a ecrit :
>> Hello,
>>
>> The first release candidate for JMeter 2.5.1 has been prepared, and your
>> votes are solicited.
>>
>> This release fixes mainly some bugs appeared since JMeter 2.5, but
>> contains few improvements.
>>
>> Tests (load tests or functional tests) with JVM 5/6/7 on
>> Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
>> 4.1 request, Http request with parallels embedded resources, View
>> results tree, WebServices (SOAP) request, etc)
>> List of changes:
>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html
>>
>>
>> JMeter is a Java desktop application designed to load test functional
>> behavior and measure performance. The current version is targeted at
>> Java 1.5+.
>>
>> Archives/hashes/sigs and RAT report:
>>
>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist
>>
>> MD5 hashes of archives for this vote:
>>
>> c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz
>> 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip
>> c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz
>> 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip
>>
>> Site Docs are here:
>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs
>>
>> Tag:
>> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1 (r1174408)
>>
>> Keys are here:
>> http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>> also
>> http://people.apache.org/~milamber/
>>
>> N.B.
>> To download the dependencies: "ant download_jars"
>>
>> To create the jars and test JMeter: "ant package test".
>>
>> JMeter 2.5 requires Java 1.5 or later.
>>
>> Note that there is a bug in Java on some Linux systems that manifests
>> itself as the following error when running the test cases or JMeter itself:
>>
>>  [java] WARNING: Couldn't flush user prefs:
>>  java.util.prefs.BackingStoreException:
>>  java.lang.IllegalArgumentException: Not supported: indent-number
>>
>> This does not affect JMeter operation.
>>
>>
>> All feedback (and votes!) welcome.
>>
>> [  ] +1  I support this release
>> [  ] +0  I am OK with this release
>> [  ] -0   OK, but
>> [  ] -1   I do not support this release (please indicate why)
>>
>> The vote will remain open for at least 72 hours.
>>
>> Note: If the vote passes, the intention is to release the archive files
>> and rename the RC tag as the release tag.
>>
>> Thanks in advance!
>>
>> Milamber
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1164186 - in /jakarta/jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java xdocs/changes.xml xdocs/usermanual/component_refer

[sebb]

On 23 September 2011 16:28, Milamber  wrote:
>
>
> Le 23/09/2011 14:34, sebb a ecrit :
>> On 23 September 2011 15:20, Milamber  wrote:
>>
>>> Hello,
>>>
>>> I've relaunched some tests with a new SimpleTest.jmx version which
>>> generate an unique URL for each request (in attachment)
>>> I did a analysis with wireshark to find the "retries GET" (same unique
>>> url call 2 times)
>>>
>>> NB "retries GET" means: GET /unique_url at end of TCP conversations
>>> without response, and a new retry GET /unique_url at the begin of TCP
>>> conversations
>>>
>>> Results (with 2.5.1RC1):
>>>
>>> a) Java and HC3.1 (and HC4) have "retries GET"
>>>
>>> b) The load test make ~15745 requests.
>>>
>>> * With Java : 670 "retries GET"
>>>
>>> * With HC3.1 (retrycount default) : 536 "retries GET"
>>>
>>> * With HC4 (retrycount force to 3) : 571 "retries GET"
>>>
>> Were any requests retried *more* than once in any of the implementations?
>> It would be interesting to know if the Java implementation can retry
>> more than once.
>>
>
> 0 request retried more than once for JAVA / HC 3 / HC 4
>
>
>>
>>> I suppose that the retrycount default value to 3 (or 1) is needed for HC4.
>>>
>> For backwards compatibility (and compatibility with HC3), then we
>> should choose 3.
>> I asked on the HC mailing list, and the choice of 3 was arbitrary.
>>
>> For compatibility with Java we should probably set them both to 1.
>>
>> I think 1 might be the best compromise - should catch most errors.
>>
>
> 1 retry count seems the good value from RFC HTTP/1.1 Keep-alive :
> "Clients which assume persistent connections and pipeline immediately
> after connection establishment SHOULD be prepared to retry their
> connection* if the first pipelined attempt fails*. If a client does such
> a retry, it MUST NOT pipeline before it knows the connection is
> persistent. Clients MUST also be prepared to resend their requests if
> the server closes the connection before sending all of the corresponding
> responses. "
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2.2

OK, thanks very much for investigating that.

Default retry count will be set to 1 for HC3 and HC4.

> Milamber
>
>> In any case, we need to document the settings.
>> I'll add some text to component reference shortly.
>>
>>
>>> Milamber
>>>
>>>
>>>
>>> Le 23/09/2011 12:58, sebb a ecrit :
>>>
>>>> Has anyone seen the errors with the Java implementation?
>>>>
>>>> There does not seem to be any documentation [1] on how many retries it
>>>> does, but I have seen something that suggests it normally retries just
>>>> once.
>>>>
>>>> [1] 
>>>> http://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html
>>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1164186 - in /jakarta/jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java xdocs/changes.xml xdocs/usermanual/component_refer

[sebb]

On 23 September 2011 15:20, Milamber  wrote:
> Hello,
>
> I've relaunched some tests with a new SimpleTest.jmx version which
> generate an unique URL for each request (in attachment)
> I did a analysis with wireshark to find the "retries GET" (same unique
> url call 2 times)
>
> NB "retries GET" means: GET /unique_url at end of TCP conversations
> without response, and a new retry GET /unique_url at the begin of TCP
> conversations
>
> Results (with 2.5.1RC1):
>
> a) Java and HC3.1 (and HC4) have "retries GET"
>
> b) The load test make ~15745 requests.
>
> * With Java : 670 "retries GET"
>
> * With HC3.1 (retrycount default) : 536 "retries GET"
>
> * With HC4 (retrycount force to 3) : 571 "retries GET"

Were any requests retried *more* than once in any of the implementations?
It would be interesting to know if the Java implementation can retry
more than once.

> I suppose that the retrycount default value to 3 (or 1) is needed for HC4.

For backwards compatibility (and compatibility with HC3), then we
should choose 3.
I asked on the HC mailing list, and the choice of 3 was arbitrary.

For compatibility with Java we should probably set them both to 1.

I think 1 might be the best compromise - should catch most errors.

In any case, we need to document the settings.
I'll add some text to component reference shortly.

> Milamber
>
>
>
> Le 23/09/2011 12:58, sebb a ecrit :
>> Has anyone seen the errors with the Java implementation?
>>
>> There does not seem to be any documentation [1] on how many retries it
>> does, but I have seen something that suggests it normally retries just
>> once.
>>
>> [1] 
>> http://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1164186 - in /jakarta/jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java xdocs/changes.xml xdocs/usermanual/component_refer

[sebb]

Has anyone seen the errors with the Java implementation?

There does not seem to be any documentation [1] on how many retries it
does, but I have seen something that suggests it normally retries just
once.

[1] 
http://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: svn commit: r1164186 - in /jakarta/jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java xdocs/changes.xml xdocs/usermanual/component_refer

[sebb]

On 23 September 2011 13:29, Philippe Mouawad  wrote:
> Again,
> I just implemented Retry on HTTPHC3.1 setting it to 0 and I get low 0.12%
> error like with HTTP 4.1.
> Do you want me to submit a patch to HTTPHC3.1 ?

Would be useful, thanks.

> Regards
> Philippe
>
>
> On Fri, Sep 23, 2011 at 2:23 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> Don't you think you should keep default to 0 and add same configuration to
>> HTTPHC3 ?
>> Maybe it's a real server issue that is hidden by retry set to 3.
>> Can't we check in Jakarta apache logs to see if these errors are mentionned
>> ?
>>
>> Regards
>> Philippe
>>
>>
>> On Fri, Sep 23, 2011 at 11:12 AM, Milamber  wrote:
>>
>>> Hello,
>>>
>>> (on JMeter 2.5.1RC1)
>>> Don't retry automatically with HC4 sampler seems introduce a bug on load
>>> tests using HC4.
>>>
>>> When you run a load test, some errors "The target server failed to
>>> respond" can appear on response data.
>>>
>>> With wireshark, this error arrives at the end of TCP conversations: the
>>> GET request is sent, but no server response (the connection has been
>>> closed, I suppose).
>>>
>>> If I changes the property httpclient4.retrycount to 3, the load tests
>>> works fine, with no errors.
>>>
>>> This bug is tested on Linux with JVM5/7 and WinXP with JVM7
>>>
>>> Test case is the Simple Test Case on this bugs:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51863
>>>
>>> (Note: no errors with HC3.1)
>>> (Questions: retrycount exists on HC3.1? if yes what default value?)
>>>
>>> Response data
>>> org.apache.http.NoHttpResponseException: The target server failed to
>>> respond
>>>    at
>>>
>>> org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101)
>>>    at
>>>
>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252)
>>>    at
>>>
>>> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
>>>    at
>>>
>>> org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247)
>>>    at
>>>
>>> org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219)
>>>    at
>>>
>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298)
>>>    at
>>>
>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
>>>    at
>>>
>>> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645)
>>>    at
>>>
>>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464)
>>>    at
>>>
>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>>>    at
>>>
>>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
>>>    at
>>>
>>> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265)
>>>    at
>>>
>>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
>>>    at
>>>
>>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010)
>>>    at
>>>
>>> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996)
>>>    at
>>>
>>> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383)
>>>    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276)
>>>    at java.lang.Thread.run(Thread.java:595)
>>> =
>>>
>>> Milamber
>>>
>>> Le 01/09/2011 17:52, s...@apache.org a ecrit :
>>> > Author: sebb
>>> > Date: Thu Sep  1 17:52:41 2011
>>> > New Revision: 1164186
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1164186&view=rev
>>> > Log:
>>> > Don't automatically retry with HttpCLient4 sampler
>>> >
>>> > Modified:
>>> >     jakarta/jmeter/trunk/bin/jmeter.properties
>>> >
>>> jakarta/jmeter/trunk/src/protocol

Re: svn commit: r1164186 - in /jakarta/jmeter/trunk: bin/jmeter.properties src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java xdocs/changes.xml xdocs/usermanual/component_refer

[sebb]

On 23 September 2011 10:12, Milamber  wrote:
> Hello,
>
> (on JMeter 2.5.1RC1)
> Don't retry automatically with HC4 sampler seems introduce a bug on load
> tests using HC4.
>
> When you run a load test, some errors "The target server failed to
> respond" can appear on response data.
>
> With wireshark, this error arrives at the end of TCP conversations: the
> GET request is sent, but no server response (the connection has been
> closed, I suppose).
>
> If I changes the property httpclient4.retrycount to 3, the load tests
> works fine, with no errors.
>
> This bug is tested on Linux with JVM5/7 and WinXP with JVM7
>
> Test case is the Simple Test Case on this bugs:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51863
>
> (Note: no errors with HC3.1)
> (Questions: retrycount exists on HC3.1? if yes what default value?)
>

Looks like the HC3.1 retry count also defaults to 3.

I don't now remember exactly why I overrode the setting.
I vaguely remember seeing some retries in a test I was doing, and
thinking it would be better to know about them.

It is possible to revert to the previous behaviour - just define the
JMeter property:

httpclient4.retrycount=3

Could you retry the test with that setting and see if that fixes the
bahaviour for you?

S.

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

2011/9/23 Stéphane Hoblingre :
> Thanks for the quick response!
> Yes it is a new issue, it was working fine in 2.5.

Thanks for reviewing and reporting it.

It was a side effect of the fix for Bug 51839 - "... end of run"
printed prematurely

Now fixed in SVN.

> Stef
>
> On Fri, Sep 23, 2011 at 3:48 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> I reproduce your issue (not sure it's a new one).
>> I opened https://issues.apache.org/bugzilla/show_bug.cgi?id=51880 and
>> submitted a patch.
>>
>> Can you test to tell if it's OK for you ?
>> Regards
>> Philippe Mouawad
>>
>> 2011/9/23 Stéphane Hoblingre 
>>
>> > One update:
>> > The shutdown command is not working if I invoke it before all the thread
>> > are
>> > started.
>> > eg. If I start 20 thread and call it before the 20 are started, it fails.
>> > If
>> > I call it once the 20 thread are started, it works.
>> > The 'Stop' command works in both cases.
>> >
>> > Regards,
>> >
>> > Stef
>> >
>> > 2011/9/23 Stéphane Hoblingre 
>> >
>> > > Hi,
>> > >
>> > > If I try to stop a running test using "Shutdown", it never stops (even
>> if
>> > > thread count is reduced till 0) and the windows stays open. I have to
>> > close
>> > > it and call stop to have the top left green box back to gray. Can
>> someone
>> > > confirm this?
>> > > JMeter 2.5.1 r1174406, win xp sp3 32bits, jdk 1.6.
>> > >
>> > > Regards,
>> > >
>> > > Stef
>> > >
>> > >
>> > > On Fri, Sep 23, 2011 at 4:37 AM, Peter Lin  wrote:
>> > >
>> > >> +1
>> > >>
>> > >> On Thu, Sep 22, 2011 at 6:53 PM, Milamber 
>> wrote:
>> > >> > Hello,
>> > >> >
>> > >> > The first release candidate for JMeter 2.5.1 has been prepared, and
>> > your
>> > >> > votes are solicited.
>> > >> >
>> > >> > This release fixes mainly some bugs appeared since JMeter 2.5, but
>> > >> > contains few improvements.
>> > >> >
>> > >> > Tests (load tests or functional tests) with JVM 5/6/7 on
>> > >> > Linux/Windows/Mac OS on functionality changes are welcomes
>> (HttpClient
>> > >> > 4.1 request, Http request with parallels embedded resources, View
>> > >> > results tree, WebServices (SOAP) request, etc)
>> > >> > List of changes:
>> > >> >
>> http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html
>> > >> >
>> > >> >
>> > >> > JMeter is a Java desktop application designed to load test
>> functional
>> > >> > behavior and measure performance. The current version is targeted at
>> > >> > Java 1.5+.
>> > >> >
>> > >> > Archives/hashes/sigs and RAT report:
>> > >> >
>> > >> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist
>> > >> >
>> > >> > MD5 hashes of archives for this vote:
>> > >> >
>> > >> > c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz
>> > >> > 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip
>> > >> > c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz
>> > >> > 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip
>> > >> >
>> > >> > Site Docs are here:
>> > >> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs
>> > >> >
>> > >> > Tag:
>> > >> >
>> > http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1(r1174408)
>> > >> >
>> > >> > Keys are here:
>> > >> > http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>> > >> > also
>> > >> > http://people.apache.org/~milamber/
>> > >> >
>> > >> > N.B.
>> > >> > To download the dependencies: "ant download_jars"
>> > >> >
>> > >> > To create the jars and test JMeter: "ant package test".
>> > >> >
>> > >> > JMeter 2.5 requires Java 1.5 or later.
>> > >> >
>> > >> > Note that there is a bug in Java on some Linux systems that
>> manifests
>> > >> > itself as the following error when running the test cases or JMeter
>> > >> itself:
>> > >> >
>> > >> >  [java] WARNING: Couldn't flush user prefs:
>> > >> >  java.util.prefs.BackingStoreException:
>> > >> >  java.lang.IllegalArgumentException: Not supported: indent-number
>> > >> >
>> > >> > This does not affect JMeter operation.
>> > >> >
>> > >> >
>> > >> > All feedback (and votes!) welcome.
>> > >> >
>> > >> > [  ] +1  I support this release
>> > >> > [  ] +0  I am OK with this release
>> > >> > [  ] -0   OK, but
>> > >> > [  ] -1   I do not support this release (please indicate why)
>> > >> >
>> > >> > The vote will remain open for at least 72 hours.
>> > >> >
>> > >> > Note: If the vote passes, the intention is to release the archive
>> > files
>> > >> > and rename the RC tag as the release tag.
>> > >> >
>> > >> > Thanks in advance!
>> > >> >
>> > >> > Milamber
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> -
>> > >> > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> > >> > For additional commands, e-mail: dev-h...@jakarta.apache.org
>> > >> >
>> > >> >
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> > >> For addition

Re: Classloading issue

[sebb]

On 20 September 2011 23:04, Philippe Mouawad  wrote:
> Hello,
> I am implementing a specific RequestView for a particular kind of requests.
> I package my JAR and put it in lib/ext.
> I run JMeter but my RequestView is not found.
> I debugged RequestPanel constructor:
>
> try {
>           classesToAdd =
> JMeterUtils.findClassesThatExtend(RequestView.class);
>       } catch (IOException e1) {
>           // ignored
>       }
>
> This finds my class.
> But this code:
> final RequestView requestView =
>     (RequestView)   Class.forName(clazz).newInstance();
>
> Fails with ClassNotFoundException.
>
> To workaround I changed this to :
> final RequestView requestView = (RequestView)
> Thread.currentThread().getContextClassLoader().loadClass(clazz).newInstance();
> and it worked.
>
> Is there something wrong in my approach or should I submit a patch ?
> This issue also occurs on 2.5

Just for completeness - this has been fixed, it was an issue with
Eclipse configuration, not JMeter.

> I opened issue 51854.
> Thank you
> Regards
> Philippe Mouawad
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
>
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

On 23 September 2011 11:29, sebb  wrote:
> 2011/9/23 Stéphane Hoblingre :
>> One update:
>> The shutdown command is not working if I invoke it before all the thread are
>> started.
>> eg. If I start 20 thread and call it before the 20 are started, it fails. If
>> I call it once the 20 thread are started, it works.
>> The 'Stop' command works in both cases.
>
> The Shutdown command just sets a flag to tell the threads to stop; the
> Stop command actually interrupts the threads.
>
> Probably the flag is not being checked at startup.

Yes, that is the case.

Shutdown does actually work, but it currently waits for the Ramp-Up
delay to complete.
Obviously this is not ideal; will fix it shortly.

>> Regards,
>>
>> Stef
>>
>> 2011/9/23 Stéphane Hoblingre 
>>
>>> Hi,
>>>
>>> If I try to stop a running test using "Shutdown", it never stops (even if
>>> thread count is reduced till 0) and the windows stays open. I have to close
>>> it and call stop to have the top left green box back to gray. Can someone
>>> confirm this?
>>> JMeter 2.5.1 r1174406, win xp sp3 32bits, jdk 1.6.
>>>
>>> Regards,
>>>
>>> Stef
>>>
>>>
>>> On Fri, Sep 23, 2011 at 4:37 AM, Peter Lin  wrote:
>>>
>>>> +1
>>>>
>>>> On Thu, Sep 22, 2011 at 6:53 PM, Milamber  wrote:
>>>> > Hello,
>>>> >
>>>> > The first release candidate for JMeter 2.5.1 has been prepared, and your
>>>> > votes are solicited.
>>>> >
>>>> > This release fixes mainly some bugs appeared since JMeter 2.5, but
>>>> > contains few improvements.
>>>> >
>>>> > Tests (load tests or functional tests) with JVM 5/6/7 on
>>>> > Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
>>>> > 4.1 request, Http request with parallels embedded resources, View
>>>> > results tree, WebServices (SOAP) request, etc)
>>>> > List of changes:
>>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html
>>>> >
>>>> >
>>>> > JMeter is a Java desktop application designed to load test functional
>>>> > behavior and measure performance. The current version is targeted at
>>>> > Java 1.5+.
>>>> >
>>>> > Archives/hashes/sigs and RAT report:
>>>> >
>>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist
>>>> >
>>>> > MD5 hashes of archives for this vote:
>>>> >
>>>> > c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz
>>>> > 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip
>>>> > c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz
>>>> > 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip
>>>> >
>>>> > Site Docs are here:
>>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs
>>>> >
>>>> > Tag:
>>>> > http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1(r1174408)
>>>> >
>>>> > Keys are here:
>>>> > http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>>>> > also
>>>> > http://people.apache.org/~milamber/
>>>> >
>>>> > N.B.
>>>> > To download the dependencies: "ant download_jars"
>>>> >
>>>> > To create the jars and test JMeter: "ant package test".
>>>> >
>>>> > JMeter 2.5 requires Java 1.5 or later.
>>>> >
>>>> > Note that there is a bug in Java on some Linux systems that manifests
>>>> > itself as the following error when running the test cases or JMeter
>>>> itself:
>>>> >
>>>> >  [java] WARNING: Couldn't flush user prefs:
>>>> >  java.util.prefs.BackingStoreException:
>>>> >  java.lang.IllegalArgumentException: Not supported: indent-number
>>>> >
>>>> > This does not affect JMeter operation.
>>>> >
>>>> >
>>>> > All feedback (and votes!) welcome.
>>>> >
>>>> > [  ] +1  I support this release
>>>> > [  ] +0  I am OK with this release
>>>> > [  ] -0   OK, but
>>>> > [  ] -1   I do not support this release (please indicate why)
>>>> >
>>>> > The vote will remain open for at least 72 hours.
>>>> >
>>>> > Note: If the vote passes, the intention is to release the archive files
>>>> > and rename the RC tag as the release tag.
>>>> >
>>>> > Thanks in advance!
>>>> >
>>>> > Milamber
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > -
>>>> > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>> > For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>> >
>>>> >
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>>
>>>>
>>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: [VOTE] Release JMeter 2.5.1 RC1

[sebb]

2011/9/23 Stéphane Hoblingre :
> One update:
> The shutdown command is not working if I invoke it before all the thread are
> started.
> eg. If I start 20 thread and call it before the 20 are started, it fails. If
> I call it once the 20 thread are started, it works.
> The 'Stop' command works in both cases.

The Shutdown command just sets a flag to tell the threads to stop; the
Stop command actually interrupts the threads.

Probably the flag is not being checked at startup.

> Regards,
>
> Stef
>
> 2011/9/23 Stéphane Hoblingre 
>
>> Hi,
>>
>> If I try to stop a running test using "Shutdown", it never stops (even if
>> thread count is reduced till 0) and the windows stays open. I have to close
>> it and call stop to have the top left green box back to gray. Can someone
>> confirm this?
>> JMeter 2.5.1 r1174406, win xp sp3 32bits, jdk 1.6.
>>
>> Regards,
>>
>> Stef
>>
>>
>> On Fri, Sep 23, 2011 at 4:37 AM, Peter Lin  wrote:
>>
>>> +1
>>>
>>> On Thu, Sep 22, 2011 at 6:53 PM, Milamber  wrote:
>>> > Hello,
>>> >
>>> > The first release candidate for JMeter 2.5.1 has been prepared, and your
>>> > votes are solicited.
>>> >
>>> > This release fixes mainly some bugs appeared since JMeter 2.5, but
>>> > contains few improvements.
>>> >
>>> > Tests (load tests or functional tests) with JVM 5/6/7 on
>>> > Linux/Windows/Mac OS on functionality changes are welcomes (HttpClient
>>> > 4.1 request, Http request with parallels embedded resources, View
>>> > results tree, WebServices (SOAP) request, etc)
>>> > List of changes:
>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs/changes.html
>>> >
>>> >
>>> > JMeter is a Java desktop application designed to load test functional
>>> > behavior and measure performance. The current version is targeted at
>>> > Java 1.5+.
>>> >
>>> > Archives/hashes/sigs and RAT report:
>>> >
>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/dist
>>> >
>>> > MD5 hashes of archives for this vote:
>>> >
>>> > c1c63f36692ac2fd2e7cca2f2b162c6e *jakarta-jmeter-2.5.1.tgz
>>> > 8345f36f769872651d53db2436eac100 *jakarta-jmeter-2.5.1.zip
>>> > c232ea7259543592f56c2dca7ba5850d *jakarta-jmeter-2.5.1_src.tgz
>>> > 52a2dee578fd433d286e16dfe928b6b2 *jakarta-jmeter-2.5.1_src.zip
>>> >
>>> > Site Docs are here:
>>> > http://people.apache.org/~milamber/jmeter-2.5.1RC1/docs
>>> >
>>> > Tag:
>>> > http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_5_1_RC1(r1174408)
>>> >
>>> > Keys are here:
>>> > http://svn.apache.org/repos/asf/jakarta/site/dist/jmeter/
>>> > also
>>> > http://people.apache.org/~milamber/
>>> >
>>> > N.B.
>>> > To download the dependencies: "ant download_jars"
>>> >
>>> > To create the jars and test JMeter: "ant package test".
>>> >
>>> > JMeter 2.5 requires Java 1.5 or later.
>>> >
>>> > Note that there is a bug in Java on some Linux systems that manifests
>>> > itself as the following error when running the test cases or JMeter
>>> itself:
>>> >
>>> >  [java] WARNING: Couldn't flush user prefs:
>>> >  java.util.prefs.BackingStoreException:
>>> >  java.lang.IllegalArgumentException: Not supported: indent-number
>>> >
>>> > This does not affect JMeter operation.
>>> >
>>> >
>>> > All feedback (and votes!) welcome.
>>> >
>>> > [  ] +1  I support this release
>>> > [  ] +0  I am OK with this release
>>> > [  ] -0   OK, but
>>> > [  ] -1   I do not support this release (please indicate why)
>>> >
>>> > The vote will remain open for at least 72 hours.
>>> >
>>> > Note: If the vote passes, the intention is to release the archive files
>>> > and rename the RC tag as the release tag.
>>> >
>>> > Thanks in advance!
>>> >
>>> > Milamber
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> > For additional commands, e-mail: dev-h...@jakarta.apache.org
>>> >
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

[sebb]

On 22 September 2011 09:18, Milamber  wrote:
>
>
> Le 21/09/2011 23:49, sebb a ecrit :
>> On 22 September 2011 00:13, Milamber  wrote:
>>
>>> [snip]
>>> netstat -tplna| grep java | grep ESTA | wc -l
>>> 39 (esta conn)
>>>
>>> ==> 39 is the number of http requests in my test plan
>>>
>> I see the problem now.
>>
>> The httpclient cache key includes the full URL, so only reuses
>> connections for identical URLs.
>>
>> It should match on host name, port and protocol.
>>
>> If you test instead with identical URLs - or loop a single URL - it
>> should work the same as HC3.1
>> That's why I did not spot it earlier.
>>
>> I'll work on a fix now.
>>
>
>
> Your last commit fixes the problem.
> Now 1 connection with second test case (bug 51863), and 100 connections
> with my load test with 0% error during the test (second issue fixed too).
>
> Thanks.

I'm glad you spotted the issue.

>>>> [I think we need to fix this before releasing 2.5.1
>>>
>>> Yes sure.
>>>
>>>
>
> Any objection now to start RC1 process tonight?
>

No objections, go ahead.

I don't think there are any other issues that cannot wait.

It's sometimes tempting to add just one more fix, but then the process
can slip and slip ...


> Milamber
>
>
>
>>>
>>>>
>>>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>>>
>>>>> I suppose that is a close keep alive connection problem with JMeter.
>>>>> Perhaps 2 issues are linked?
>>>>>
>>>>>
>>>> Dunno yet.
>>>>
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org

Re: Lots of CLOSE_WAIT with HC4 HTTP implementation

[sebb]

On 22 September 2011 00:13, Milamber  wrote:
>
>
> Le 21/09/2011 22:42, sebb a ecrit :
>> On 21 September 2011 22:29, Milamber  wrote:
>>
>>> [snip]
>>>
>>> I make a tcp dump and analyze with wireshark.
>>> With HC3.1 : 0-42 secs : 43 TCP conversations (inside several HTTP GET
>>> and response)
>>> With HC4.1 : 0-44 secs : 3011 TCP conversations (inside one HTTP GET and
>>> one response)
>>>
>> Do you mean that each HC4.1 conversation only contains a single
>> request/response?
>>
>
> Yes a single request/response
>
>> Can you enable debug logging for HTTPHC4Impl ?
>>
>
> Yes I can, I will sent the log in a private mail
> see end of log : one user but lot of:
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
> 2011/09/22 01:06:56 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> Thread Finished
>
>
>> This should show if the clients are being reused or not.
>>
>> I suggest you reduce thread and loop counts, or the log file will be very 
>> big.
>>
>
> Done: 1 thread, 1 sec ramp up, 30 secs duration
>
> Starting the test @ Thu Sep 22 01:06:25 CEST 2011 (1316646385910)
> Waiting for possible shutdown message on port 4445
> summary +   188 in   3,7s =   50,9/s Avg:    18 Min:     8 Max:   113
> Err:     0 (0,00%)
> summary +  1697 in  26,1s =   65,1/s Avg:    14 Min:     8 Max:   173
> Err:     0 (0,00%)
> summary =  1885 in  29,8s =   63,3/s Avg:    15 Min:     8 Max:   173
> Err:     0 (0,00%)
> Tidying up ...    @ Thu Sep 22 01:06:56 CEST 2011 (1316646416091)
> ... end of run
>
>
>
> netstat -tplna| grep java | grep ESTA | wc -l
> 39 (esta conn)
>
> ==> 39 is the number of http requests in my test plan

I see the problem now.

The httpclient cache key includes the full URL, so only reuses
connections for identical URLs.

It should match on host name, port and protocol.

If you test instead with identical URLs - or loop a single URL - it
should work the same as HC3.1
That's why I did not spot it earlier.

I'll work on a fix now.

>
>> [I think we need to fix this before releasing 2.5.1]
>>
>
>
> Yes sure.
>
>
>>
>>> HTTP conversations show Keep-Alive header (HC3 and HC4)
>>>
>>> I suppose that is a close keep alive connection problem with JMeter.
>>> Perhaps 2 issues are linked?
>>>
>> Dunno yet.
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org