Re: config httpclient.localaddress
On 2 December 2011 10:02, sbos-61 ser...@bosoconsulting.it 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
On 26 November 2011 20:08, Greg Roodt gro...@gmail.com 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: [JMeter] evolution request - handle BeanDescriptor.hidden flag in JMeter
2011/11/9 Stéphane Hoblingre stephane.hoblin...@gmail.com:
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 seb...@gmail.com wrote:
2011/11/8 Stéphane Hoblingre stephane.hoblin...@gmail.com:
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
JMeter TLP changes
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: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)
On 1 November 2011 14:25, Philippe Mouawad philippe.moua...@gmail.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=52033 --- Comment #13 from Philippe Mouawad p.moua...@ubik-ingenierie.com 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: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)
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 philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 1 November 2011 14:25, Philippe Mouawad philippe.moua...@gmail.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=52033 --- Comment #13 from Philippe Mouawad p.moua...@ubik-ingenierie.com 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: ISSUE 52033
On 1 November 2011 19:32, Philippe Mouawad philippe.moua...@gmail.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=52033 --- Comment #14 from Julian Cesar juliance...@gmail.com 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
JMeter SVN move
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
** JMeter SVN move about to start **
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 completed
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
Re: JMeter SVN move completed
On 1 November 2011 22:12, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com 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
Re: Start Next Loop fix
On 31 October 2011 10:59, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 25 October 2011 17:14, Philippe Mouawad p.moua...@ubik-ingenierie.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51866 --- Comment #8 from Sebb s...@apache.org 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: Issue 52044
On 18 October 2011 22:21, sebb seb...@gmail.com wrote: On 18 October 2011 19:50, Philippe Mouawad p.moua...@ubik-ingenierie.com 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: Issue 52044
On 18 October 2011 19:50, Philippe Mouawad p.moua...@ubik-ingenierie.com 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
Wrong mailing list?
This is Jakarta, not Jackrabbit ...
On 17 October 2011 00:44, Dave Brosius dbros...@apache.org 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();
MapString, MultiStatusResponse respMap = new HashMapString,
MultiStatusResponse();
ListAclProperty.Ace list = (ListAclProperty.Ace)
((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: svn commit: r1182664 - /jakarta/jmeter/trunk/eclipse.classpath
Good catch! On 13 October 2011 06:39, pmoua...@apache.org wrote: Author: pmouawad Date: Thu Oct 13 05:39:35 2011 New Revision: 1182664 URL: http://svn.apache.org/viewvc?rev=1182664view=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=1182664r1=1182663r2=1182664view=diff == --- jakarta/jmeter/trunk/eclipse.classpath (original) +++ jakarta/jmeter/trunk/eclipse.classpath Thu Oct 13 05:39:35 2011 @@ -50,6 +50,7 @@ classpathentry kind=lib path=lib/commons-httpclient-3.1.jar/ classpathentry kind=lib path=lib/commons-io-2.0.1.jar/ classpathentry kind=lib path=lib/commons-jexl-1.1.jar/ + classpathentry kind=lib path=lib/commons-jexl-2.0.1.jar/ classpathentry kind=lib path=lib/commons-lang-2.6.jar/ classpathentry kind=lib path=lib/commons-logging-1.1.1.jar/ classpathentry kind=lib path=lib/commons-net-3.0.1.jar/ - 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: Patch 52001
On 13 October 2011 18:28, Philippe Mouawad pmoua...@apache.org wrote: Hello Sebb, Do you think we should implement issue 52001https://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: Patch 52001
On 13 October 2011 18:47, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 13 October 2011 18:28, Philippe Mouawad pmoua...@apache.org wrote: Hello Sebb, Do you think we should implement issue 52001https://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: DO NOT REPLY [Bug 52019] Add menu option to enable/disable timers when running Plan
On 13 October 2011 18:34, Philippe Mouawad p.moua...@ubik-ingenierie.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=52019 --- Comment #1 from Sebb s...@apache.org 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: DO NOT REPLY [Bug 52013] View Results Tree does not take into account proxy excluded URLs
On 12 October 2011 13:37, Philippe Mouawad philippe.moua...@gmail.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=52013 --- Comment #1 from Sebb s...@apache.org 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)
On 9 October 2011 10:41, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com 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
On 10 October 2011 21:45, Philippe Mouawad pmoua...@apache.org wrote: Hello All, Did you have some time to look at issue 51876https://issues.apache.org/bugzilla/show_bug.cgi?id=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
On 7 October 2011 09:45, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 7 October 2011 00:00, sebb seb...@gmail.com wrote: On 6 October 2011 22:17, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 5 October 2011 21:46, Philippe Mouawad philippe.moua...@gmail.com 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
Re: svn commit: r1180004 - in /jakarta/jmeter/trunk: src/components/org/apache/jmeter/config/CSVDataSet.java xdocs/changes.xml
On 7 October 2011 12:10, pmoua...@apache.org wrote:
Author: pmouawad
Date: Fri Oct 7 11:10:18 2011
New Revision: 1180004
URL: http://svn.apache.org/viewvc?rev=1180004view=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=1180004r1=1180003r2=1180004view=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 EOF
try {
- line = server.readLine(alias, getRecycle(),
firstLineIsNames);
- } catch
Re: svn commit: r1180004 - in /jakarta/jmeter/trunk: src/components/org/apache/jmeter/config/CSVDataSet.java xdocs/changes.xml
On 7 October 2011 12:51, sebb seb...@gmail.com wrote:
On 7 October 2011 12:10, pmoua...@apache.org wrote:
Author: pmouawad
Date: Fri Oct 7 11:10:18 2011
New Revision: 1180004
URL: http://svn.apache.org/viewvc?rev=1180004view=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=1180004r1=1180003r2=1180004view=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, 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
Re: svn commit: r1179989 - /jakarta/jmeter/trunk/bin/testfiles/HTMLParserTestFile_2.xml
On 7 October 2011 11:38, pmoua...@apache.org wrote: Author: pmouawad Date: Fri Oct 7 10:38:56 2011 New Revision: 1179989 URL: http://svn.apache.org/viewvc?rev=1179989view=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=1179989r1=1179988r2=1179989view=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 @@ ?xml version=1.0 encoding=UTF-8? testResults version=1.2 httpSample s=true lb=Download embedded rc=200 rm=OK tn=Thread Group 1-1 dt=text de= by=40174 sc=1 ec=0 ng=1 na=1 - httpSample s=true lb=file:testfiles/HTMLParserTestFile_2.htm rc=200 rm=OK tn=Thread Group 1-1 dt=text de= by=40174 sc=1 ec=0 ng=0 na=0 + httpSample s=true lb=file:testfiles/HTMLParserTestFile_2.html rc=200 rm=OK tn=Thread Group 1-1 dt=text de= by=40174 sc=1 ec=0 ng=0 na=0 responseHeader class=java.lang.String/responseHeader requestHeader class=java.lang.String/requestHeader responseFile class=java.lang.String/responseFile cookies class=java.lang.String/cookies method class=java.lang.StringGET/method queryString class=java.lang.String/queryString - java.net.URLfile:testfiles/HTMLParserTestFile_2.htm/java.net.URL + java.net.URLfile:testfiles/HTMLParserTestFile_2.html/java.net.URL /httpSample - httpSample s=true 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 + httpSample s=true 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 responseHeader class=java.lang.String/responseHeader requestHeader class=java.lang.String/requestHeader responseFile class=java.lang.String/responseFile @@ -106,7 +106,7 @@ cookies class=java.lang.String/cookies method class=java.lang.StringGET/method queryString class=java.lang.String/queryString - java.net.URLfile:testfiles/HTMLParserTestFile_2.htm/java.net.URL + java.net.URLfile:testfiles/HTMLParserTestFile_2.html/java.net.URL /httpSample /testResults - 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
On 7 October 2011 13:01, sebb seb...@gmail.com wrote:
On 7 October 2011 12:51, sebb seb...@gmail.com wrote:
On 7 October 2011 12:10, pmoua...@apache.org wrote:
Author: pmouawad
Date: Fri Oct 7 11:10:18 2011
New Revision: 1180004
URL: http://svn.apache.org/viewvc?rev=1180004view=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=1180004r1=1180003r2=1180004view=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 revision.
Revert the changes that aren't relevant.
Just before commiting, recheck changes against the server version.
Either way, commits should be the minimum necessary to solve the issue.
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
Welcome to Jakarta and JMeter!
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: DO NOT REPLY [Bug 51876] [PATCH] Functionnality to search in Samplers TreeView
On 4 October 2011 15:51, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51876 Philippe Mouawad p.moua...@ubik-ingenierie.com 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: [VOTE] Release JMeter 2.5.1 RC3
On 29 September 2011 00:52, Milamber milam...@apache.org 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: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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:
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 seb...@gmail.com wrote:
On 3 October 2011 12:15, Rainer Jung rainer.j...@kippdata.de 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
--
Cordialement.
Philippe Mouawad.
--
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
On 3 October 2011 14:04, Philippe Mouawad philippe.moua...@gmail.com 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 FutureHTTPSampleResult 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 seb...@gmail.com 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:
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 seb...@gmail.com wrote:
On 3 October 2011 12:15, Rainer Jung rainer.j...@kippdata.de 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
Re: Running ant test fails
On 3 October 2011 16:39, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 3 October 2011 16:12, Philippe Mouawad philippe.moua...@gmail.com 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 presetdef/macrodef 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: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
On 1 October 2011 14:33, Philippe Mouawad philippe.moua...@gmail.com 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
On 2 October 2011 15:20, Rainer Jung rainer.j...@kippdata.de wrote: On 02.10.2011 15:49, sebb wrote: On 1 October 2011 14:33, Philippe Mouawad philippe.moua...@gmail.com 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
On 2 October 2011 19:39, Philippe Mouawad philippe.moua...@gmail.com 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: JMeter TLP - draft resolution and first chair
On 1 October 2011 15:36, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Sep 21, 2011 at 8:31 PM, sebb seb...@gmail.com wrote: On 22 September 2011 01:15, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Sep 21, 2011 at 7:33 PM, Henri Yandell bay...@generationjava.com wrote: On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell bay...@generationjava.com 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. snip/ Thats reasonable too :-) Sebb? I would have preferred to see JMeter as part of HC, but perhaps it would be better as a TLP. snip/ IMO, yes. However I think we need some more PMC members first. snap/ 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
On 1 October 2011 10:53, Philippe Mouawad p.moua...@ubik-ingenierie.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51919 --- Comment #2 from Milamber milam...@apache.org 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: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
On 1 October 2011 12:38, Philippe Mouawad philippe.moua...@gmail.com wrote: On Sat, Oct 1, 2011 at 12:57 PM, sebb seb...@gmail.com wrote: On 1 October 2011 10:53, Philippe Mouawad p.moua...@ubik-ingenierie.com 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, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51919 --- Comment #2 from Milamber milam...@apache.org 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: [VOTE] Release JMeter 2.5.1 RC3
On 30 September 2011 16:52, Philippe Mouawad philippe.moua...@gmail.com 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 seb...@gmail.com wrote: On 29 September 2011 21:37, Philippe Mouawad philippe.moua...@gmail.com 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 milam...@apache.org 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
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)
On 28 September 2011 19:59, Philippe Mouawad philippe.moua...@gmail.com 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
Re: [VOTE] Release JMeter 2.5.1 RC2
On 26 September 2011 20:04, Oleg Kalnichevski ol...@apache.org 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 unwar 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: svn commit: r1175371 - /jakarta/jmeter/tags/v2_5_1_RC2/
On 25 September 2011 12:22, milam...@apache.org wrote: Author: milamber Date: Sun Sep 25 11:22:54 2011 New Revision: 1175371 URL: http://svn.apache.org/viewvc?rev=1175371view=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
On 25 September 2011 01:03, Milamber milam...@apache.org wrote: Le 23/09/2011 23:38, sebb a ecrit : On 23 September 2011 23:17, sebb seb...@gmail.com wrote: On 23 September 2011 18:14, sebb seb...@gmail.com wrote: On 23 September 2011 17:15, Milamber milam...@apache.org 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=1175069view=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
On 23 September 2011 11:29, sebb seb...@gmail.com wrote: 2011/9/23 Stéphane Hoblingre stephane.hoblin...@gmail.com: 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 stephane.hoblin...@gmail.com 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 wool...@gmail.com wrote: +1 On Thu, Sep 22, 2011 at 6:53 PM, Milamber milam...@apache.org 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: Classloading issue
On 20 September 2011 23:04, Philippe Mouawad philippe.moua...@gmail.com 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
2011/9/23 Stéphane Hoblingre stephane.hoblin...@gmail.com: 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 stephane.hoblin...@gmail.com 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 stephane.hoblin...@gmail.com 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 wool...@gmail.com wrote: +1 On Thu, Sep 22, 2011 at 6:53 PM, Milamber milam...@apache.org 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 -- 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: 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
On 23 September 2011 15:20, Milamber milam...@apache.org 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: request to be added to the contributors list
On 23 September 2011 20:49, Franco Sabadini fsab...@gmail.com wrote: Hi, I helped on resolving *Bug 30563*https://issues.apache.org/bugzilla/show_bug.cgi?id=30563and 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: [VOTE] Release JMeter 2.5.1 RC1
On 23 September 2011 18:14, sebb seb...@gmail.com wrote: On 23 September 2011 17:15, Milamber milam...@apache.org 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: [VOTE] Release JMeter 2.5.1 RC1
On 23 September 2011 23:17, sebb seb...@gmail.com wrote: On 23 September 2011 18:14, sebb seb...@gmail.com wrote: On 23 September 2011 17:15, Milamber milam...@apache.org 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=1175069view=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: JMeter OS tested
On 20 September 2011 13:46, Nermin Caluk nermin.ca...@gmail.com wrote: JMeter works on Windows 7 + JDK 6, too (tried to edit the wiki, but it says Immutable Page) We had ongoing problems with spam, so now you need to be registered to update pages. What is your Wiki login? We can easily add you to the list of allowed updaters. Nermin On 20 September 2011 11:45, Milamber milam...@apache.org wrote: Le 19/09/2011 10:15, sebb a ecrit : On 19 September 2011 04:21, Rainer Jung rainer.j...@kippdata.de wrote: On 19.09.2011 02:41, sebb wrote: On 18 September 2011 18:02, Milamber milam...@apache.org wrote: Solaris? Solaris Sparc with HotSpot JVM (Sun/Oracle) workes very well (at least for JMeter 2.4). Regards, Rainer Thanks. If we do want to list the OSes that are being used to run JMeter, I think it would be better to set up a page for this on the Wiki. That would be much easier to maintain (and anyone could contribute). OK? Done. http://wiki.apache.org/jakarta-jmeter/JMeterAndOperatingSystemsTested and update done on getting start page. 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 -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: JMeter OS tested
On 20 September 2011 14:43, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, By the way I am also in this case (Can Login but cannot update). If I am allowed my user is: Philippe Mouawad Try again now. Regards Philippe On Tue, Sep 20, 2011 at 3:41 PM, sebb seb...@gmail.com wrote: On 20 September 2011 13:46, Nermin Caluk nermin.ca...@gmail.com wrote: JMeter works on Windows 7 + JDK 6, too (tried to edit the wiki, but it says Immutable Page) We had ongoing problems with spam, so now you need to be registered to update pages. What is your Wiki login? We can easily add you to the list of allowed updaters. Nermin On 20 September 2011 11:45, Milamber milam...@apache.org wrote: Le 19/09/2011 10:15, sebb a ecrit : On 19 September 2011 04:21, Rainer Jung rainer.j...@kippdata.de wrote: On 19.09.2011 02:41, sebb wrote: On 18 September 2011 18:02, Milamber milam...@apache.org wrote: Solaris? Solaris Sparc with HotSpot JVM (Sun/Oracle) workes very well (at least for JMeter 2.4). Regards, Rainer Thanks. If we do want to list the OSes that are being used to run JMeter, I think it would be better to set up a page for this on the Wiki. That would be much easier to maintain (and anyone could contribute). OK? Done. http://wiki.apache.org/jakarta-jmeter/JMeterAndOperatingSystemsTested and update done on getting start page. 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 -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org -- 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: JMeter OS tested
On 20 September 2011 14:56, Nermin Caluk nermin.ca...@gmail.com wrote: my wiki login is: nermin.calukhttp://wiki.apache.org/jakarta-jmeter/nermin.caluk OK, try again now. Thanks, Nermin On 20 September 2011 15:41, sebb seb...@gmail.com wrote: On 20 September 2011 13:46, Nermin Caluk nermin.ca...@gmail.com wrote: JMeter works on Windows 7 + JDK 6, too (tried to edit the wiki, but it says Immutable Page) We had ongoing problems with spam, so now you need to be registered to update pages. What is your Wiki login? We can easily add you to the list of allowed updaters. Nermin On 20 September 2011 11:45, Milamber milam...@apache.org wrote: Le 19/09/2011 10:15, sebb a ecrit : On 19 September 2011 04:21, Rainer Jung rainer.j...@kippdata.de wrote: On 19.09.2011 02:41, sebb wrote: On 18 September 2011 18:02, Milamber milam...@apache.org wrote: Solaris? Solaris Sparc with HotSpot JVM (Sun/Oracle) workes very well (at least for JMeter 2.4). Regards, Rainer Thanks. If we do want to list the OSes that are being used to run JMeter, I think it would be better to set up a page for this on the Wiki. That would be much easier to maintain (and anyone could contribute). OK? Done. http://wiki.apache.org/jakarta-jmeter/JMeterAndOperatingSystemsTested and update done on getting start page. 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 -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: DO NOT REPLY [Bug 51840] JMS : Cache of InitialContext has some issues
On 19 September 2011 06:45, Philippe Mouawad p.moua...@ubik-ingenierie.com wrote: Hello, I closed bug as fixed, don't know if I had to do it or it's up to you. That's OK as you raised the issue. I had intended to close it myself, but forgot. Only a JMeter developer or the originator should normally close issues. Thank you Regards Philippe On Monday, September 19, 2011, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51840 --- Comment #7 from Sebb s...@apache.org 2011-09-19 00:58:45 UTC --- Thanks for finding the bug and the patch. I made two changes to InitialContextFactory.java: * when the context is added to the map using putIfAbsent, this might return an existing context, in which case we need to return that, rather than the one we just created, or the Map does no correspond with what we have issued. * simplified the close method - no need to iterate over the map entries when we only want the values. URL: http://svn.apache.org/viewvc?rev=1172403view=rev Log: Bug 51840 - JMS : Cache of InitialContext has some issues Modified: 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/sampler/PublisherSampler.java jakarta/jmeter/trunk/src/protocol/jms/org/apache/jmeter/protocol/jms/sampler/SubscriberSampler.java jakarta/jmeter/trunk/xdocs/changes.xml -- 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: Question about issues management
On 19 September 2011 12:27, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello Sebb, A question about Issue management strategy if a bug is in status NEED and you don't get any answer ? after how many time do you close the issue ? Depends on the issue, but generally at least a few months, maybe a year or more. Thanks. Regards Philippe - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: JMeter OS tested
On 18 September 2011 18:02, Milamber milam...@apache.org wrote: Hello, On JMeter Get Started documentation, there are: JMeter is a 100% Java application and should run correctly on any system that has a compliant Java implementation. JMeter has been tested and works under: * Unix (Solaris, Linux, etc) * Windows (98, NT, XP, etc) Win98 and NT should be dropped. * OpenVMS Alpha 7.3+ I've not tried it on OpenVMS for a while; I expect it still works, but I don't have access to a system on which I can try the GUI. I would like update the OS list. Please can you confirm if JMeter works on these platforms (with JVM 1.5+) (for me, JMeter works with Linux, Win XP, Win 2003) * Windows Vista * Windows 7 * Windows Server 2008 * Mac OS X OpenVMS 7.3 still a supported platform? FreeBSD, NetBSD or OpenBSD? JMeter with appropriate JVM works? AIX (IBM JVM)? HP-UX (HP JVM) ? Solaris? MVS? etc? Thanks for your feedback. I think we should just drop the OS list; just because we have not tested it does not mean it won't work. Milamber - 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 RC1
On 2 August 2011 14:05, sebb seb...@gmail.com wrote: On 1 August 2011 06:46, Stefan Bodewig bode...@apache.org wrote: On 2011-08-01, Milamber wrote: The first release candidate for JMeter 2.5 has been prepared, and your votes are solicited. I haven't performed any sort of test, not even tried to build JMeter. * hashes and sigs are fine * source tarball and svn tag differ in some ways, some minor like no checkstyle.xml in the source archive but at least one that might be significant: We ought to include checkstyle.xml in the source archive - I think that must be new since 2.4. I see that Milamber has fixed that. diff -ur v2_5_RC1/src/core/org/apache/jmeter/util/JMeterVersion.java jakarta-jmeter-2.5/src/core/org/apache/jmeter/util/JMeterVersion.java --- v2_5_RC1/src/core/org/apache/jmeter/util/JMeterVersion.java 2011-08-01 07:26:20.174097342 +0200 +++ jakarta-jmeter-2.5/src/core/org/apache/jmeter/util/JMeterVersion.java 2011-08-01 01:18:26.0 +0200 @@ -44,7 +44,7 @@ * This ensures that JMeterUtils always gets the correct * version, even if JMeterUtils is not re-compiled during the build. */ - private static final String VERSION = 2.5; + private static final String VERSION = 2.5 r1152655; For me this is not big enough to cast a negative vote, this really depends on how closely the JMeter devs want the tag and the released code to match. This is tricky. The idea is that the displayed version includes the SVN revision number from which the binary was built. The file would need to be updated when creating the tag so it gets the same id as the tag. The existing post-tag update phase could be changed to check that the correct rev number had been included. I'll see if I can get this working, but it may take a while as I don't have access to my normal build PC at present. Looks like it can be made to work. The procedure that worked for me was: Update the file containing the $Revision keyword. It's not sufficient to edit the text within the keywork field, as SVN does not consider that to be an update. Probably the easiest would be to add the current date as a comment to the version file. The SVN tag can then be created using svn copy from the workspace. See my test commit: URL: http://svn.apache.org/viewvc?rev=1153135view=rev Log: Test tag / keyword creation There's a bit more work still needed to incorporate this into the JMeter build process. For example, the keyword expansion produces $Revision: 1153135 $, but ideally we only want the revision number. I can make a start on this. * in addition the source distribution is missing the docs subdirectory. Is this intentional? The docs subdirectory is generated from xdocs, so is not needed in the source archive. It's only stored in SVN for use when updating the website. * RAT only flags some testfiles, which is good enough for me * NOTICE should contain 2011 rather than 2010 Good point; needs to be fixed. I see Milamber has done that too. * ApacheJMeter.jar should probably not contain the tird party notice and licenses but only the ASF ones as the files inside the jar only apply to the jar and not the binary distribution. No biggy for me. Probably should be fixed. Not a +1, yet. Stefan - 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 RC1
On 2 August 2011 19:53, Milamber milam...@apache.org wrote: Le 02/08/2011 13:05, sebb a ecrit : * ApacheJMeter.jar should probably not contain the tird party notice and licenses but only the ASF ones as the files inside the jar only apply to the jar and not the binary distribution. No biggy for me. Probably should be fixed. For next RC2, I can fix this? Presumably all the JMeter*.jar files should just contain the standard NOTICE header; only the binary archive needs the additional details of the other code. Ditto for the LICENSE file. 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: svn commit: r1152605 - in /jakarta/jmeter/trunk: build.properties eclipse.classpath xdocs/changes.xml
On 31 July 2011 19:09, milam...@apache.org wrote: Author: milamber Date: Sun Jul 31 18:09:09 2011 New Revision: 1152605 URL: http://svn.apache.org/viewvc?rev=1152605view=rev Log: Update to httpcore 4.1.3 Modified: jakarta/jmeter/trunk/build.properties jakarta/jmeter/trunk/eclipse.classpath jakarta/jmeter/trunk/xdocs/changes.xml Thanks! Was just starting to look at fixing this, but you beat me to it. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE][LAZY] Move BCEL and JCS to Commons
On 23 June 2011 03:38, Rahul Akolkar rahul.akol...@gmail.com wrote: After reasonable support to the idea on Jakarta and Commons lists, this is a vote to move BCEL and JCS to Apache Commons. As part of the move, I'll nominate any active committers for Commons karma (so far: dbrosius, asmuts, tv -- anyone else, please ping this thread). Since neither may have enough PMC members active, this vote will be held by lazy consensus. If you object to moving either/both, please also provide a reason and an alternative course of action. Vote runs for 72 hours. Vote is being held on general@jao but is being cross-posted to ensure we reach the full audience. I've not looked at JCS; I've done a bit of tinkering on BCEL. +1 to moving them. But I hope the move won't *require* the package names to be changed to o.a.commons. Likewise Maven ids. If later on it proves necessary to make an incompatible API change, that would be the point to change package names. But I think users would be understandably upset if the package or Maven name was changed unnecessarily, and I will vote -1 against any such change. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [BSF] Couldn't build bsf project from source
On 27 April 2011 11:22, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: Hi all, I'm trying to build the bsf project from source (version 3.0.0) .I downloaded the source distribution and tried to build it.. but anyway i'm failing with the following issue [1], since 'jsr' site is unavailable.. Not a lot we can do to fix that; it's not an ASF resource. Would be great if someone look into this issue ASAP.. i'm trying to debug my project, for that i need the bsf source.. Which is available from the download location as usual. The engines are only needed to test some parts of BSF; just comment out the following lines in the top level pom: modulebsf-engines/module and moduletesting/module Note that BSF 3.0 is generally only needed for projects running on Java 1.4 and Java 1.5 as Java 1.6+ contains the JSR-223 API. There are a few utility methods in the bsf-utils jar that may be useful with Java 1.6. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [BSF] Couldn't build bsf project from source
On 27 April 2011 12:00, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: From: sebb seb...@gmail.com To: dev@jakarta.apache.org Sent: Wed, 27 April, 2011 16:21:18 Subject: Re: [BSF] Couldn't build bsf project from source On 27 April 2011 11:22, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: Hi all, I'm trying to build the bsf project from source (version 3.0.0) .I downloaded the source distribution and tried to build it.. but anyway i'm failing with the following issue [1], since 'jsr' site is unavailable.. Not a lot we can do to fix that; it's not an ASF resource. Would be great if someone look into this issue ASAP.. i'm trying to debug my project, for that i need the bsf source.. Which is available from the download location as usual. The engines are only needed to test some parts of BSF; just comment out the following lines in the top level pom: modulebsf-engines/module and moduletesting/module Hi, Thanks for the response , i tried to avoid testing/bsf-engines modules..but distribution needs bsf-engines jar..so couldn't build the project...:( bsf-engines.jar is NOT needed for the distribution. However, bsf-utils has a dependency on bsf-engines which needs to be commented out as well. Not sure why it is a compile-time depend (that may be incorrect) You will then need to run Maven with -DskipTests otherwise the bsf-utils module will fail. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [BSF] Couldn't build bsf project from source
On 27 April 2011 12:57, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: From: sebb seb...@gmail.com To: dev@jakarta.apache.org Sent: Wed, 27 April, 2011 17:19:20 Subject: Re: [BSF] Couldn't build bsf project from source On 27 April 2011 12:43, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: Hi, After commenting commented out testing/bsf-engines and commented out bsf-engines @ the build.xml of distribution module i was able to build project successfully... Anyway i couldnt start my application because im getting class not found exception[1] This error is nothing to do with BSF; you need to download the appropriate scripting engine. BSF 3.1 does not include any scripting engines. Partial build is not working for my case to debug... Without a full success build i can not debug...:( What Java version are you using? JDK1.6.0_20 In which case (as I already wrote) you don't need BSF 3.1. I tried to find a location to down that particular jsr223-engines.zip in google and all point to this location https://scripting.dev.java.net;.. BTW if there is no any other solution from ASF side..I try to debug with BSF 3.1 and see.. I repeat: you don't need BSF 3.1 with Java 1.6+. In fact adding bsf-api-3.1 to the classpath may cause problems. You do need to ensure that you have the appropriate scripting engine on the classpath. Thanks a lot for your help... Regards, -Ratha. Regards, -Ratha. [1] java.lang.NoClassDefFoundError: com/sun/phobos/script/javascript/RhinoScriptEngineFactory at org.apache.synapse.mediators.bsf.ScriptMediator.initScriptEngine(ScriptMediator.java:402) ) at org.apache.synapse.mediators.bsf.ScriptMediator.initInlineScript(ScriptMediator.java:268) ) From: sebb seb...@gmail.com To: dev@jakarta.apache.org Sent: Wed, 27 April, 2011 16:51:48 Subject: Re: [BSF] Couldn't build bsf project from source On 27 April 2011 12:00, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: From: sebb seb...@gmail.com To: dev@jakarta.apache.org Sent: Wed, 27 April, 2011 16:21:18 Subject: Re: [BSF] Couldn't build bsf project from source On 27 April 2011 11:22, vijayaratha vijayasingam vijayara...@yahoo.co.uk wrote: Hi all, I'm trying to build the bsf project from source (version 3.0.0) .I downloaded the source distribution and tried to build it.. but anyway i'm failing with the following issue [1], since 'jsr' site is unavailable.. Not a lot we can do to fix that; it's not an ASF resource. Would be great if someone look into this issue ASAP.. i'm trying to debug my project, for that i need the bsf source.. Which is available from the download location as usual. The engines are only needed to test some parts of BSF; just comment out the following lines in the top level pom: modulebsf-engines/module and moduletesting/module Hi, Thanks for the response , i tried to avoid testing/bsf-engines modules..but distribution needs bsf-engines jar..so couldn't build the project...:( bsf-engines.jar is NOT needed for the distribution. However, bsf-utils has a dependency on bsf-engines which needs to be commented out as well. Not sure why it is a compile-time depend (that may be incorrect) You will then need to run Maven with -DskipTests otherwise the bsf-utils module will fail. - 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] HTTP Sampler consolidation of implementations
On 20 April 2011 22:30, Milamber milam...@apache.org wrote: Hello, HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut policy: ignore cookie seems don't works) Looks like this is a new bug - the example works correctly in JMeter 2.4. I must have messed something up when converting the HC3.1 sampler to the new class layout. I'll take a look shortly. With JMeter trunk and HC3.1 sampler, if you test a website with a login page which used a auth session ID cookie to keep track user session and *without* a JMeter cookie manager, the connection works and we can accessed on protected resources. The normal case is: if no cookie manager, we don't have a access on protected resources (we have a error 408 with tomcat examples) (an example Webapp is provided with tomcat archive : http://localhost:8080/examples/jsp/security/protected/ don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml before running tomcat) Simple test case. Thanks - well spotted! Milamber Le 25/11/2010 16:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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] HTTP Sampler consolidation of implementations
On 21 April 2011 01:57, sebb seb...@gmail.com wrote: On 20 April 2011 22:30, Milamber milam...@apache.org wrote: Hello, HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut policy: ignore cookie seems don't works) Looks like this is a new bug - the example works correctly in JMeter 2.4. I must have messed something up when converting the HC3.1 sampler to the new class layout. I'll take a look shortly. Fixed. With JMeter trunk and HC3.1 sampler, if you test a website with a login page which used a auth session ID cookie to keep track user session and *without* a JMeter cookie manager, the connection works and we can accessed on protected resources. The normal case is: if no cookie manager, we don't have a access on protected resources (we have a error 408 with tomcat examples) (an example Webapp is provided with tomcat archive : http://localhost:8080/examples/jsp/security/protected/ don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml before running tomcat) Simple test case. Thanks - well spotted! Milamber Le 25/11/2010 16:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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: Counting actual input size [was: svn commit: r1088435]
On 15 April 2011 08:21, Milamber milam...@apache.org wrote: Le 14/04/2011 23:09, sebb a ecrit : On 14 April 2011 22:09, Milamber milam...@apache.org wrote: Le 14/04/2011 12:14, sebb a ecrit : On 14 April 2011 00:12, sebb seb...@gmail.com wrote: On 13 April 2011 23:33, Milamber milam...@apache.org wrote: Le 13/04/2011 14:26, sebb a ecrit : On 13 April 2011 07:53, Milamber milam...@apache.org wrote: I've updated the patch on bug 43363 since your last commit on HC4 https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 With your last commit on HC4Impl, the header size and body size aren't good with a gzip stream ou chunked response. For example, with a chunked response, they are: HC4: Size in bytes: 8199 Headers size in bytes: 8192 (= Like a buffer reader?) Body size in bytes: 7 Java HC3 (good value, verified with wireshark) Size in bytes: 10505 Headers size in bytes: 581 Body size in bytes: 9924 For a gzip response: HC4: Size in bytes: 14025 (good) Headers size in bytes: 1440 Body size in bytes: 12585 Java HC3: Size in bytes: 14025 Headers size in bytes: 291 Body size in bytes: 13734 It is a bug with HttpClient 4.1 too? Possibly. Since starting to use the metrics I've found that they are mainly intended for use in custom keep-alive strategies, so may not always provide the data we want, but I'm hoping to patch HC4 to provide more useful stats in future. If you can provide details of how you are generating the test data above, I can take a further look at the problem. I've put a simple test case to show diff between plain/gzip/chunked response with the three http request type https://issues.apache.org/bugzilla/attachment.cgi?id=26885 Thanks! I can see that there is definitely a problem with the HC4 counts, and it's a bit odd. If I put a break-point just after long headerBytes = metrics.getReceivedBytesCount(); and another after long totalBytes = metrics.getReceivedBytesCount(); the headerBytes value is the same as displayed when running at full speed, but the totalBytes figure is generally much higher. Weird. I can hopefully reproduce this directly as an HC4 test case (without all the JMeter code) and use that to fix the issue. Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was not always updating the metrics. That part of the code seems to depends on how much data is available, so the behaviour is timing related. I still need to fix the original issue so stats can safely be obtained for responses with no content (e.g. HEAD) (though we have a work-round for JMeter). Thanks for your works on this bug. Where download a nightly build of httpcore for test in JMeter? (or I must compile last trunk?) I've created a snapshot here: https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/ Thanks. I've tested, but don't works perfectly. With HC4, headers size always 1440 bytes. (total response size are good) Perhaps, we must calculate headears size like HC3 instead of use metrics? I don't see the behaviour you are reporting; HC4 seems to work OK for me with the snapshot build. Did you remove/rename the existing httpcore jar? What URL are you seeing the problem with? - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: Counting actual input size [was: svn commit: r1088435]
On 18 April 2011 22:36, Milamber milambersp...@gmail.com wrote: [snip] Thanks for your works on this bug. Where download a nightly build of httpcore for test in JMeter? (or I must compile last trunk?) I've created a snapshot here: https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/ Thanks. I've tested, but don't works perfectly. With HC4, headers size always 1440 bytes. (total response size are good) Perhaps, we must calculate headears size like HC3 instead of use metrics? I don't see the behaviour you are reporting; HC4 seems to work OK for me with the snapshot build. I confirm. I have this issue with test case on wiki jakarta, google home page. Sometimes with 1440 bytes ann sometimes 1338 (google, Jakarta wiki) I've found too: if the total response size (headers+body 1440 (or 1438)) HC4 have a headers size = total size, and body size is response data size (old behavior) (site with small response : www.monip.org) I don't see the same problem as you; wiki and monip behave OK for me. Can you capture the site response using Wireshark? I wonder if there is some additional buffering going on somewhere in your ISP? Did you remove/rename the existing httpcore jar? Yes. And same issue with Jdk1.5 / 6 on Linux/Windows. What URL are you seeing the problem with? - 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: Counting actual input size [was: svn commit: r1088435]
On 14 April 2011 00:12, sebb seb...@gmail.com wrote: On 13 April 2011 23:33, Milamber milam...@apache.org wrote: Le 13/04/2011 14:26, sebb a ecrit : On 13 April 2011 07:53, Milamber milam...@apache.org wrote: I've updated the patch on bug 43363 since your last commit on HC4 https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 With your last commit on HC4Impl, the header size and body size aren't good with a gzip stream ou chunked response. For example, with a chunked response, they are: HC4: Size in bytes: 8199 Headers size in bytes: 8192 (= Like a buffer reader?) Body size in bytes: 7 Java HC3 (good value, verified with wireshark) Size in bytes: 10505 Headers size in bytes: 581 Body size in bytes: 9924 For a gzip response: HC4: Size in bytes: 14025 (good) Headers size in bytes: 1440 Body size in bytes: 12585 Java HC3: Size in bytes: 14025 Headers size in bytes: 291 Body size in bytes: 13734 It is a bug with HttpClient 4.1 too? Possibly. Since starting to use the metrics I've found that they are mainly intended for use in custom keep-alive strategies, so may not always provide the data we want, but I'm hoping to patch HC4 to provide more useful stats in future. If you can provide details of how you are generating the test data above, I can take a further look at the problem. I've put a simple test case to show diff between plain/gzip/chunked response with the three http request type https://issues.apache.org/bugzilla/attachment.cgi?id=26885 Thanks! I can see that there is definitely a problem with the HC4 counts, and it's a bit odd. If I put a break-point just after long headerBytes = metrics.getReceivedBytesCount(); and another after long totalBytes = metrics.getReceivedBytesCount(); the headerBytes value is the same as displayed when running at full speed, but the totalBytes figure is generally much higher. Weird. I can hopefully reproduce this directly as an HC4 test case (without all the JMeter code) and use that to fix the issue. Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was not always updating the metrics. That part of the code seems to depends on how much data is available, so the behaviour is timing related. I still need to fix the original issue so stats can safely be obtained for responses with no content (e.g. HEAD) (though we have a work-round for JMeter). Thanks for all the fixes to the other code. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: nightlies vs release: two files
On 14 April 2011 14:14, Peter Lynch pe...@peterlynch.ca wrote: The nightlies require unzipping two files to make a usable runtime as described here http://people.apache.org/builds/jakarta-jmeter/nightly/ . Is it correct to assume that the a final release will just be one distributable? Sort of. There is a binary dist and a source dist, and each is available as zip and tar.gz, so there are actually 4 archives (plus hashes and sigs). However only one binary is needed to run JMeter. Here is the download page: http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi -Peter - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: Counting actual input size [was: svn commit: r1088435]
On 14 April 2011 22:09, Milamber milam...@apache.org wrote: Le 14/04/2011 12:14, sebb a ecrit : On 14 April 2011 00:12, sebb seb...@gmail.com wrote: On 13 April 2011 23:33, Milamber milam...@apache.org wrote: Le 13/04/2011 14:26, sebb a ecrit : On 13 April 2011 07:53, Milamber milam...@apache.org wrote: I've updated the patch on bug 43363 since your last commit on HC4 https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 With your last commit on HC4Impl, the header size and body size aren't good with a gzip stream ou chunked response. For example, with a chunked response, they are: HC4: Size in bytes: 8199 Headers size in bytes: 8192 (= Like a buffer reader?) Body size in bytes: 7 Java HC3 (good value, verified with wireshark) Size in bytes: 10505 Headers size in bytes: 581 Body size in bytes: 9924 For a gzip response: HC4: Size in bytes: 14025 (good) Headers size in bytes: 1440 Body size in bytes: 12585 Java HC3: Size in bytes: 14025 Headers size in bytes: 291 Body size in bytes: 13734 It is a bug with HttpClient 4.1 too? Possibly. Since starting to use the metrics I've found that they are mainly intended for use in custom keep-alive strategies, so may not always provide the data we want, but I'm hoping to patch HC4 to provide more useful stats in future. If you can provide details of how you are generating the test data above, I can take a further look at the problem. I've put a simple test case to show diff between plain/gzip/chunked response with the three http request type https://issues.apache.org/bugzilla/attachment.cgi?id=26885 Thanks! I can see that there is definitely a problem with the HC4 counts, and it's a bit odd. If I put a break-point just after long headerBytes = metrics.getReceivedBytesCount(); and another after long totalBytes = metrics.getReceivedBytesCount(); the headerBytes value is the same as displayed when running at full speed, but the totalBytes figure is generally much higher. Weird. I can hopefully reproduce this directly as an HC4 test case (without all the JMeter code) and use that to fix the issue. Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was not always updating the metrics. That part of the code seems to depends on how much data is available, so the behaviour is timing related. I still need to fix the original issue so stats can safely be obtained for responses with no content (e.g. HEAD) (though we have a work-round for JMeter). Thanks for your works on this bug. Where download a nightly build of httpcore for test in JMeter? (or I must compile last trunk?) I've created a snapshot here: https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/ Milamber Thanks for all the fixes to the other code. - 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: Counting actual input size [was: svn commit: r1088435]
On 8 April 2011 14:23, sebb seb...@gmail.com wrote: On 8 April 2011 07:45, Milamber milam...@apache.org wrote: [...] With my last submission (r1088748), I try to respond to your feedback. Please say me if another thing to improve. The problem of chunked responses still exists - such responses don't have a Content-Length header. One way round this would be to wrap the input Stream with a org.apache.commons.io.input.CountingInputStream. I don't think this will affect performance adversely. Does that make sense? Yes may be a good idea. Since your last commit on HC4Impl, entity.getContentLength() return -1 (unknown size) (but http response have a content-length define) I thinks the ResponseContentEncoding class which decompress stream is the cause. That seems likely. On HC4, I try to use a CountingInputStream on instream, but the return size is uncompressed. // InputStream instream = entity.getContent(); InputStream instream = new CountingInputStream(entity.getContent()); res.setResponseData(readResponse(res, instream, (int) entity.getContentLength())); int cnt = ((CountingInputStream) instream).getCount(); log.debug(CNT= + cnt); I thinks that CountingInputStream must be in more deep in code, directly in HttpClient, or inside the Gzip/deflate input stream? Yes, you're right - the streams we currently use are somewhat removed from the actual input . For HC3 and Java, we decompress the inputstream directly, so could wrap that with a CountingInputStream first. However, the stream contains the de-chunked data, so the chunking overhead would not be seen. But it would be closer to the true size, and might be acceptable. Ideally, one would like to intercept the input stream before de-chunking, but I'm not sure that's possible with HC3 and Java. However with HC3 and HC4 one can provide custom sockets, so it would be possible to count the actual input. One could even detect the end of the header by looking for CRLF CRLF - but that might add an unacceptable overhead, in which case we could use the current header calculation which would be reasonably close. It's not possible to provide a custom socket implementation for Java HTTP, only Java HTTPS, so this approach would not work there, so we would have to use the CountingInputStream. I suggest we use the simple approach of CountingInputStream (CIS) for Java and HC3; it's easy to do and fairly accurate. No point spending lots of time on those implementations as HC4 is better. I'll have a look at HC4 to see what can be done - would you like to see if CIS works OK for HC3 and Java? HC4 keeps metrics on the connection, so it's very easy to find the actual byte counts for header and body. == I think we should consider changing the default to be the total network response size. However, this may affect some size assertions. HTTPSampleResult (v2.4) stores the decoded body size only. Maybe we should store the header and raw body sizes separately, rather than combining some of them. This would give the most flexibility. Also, consider adding the fields to SampleResult rather than HTTPSampleResult. For non-HTTP responses, the headerSize would normally be zero and raw body size would be the same as decoded body size, but e.g. for POP3 perhaps it would make sense to implement header size. Adding the fields to SampleResult would also make it easier to display them in the Tree View Listener (HTTPSampleResult is currently defined in a different jar which is built later - perhaps that's a mistake). - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 3 April 2011 23:19, Milamber milam...@apache.org wrote: Hello, Currently I works to add a optional property to get response size (in bytes) by different methods: 1/ default (responses data size (uncompressed length if gzip) 2/ responses headers length + default (response data size) 2/ responses headers length + content-length value (real size if gzip) See: https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 https://issues.apache.org/bugzilla/show_bug.cgi?id=50170 When I testing my future patch, I found this bug on HC4 Impl: When Web server (Apache 2.2) uses mod_deflate to compress response data, the data remains compress data (in view results tree, we have the compress characters and getBytes() is the compressed length) I thinks that must add a code section in sample() method when JMeter reads response data, to decode GZip response if needs, like HC3Impl? (perhaps HC4 has a specific method to do this?) HC4 should do this automatically, I think, but there was a bug whereby it did not recognise some encoding methods: https://issues.apache.org/jira/browse/HTTPCLIENT-1063 As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which JMeter trunk was recently updated to use). Can you check which version of HC4 you were using, and the Content-type used by Apache 2.2? Milamber Le 25/11/2010 15:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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] HTTP Sampler consolidation of implementations
On 6 April 2011 23:11, Milamber milam...@apache.org wrote: When Web server (Apache 2.2) uses mod_deflate to compress response data, the data remains compress data (in view results tree, we have the compress characters and getBytes() is the compressed length) I thinks that must add a code section in sample() method when JMeter reads response data, to decode GZip response if needs, like HC3Impl? (perhaps HC4 has a specific method to do this?) HC4 should do this automatically, I think, but there was a bug whereby it did not recognise some encoding methods: https://issues.apache.org/jira/browse/HTTPCLIENT-1063 As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which JMeter trunk was recently updated to use). Can you check which version of HC4 you were using, and the Content-type used by Apache 2.2? I uses last JMeter with HC v4.1.1 httpclient-4.1.1.jar httpmime-4.1.1.jar and httpcore-4.1.jar Response headers (extract) : Server: Apache/2.2.16 (Unix) DAV/2 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 70 Request Headers: Connection: keep-alive Accept-Encoding: gzip,deflate (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue) Issue too with www.google.com Thanks, that was useful, though strangely google would not gzip until I added a User-Agent of Firefox. Accepting gzip was not enough. Code now fixed - HC4 does support gzip decoding, but not by default. Milamber Milamber Le 25/11/2010 15:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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 - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] JUnit sampler sample time changes
That reminds me -
Tests I've done on Windows show that nanoTime() drifts considerably
when compared with currentTimeMillis(), i.e. its clock does not appear
to run at the same rate.
Here's a simple test you can run:
public class NanoDrift {
public static void main(String[] args) throws InterruptedException {
long systemTime = System.currentTimeMillis();
long nanoTime = System.nanoTime() / 100;
long count=0;
while(true){
long systemDiff = System.currentTimeMillis() - systemTime;
long nanoDiff = System.nanoTime() / 100 - nanoTime;
long absdiff = Math.abs(systemDiff-nanoDiff);
if (absdiff 100 || (count % 60 == 0)) {
System.out.println(@:+count+ |S-N|:+absdiff+
S:+systemDiff + N: + nanoDiff);
}
Thread.sleep(1000);
count++;
}
}
}
Behaviour may depend on the JVM used; on
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
I just got
@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60032 N:60032
@:120 |S-N|:1 S:120032 N:120033
@:180 |S-N|:2 S:180032 N:180034
@:240 |S-N|:6 S:240032 N:240038
@:300 |S-N|:7 S:300032 N:300039
@:360 |S-N|:13 S:360032 N:360045
@:420 |S-N|:14 S:420032 N:420046
@:480 |S-N|:15 S:480032 N:480047
@:540 |S-N|:16 S:540032 N:540048
@:600 |S-N|:17 S:600032 N:600049
@:660 |S-N|:18 S:660032 N:660050
@:720 |S-N|:19 S:720032 N:720051
@:780 |S-N|:20 S:780032 N:780052
@:840 |S-N|:21 S:840032 N:840053
@:900 |S-N|:22 S:900032 N:900054
@:960 |S-N|:23 S:960032 N:960055
@:1020 |S-N|:24 S:1020032 N:1020056
@:1080 |S-N|:21 S:1080063 N:1080084
@:1140 |S-N|:22 S:1140063 N:1140085
@:1200 |S-N|:23 S:1200063 N:1200086
@:1260 |S-N|:24 S:1260063 N:1260087
@:1320 |S-N|:21 S:1320172 N:1320193
@:1380 |S-N|:36 S:1380172 N:1380208
@:1440 |S-N|:37 S:1440172 N:1440209
@:1500 |S-N|:38 S:1500172 N:1500210
@:1560 |S-N|:40 S:1560172 N:1560212
@:1620 |S-N|:41 S:1620172 N:1620213
@:1680 |S-N|:42 S:1680172 N:1680214
@:1740 |S-N|:29 S:1740188 N:1740217
@:1800 |S-N|:30 S:1800188 N:1800218
@:1860 |S-N|:31 S:1860188 N:1860219
@:1920 |S-N|:31 S:1920188 N:1920219
@:1980 |S-N|:32 S:1980188 N:1980220
@:2040 |S-N|:33 S:2040188 N:2040221
@:2100 |S-N|:34 S:2100188 N:2100222
@:2160 |S-N|:35 S:2160188 N:2160223
@:2220 |S-N|:36 S:2220188 N:2220224
@:2280 |S-N|:37 S:2280188 N:2280225
@:2340 |S-N|:38 S:2340188 N:2340226
@:2400 |S-N|:39 S:2400188 N:2400227
@:2460 |S-N|:40 S:2460188 N:2460228
@:2520 |S-N|:41 S:2520188 N:2520229
However, on a FreeBSD system using
java version 1.6.0_03-p4
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_17_dec_2010_05_08-b00)
Java HotSpot(TM) 64-Bit Server VM (build
1.6.0_03-p4-root_17_dec_2010_05_08-b00, mixed mode)
I see no drift:
@:0 |S-N|:0 S:0 N:0
@:60 |S-N|:0 S:60118 N:60118
@:120 |S-N|:0 S:120239 N:120239
@:180 |S-N|:1 S:180357 N:180358
@:240 |S-N|:0 S:240476 N:240476
@:300 |S-N|:0 S:300594 N:300594
@:360 |S-N|:0 S:360713 N:360713
@:420 |S-N|:0 S:420830 N:420830
@:480 |S-N|:1 S:480948 N:480949
@:540 |S-N|:0 S:541066 N:541066
@:600 |S-N|:0 S:601184 N:601184
@:660 |S-N|:0 S:661302 N:661302
@:720 |S-N|:0 S:721419 N:721419
@:780 |S-N|:0 S:781537 N:781537
@:840 |S-N|:0 S:841655 N:841655
@:900 |S-N|:0 S:901773 N:901773
@:960 |S-N|:1 S:961890 N:961891
@:1020 |S-N|:0 S:1022008 N:1022008
@:1080 |S-N|:0 S:1082126 N:1082126
@:1140 |S-N|:0 S:1142244 N:1142244
@:1200 |S-N|:1 S:1202361 N:1202362
@:1260 |S-N|:1 S:1262479 N:1262480
@:1320 |S-N|:0 S:1322600 N:1322600
@:1380 |S-N|:1 S:1382748 N:1382749
@:1440 |S-N|:0 S:1442879 N:1442879
@:1500 |S-N|:1 S:1502997 N:1502998
@:1560 |S-N|:0 S:1563115 N:1563115
@:1620 |S-N|:0 S:1623233 N:1623233
@:1680 |S-N|:0 S:1683351 N:1683351
@:1740 |S-N|:0 S:1743468 N:1743468
@:1800 |S-N|:0 S:1803586 N:1803586
@:1860 |S-N|:0 S:1863704 N:1863704
@:1920 |S-N|:1 S:1923838 N:1923839
@:1980 |S-N|:0 S:1983959 N:1983959
@:2040 |S-N|:1 S:2044077 N:2044078
@:2100 |S-N|:0 S:2104195 N:2104195
@:2160 |S-N|:0 S:2164313 N:2164313
@:2220 |S-N|:1 S:2224430 N:2224431
@:2280 |S-N|:1 S:2284548 N:2284549
@:2340 |S-N|:0 S:2344666 N:2344666
@:2400 |S-N|:1 S:2404784 N:2404785
@:2460 |S-N|:0 S:2464903 N:2464903
@:2520 |S-N|:0 S:2525020 N:2525020
@:2580 |S-N|:0 S:2585138 N:2585138
@:2640 |S-N|:0 S:2645256 N:2645256
On 3 April 2011 13:50, Peter Lin wool...@gmail.com wrote:
Another important thing to consider is that nano time costs a lot more
than System.currentTimeMillis().
I've done some benchmarking in the past and nano time costs 30% on
windows. On linux, the cost is higher due to differences in how it's
implemented.
On Sun, Apr 3, 2011 at 5:28 AM, sebb seb...@gmail.com wrote:
On 3 April 2011 08:32, Ben Cuthbert ben_cuthb...@yahoo.co.uk wrote:
I see the nanotime. But the time in the sampler results is reported in ms.
So when you have you data
it just says 0. I would like it to go one further and report a low level.
Sorry, that's not possible currently
Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/
On 4 April 2011 00:13, milam...@apache.org wrote:
Author: milamber
Date: Sun Apr 3 23:13:09 2011
New Revision: 1088435
URL: http://svn.apache.org/viewvc?rev=1088435view=rev
Log:
Bug 50170 - Bytes reported by http sampler is after GUnZip
Add an optional property to allow change the method to get response size.
Modified:
jakarta/jmeter/trunk/bin/jmeter.properties
jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
jakarta/jmeter/trunk/xdocs/changes.xml
jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml
Modified: jakarta/jmeter/trunk/bin/jmeter.properties
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1088435r1=1088434r2=1088435view=diff
==
--- jakarta/jmeter/trunk/bin/jmeter.properties (original)
+++ jakarta/jmeter/trunk/bin/jmeter.properties Sun Apr 3 23:13:09 2011
@@ -243,6 +243,16 @@ log_level.jorphan=INFO
#log_config=logkit.xml
#---
+# HTTP common configuration
+#---
+
+# Response size calculate method
+# default: only data (uncompress size if deflate)
+#http.getbytes.type=default
+#http.getbytes.type=calculate_headers_size+default
+#http.getbytes.type=calculate_headers_size+content-length_value
These values are a bit complicated; I'd prefer to see true/false
values if possible.
+
+#---
# HTTP Java configuration
#---
Modified:
jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java?rev=1088435r1=1088434r2=1088435view=diff
==
--- jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
(original)
+++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java Sun
Apr 3 23:13:09 2011
@@ -36,10 +36,12 @@ import java.util.Iterator;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Locale;
+import java.util.Map.Entry;
import java.util.MissingResourceException;
import java.util.Properties;
import java.util.Random;
import java.util.ResourceBundle;
+import java.util.Set;
import java.util.StringTokenizer;
import java.util.Vector;
@@ -73,6 +75,8 @@ public class JMeterUtils implements Unit
new Perl5Compiler());
private static final String EXPERT_MODE_PROPERTY = jmeter.expertMode;
// $NON-NLS-1$
+
+ private static final String HEADER_CONTENT_LENGTH = Content-Length; //
$NON-NLS-1$
private static final String ENGLISH_LANGUAGE =
Locale.ENGLISH.getLanguage();
@@ -1237,4 +1241,19 @@ public class JMeterUtils implements Unit
return linkedHeaders;
}
+ /**
+ * Get Content-Length value from headers
+ * @param headers
+ * @return Content-Length value
+ */
+ public static int getHeaderContentLength(String headers) {
+ LinkedHashMapString, String lhm =
JMeterUtils.parseHeaders(headers);
+ SetEntryString, String keySet = lhm.entrySet();
+ for (EntryString, String entry : keySet) {
+ if (entry.getKey().equals(HEADER_CONTENT_LENGTH)) {
+ return Integer.parseInt(entry.getValue());
+ }
+ }
+ return 0; // Content-Length not found
This does not work for chunked input. It might be better to store the
actual response size when receiving the response, rather than trying
to calculate it later.
+ }
}
Modified:
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java?rev=1088435r1=1088434r2=1088435view=diff
==
---
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
(original)
+++
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSampleResult.java
Sun Apr 3 23:13:09 2011
@@ -23,6 +23,7 @@ import java.net.URL;
import org.apache.jmeter.protocol.http.util.HTTPConstants;
import org.apache.jmeter.samplers.SampleResult;
+import org.apache.jmeter.util.JMeterUtils;
/**
* This is a specialisation of the SampleResult class for the HTTP protocol.
@@ -31,6 +32,15 @@ import org.apache.jmeter.samplers.Sample
public class HTTPSampleResult extends SampleResult {
Re: [JMeter] JUnit sampler sample time changes
On 31 March 2011 19:41, Ben Cuthbert ben_cuthb...@yahoo.co.uk wrote: All I have been looking over the code in the JUnitSampler code under the jmeter source. I would like to make a change to use nanoTime() rather than milliseconds. Why? I can see in the AnnotatedTestCase there is an elapsed time. But I can't see how it is returned to a results table. Any ideas? The time in AnnotatedTestCase is only used for reporting timeout errors. The actual sample time is calculated using SampleResult.sampleStart() and sampleEnd() which already use nanoTime(). - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [VOTE][LAZY] Move Jakarta Regexp to Attic
On 22 March 2011 00:00, Rahul Akolkar rahul.akol...@gmail.com wrote: This is a vote to move Jakarta Regexp to the Apache Attic, based on the outcome of the most recent discussion on the topic. Since Regexp may not have enough PMC members active, this vote will be held by lazy consensus. If you object, please also provide a reasonable explanation. +1 Vote runs for a week, ending no sooner than Mar 28th, ~8:00 pm Eastern US. Vote is being held on general@jao but is being cross-posted to ensure we reach the full audience. Please include general@jao on any replies. -Rahul - 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: r1083962 - in /jakarta/jmeter/trunk: bin/ docs/images/screenshots/ docs/images/screenshots/http-config/ src/core/org/apache/jmeter/resources/ src/protocol/http/org/apache/jmeter/protoc
I get a compiler error with Java 1.5: [javac] D:\eclipseworkspaces\main\JMeter_trunk\src\protocol\http\org\apache\jmeter\protocol\http\sampler\HTTPSamplerBase.java:11 90: cannot find symbol [javac] symbol : method invokeAll(java.util.ArrayListorg.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.ASyncSample) [javac] location: class java.util.concurrent.ThreadPoolExecutor [javac] final ListFutureHTTPSampleResult retExec = exec.invokeAll(liste); [javac] ^ Looks like invokeAll is Java 1.6+? On 21 March 2011 21:20, milam...@apache.org wrote: Author: milamber Date: Mon Mar 21 21:20:56 2011 New Revision: 1083962 URL: http://svn.apache.org/viewvc?rev=1083962view=rev Log: Bug 50943 - Allowing concurrent downloads of embedded resources in html page Modified: jakarta/jmeter/trunk/bin/jmeter.properties jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png jakarta/jmeter/trunk/docs/images/screenshots/http-request.png jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/HttpDefaultsGui.java jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java jakarta/jmeter/trunk/xdocs/changes.xml jakarta/jmeter/trunk/xdocs/images/screenshots/http-config/http-request-defaults.png jakarta/jmeter/trunk/xdocs/images/screenshots/http-request.png jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml Modified: jakarta/jmeter/trunk/bin/jmeter.properties URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1083962r1=1083961r2=1083962view=diff == --- jakarta/jmeter/trunk/bin/jmeter.properties (original) +++ jakarta/jmeter/trunk/bin/jmeter.properties Mon Mar 21 21:20:56 2011 @@ -682,6 +682,8 @@ beanshell.server.file=../extras/startup. #httpsampler.max_redirects=5 # Maximum frame/iframe nesting depth (default 5) #httpsampler.max_frame_depth=5 +# Maximum await termination timeout (secs) when concurrent download embedded resources (default 60) +#httpsampler.await_termination_timeout=60 # The encoding to be used if none is provided (default ISO-8859-1) #sampleresult.default.encoding=ISO-8859-1 Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png?rev=1083962r1=1083961r2=1083962view=diff == Binary files - no diff available. Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-request.png URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-request.png?rev=1083962r1=1083961r2=1083962view=diff == Binary files - no diff available. Modified: jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties?rev=1083962r1=1083961r2=1083962view=diff == --- jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties (original) +++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties Mon Mar 21 21:20:56 2011 @@ -1024,6 +1024,7 @@ web_server_domain=Server Name or IP\: web_server_port=Port Number\: web_testing2_source_ip=Source IP address: web_testing2_title=HTTP Request HTTPClient +web_testing_concurrent_download=Use concurrent pool. Size: web_testing_embedded_url_pattern=Embedded URLs must match\: web_testing_retrieve_images=Retrieve All Embedded Resources from HTML Files web_testing_title=HTTP Request Modified: jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties?rev=1083962r1=1083961r2=1083962view=diff == --- jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties (original) +++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties Mon Mar 21 21:20:56 2011 @@ -927,6 +927,7 @@ web_server_timeout_response=R\u00E9ponse web_server_timeout_title=D\u00E9lai expiration (ms) web_testing2_source_ip=Adresse IP source \:
Re: svn commit: r1083962 - in /jakarta/jmeter/trunk: bin/ docs/images/screenshots/ docs/images/screenshots/http-config/ src/core/org/apache/jmeter/resources/ src/protocol/http/org/apache/jmeter/protoc
The error was from Ant, using java version 1.5.0_22 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03) Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode) but I also see an error in Eclipse: The method invokeAll(CollectionCallableT) in the type AbstractExecutorService is not applicable for the arguments (ArrayListHTTPSamplerBase.ASyncSample)HTTPSamplerBase.java On 21 March 2011 22:46, Milamber milam...@apache.org wrote: Hello, No, invokeAll() is Java 1.5 http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection,%20long,%20java.util.concurrent.TimeUnit%29 I use 1.5 complier compliance level in Eclipse for project with a JDK 1.6 (on Linux) I will change with JDK 1.5 to search to reproduce compiler error Milamber Le 21/03/2011 22:33, sebb a ecrit : I get a compiler error with Java 1.5: [javac] D:\eclipseworkspaces\main\JMeter_trunk\src\protocol\http\org\apache\jmeter\protocol\http\sampler\HTTPSamplerBase.java:11 90: cannot find symbol [javac] symbol : method invokeAll(java.util.ArrayListorg.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.ASyncSample) [javac] location: class java.util.concurrent.ThreadPoolExecutor [javac] final ListFutureHTTPSampleResult retExec = exec.invokeAll(liste); [javac] ^ Looks like invokeAll is Java 1.6+? On 21 March 2011 21:20, milam...@apache.org wrote: Author: milamber Date: Mon Mar 21 21:20:56 2011 New Revision: 1083962 URL: http://svn.apache.org/viewvc?rev=1083962view=rev Log: Bug 50943 - Allowing concurrent downloads of embedded resources in html page Modified: jakarta/jmeter/trunk/bin/jmeter.properties jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png jakarta/jmeter/trunk/docs/images/screenshots/http-request.png jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/HttpDefaultsGui.java jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java jakarta/jmeter/trunk/xdocs/changes.xml jakarta/jmeter/trunk/xdocs/images/screenshots/http-config/http-request-defaults.png jakarta/jmeter/trunk/xdocs/images/screenshots/http-request.png jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml Modified: jakarta/jmeter/trunk/bin/jmeter.properties URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/bin/jmeter.properties?rev=1083962r1=1083961r2=1083962view=diff == --- jakarta/jmeter/trunk/bin/jmeter.properties (original) +++ jakarta/jmeter/trunk/bin/jmeter.properties Mon Mar 21 21:20:56 2011 @@ -682,6 +682,8 @@ beanshell.server.file=../extras/startup. #httpsampler.max_redirects=5 # Maximum frame/iframe nesting depth (default 5) #httpsampler.max_frame_depth=5 +# Maximum await termination timeout (secs) when concurrent download embedded resources (default 60) +#httpsampler.await_termination_timeout=60 # The encoding to be used if none is provided (default ISO-8859-1) #sampleresult.default.encoding=ISO-8859-1 Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-config/http-request-defaults.png?rev=1083962r1=1083961r2=1083962view=diff == Binary files - no diff available. Modified: jakarta/jmeter/trunk/docs/images/screenshots/http-request.png URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/images/screenshots/http-request.png?rev=1083962r1=1083961r2=1083962view=diff == Binary files - no diff available. Modified: jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties?rev=1083962r1=1083961r2=1083962view=diff == --- jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties (original) +++ jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties Mon Mar 21 21:20:56 2011 @@ -1024,6 +1024,7 @@ web_server_domain=Server Name or IP\: web_server_port=Port Number\: web_testing2_source_ip=Source IP address: web_testing2_title=HTTP Request HTTPClient +web_testing_concurrent_download=Use concurrent pool. Size
Re: svn commit: r1084019 - /jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
Thanks, that's fixed it. On 21 March 2011 23:32, milam...@apache.org wrote: Author: milamber Date: Mon Mar 21 23:32:17 2011 New Revision: 1084019 URL: http://svn.apache.org/viewvc?rev=1084019view=rev Log: Correct a compiler error with a real JDK 1.5 Bug 50943 - Allowing concurrent downloads of embedded resources in html page - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: JMETER [Bug 50943] New: Allowing concurrent downloads of embedded resources in html page
On 17 March 2011 23:06, Milamber milam...@apache.org wrote: Hello, I would like commit this patch next week. Any comments are welcome. OK by me, so long as it does not affect existing test plan behaviour if not selected. Milamber Original Message Subject: DO NOT REPLY [Bug 50943] New: Allowing concurrent downloads of embedded resources in html page Date: Thu, 17 Mar 2011 18:52:34 -0400 (EDT) From: bugzi...@apache.org Reply-To: dev@jakarta.apache.org To: notificati...@jakarta.apache.org https://issues.apache.org/bugzilla/show_bug.cgi?id=50943 Summary: Allowing concurrent downloads of embedded resources in html page Product: JMeter Version: Nightly (Please specify date) Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTTP AssignedTo: notificati...@jakarta.apache.org ReportedBy: milam...@apache.org Created an attachment (id=26782) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26782) Patch to concurrent download embedded resources This patch add a option in HTTP Requests (Java mode, HC3/4) and HTTP Requests defaults to get concurrently the embedded resources (css, images, javascript, etc.) in html page. This may be useful for some tests to try to simulate multiple http connections like a modern browser. (in example: Firefox 3.6 use 6 parallels connections) -- 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: JMeter - include JChart2D (LGPL v2.1) to JMeter
On 28 February 2011 21:28, Milamber milam...@apache.org wrote: Hello, Does it possible to include the jar JChart2D, under LGPL v2.1, in JMeter main (ASF license)? http://jchart2d.sourceforge.net/index.shtml No, we cannot include the jar in JMeter downloads, see: http://www.apache.org/legal/resolved.html#category-x Thanks. 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: JMeter - include JChart2D (LGPL v2.1) to JMeter
On 28 February 2011 22:50, Milamber milam...@apache.org wrote: Hello, Ok no jar. I've developed a new graph visualiser with JChart2D. To integrate this element on JMeter, I must create a jar plugin/source code on a website like code.google.com/sourceforge? It would probably be better at http://apache-extras.org/ or I can put him in Jmeter main with a note for download separately the J2Char2D jar file? Possibly. I'm trying to find out about that. Milamber Le 28/02/2011 22:17, sebb a ecrit : On 28 February 2011 21:28, Milamber milam...@apache.org wrote: Hello, Does it possible to include the jar JChart2D, under LGPL v2.1, in JMeter main (ASF license)? http://jchart2d.sourceforge.net/index.shtml No, we cannot include the jar in JMeter downloads, see: http://www.apache.org/legal/resolved.html#category-x Thanks. 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 - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community
On 28 February 2011 22:35, Vince Adamo vad...@tech-consortium.com wrote: Philippe, I opened an enhancement request and attached the source. See Bug 50842 - Adobe AMF Protocol Sampler based on HTTPSampler2 Please feel free to e-mail me with any comments and/or questions. Unfortunately, the BlazeDS library is LGPL 3, which cannot be included in ASF releases. Thanks again, Vince -Original Message- From: Vince Adamo [mailto:vad...@tech-consortium.com] Sent: Monday, February 28, 2011 4:01 PM To: dev@jakarta.apache.org Subject: RE: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community Thanks! I will create an issue, attach the code to it and update this thread with the issue number. -Original Message- From: Philippe Mouawad [mailto:philippe.moua...@gmail.com] Sent: Monday, February 28, 2011 3:59 PM To: dev@jakarta.apache.org Subject: Re: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community Hello M. Adamo, I am interested in integrating your library. Maybe you can create an issue and attach your code to it. I would try to integrate within the next 2 months. Regards Philippe On Mon, Feb 28, 2011 at 10:50 PM, Vince Adamo vad...@tech-consortium.comwrote: I recently completed the development of a JMeter sampler for testing Flex/BlazeDS applications using Adobe's AMF Protocol over Http. I would like to contribute this sampler to the JMeter community but it has been developed as a Maven project and not as an integrated sampler in the JMeter project tree. The artifact produced by this project is a jar file (ApacheJMeter_amf.jar) that is automatically deployed, during the maven install phase, to the local JMeter installation's /lib/ext directory. The dependent BlazeDS jars are also copied to the local JMeter installations /lib directory. The implementation I would like to release is a subclass of HTTPSampler2 and provides extension points for custom AMF messages using a mechanism borrowed from the AbstractJavaSamplerClient concept. When I began this effort several months ago I searched the JMeter web site and mailing list for any existing support for the AMF protocol. I only saw recommendations for using the Java sampler, in combination with the BlazeDS AmfMessage class, to implement support for this protocol. I actually went down that road but found that the BlazeDS AmfMessage class uses the default Java Http implementation. This caused problems when testing with certain load balancers using sticky session handling via cookies, even when handling the cookies within the Java sampler. To solve this problem I needed to ensure that the connection used by the AMF sampler was not being shared with other threads and preferably the one used to establish the sticky session with the load balancer, which happened to be a connection established using an HTTPClient sampler performing authentication for our application. Therefore I chose to extend the HTTPSampler2 class. In any event, I am wondering if there is a precedence for releasing open source thirdparty samplers outside of the JMeter project, or whether one of the current contributors would be interested and willing to integrate this project into the main JMeter source tree. Please let me know your thoughts. Thanks, Vince Adamo -- 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 - 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: r1065011 - /jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
On 30 January 2011 10:40, Milamber milam...@apache.org wrote: Hello The documentation (component_reference) needs to be update too. Yes, I was intending to do that later. In my opinion, the lower case workaround for order isn't the best choice for have Thread Group first. Doesn't better to change the menu factory to manage an optional order? Yes, that would be better, but this works for now. I won't object if anyone else wants to fix it - I'm not sure when I will do so. Milamber Le 29/01/2011 12:39, s...@apache.org a ecrit : Author: sebb Date: Sat Jan 29 12:39:12 2011 New Revision: 1065011 URL: http://svn.apache.org/viewvc?rev=1065011view=rev Log: Rename Pre and Post Thread Group labels: - more like JUnit, so should be more familiar - lower-case initial letter to sort after the main one - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: Small feature request - test start time stored in StandardJMeterEngine
2011/1/14 Stéphane Hoblingre stephane.hoblin...@gmail.com: Hi, I'm committer in JMeter Plugins project ( http://code.google.com/p/jmeter-plugins/) and would like to add in our charts relative time. For this, I need to get the test start time. Could it be possible to store this value in the StandardJMeterEngine object with a static getter ? http://jakarta.apache.org/jmeter/usermanual/functions.html#predefinedprops Thanks and regards, Stephane - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: svn commit: r1057347 - /jakarta/jmeter/trunk/build.xml
On 12 January 2011 09:20, sebb seb...@gmail.com wrote:
On 11 January 2011 17:40, Milamber milam...@apache.org wrote:
Hello,
With fork=no, all test cases aren't execute when run ant tests (or
distribution).
Thanks.
I'm looking into that now.
The problem seems to be that the dir=${basedir}/bin is silently
ignored when fork=no,.
This affects the classpath scanning.
I need to find a different way to fix the Gump builds.
Milamber
Le 10/01/2011 20:28, s...@apache.org a ecrit :
Author: sebb
Date: Mon Jan 10 20:28:28 2011
New Revision: 1057347
URL: http://svn.apache.org/viewvc?rev=1057347view=rev
Log:
Try fork=no for fixing classpath issue with Gump tests
Modified:
jakarta/jmeter/trunk/build.xml
Modified: jakarta/jmeter/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1057347r1=1057346r2=1057347view=diff
==
--- jakarta/jmeter/trunk/build.xml (original)
+++ jakarta/jmeter/trunk/build.xml Mon Jan 10 20:28:28 2011
@@ -1859,7 +1859,8 @@ run JMeter unless all the JMeter jars ar
delete quiet=true
fileset dir=${basedir}/bin/testfiles includes=*.jmx.out/
/delete
- java classname=org.apache.jorphan.test.AllTests fork=yes
failonerror=true dir=${basedir}/bin
+ !-- fork=yes causes problems for Gump builds. --
+ java classname=org.apache.jorphan.test.AllTests fork=no
failonerror=true dir=${basedir}/bin
classpath
fileset dir=${dest.jar} includes=*.jar/
pathelement location=${build.test}/
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [Jakarta-jmeter Wiki] Update of AdminGroup by JMeterAdmin
On 30 December 2010 17:39, Antoine Levy-Lambert anto...@gmx.de wrote: Hi, I see that you guys are maintaining a page to prevent bad content. I do not know how to do it myself. I would need to do the same for Ant and Gump's wikis. Just create the page LocalBadContent. I was also wondering whether infra maintains a global bad content list for all the wikis ? AFAIK there is no central bad content list. There used to be one, but AIUI the code to handle it no longer worked when the Wiki code was updated to a newer version. Antoine On 12/30/2010 10:24 AM, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-jmeter Wiki for change notification. The AdminGroup page has been changed by JMeterAdmin. http://wiki.apache.org/jakarta-jmeter/AdminGroup -- New page: This is a list of people who can do editing of the LocalBadContent page: * Upayavira * DanielQuinlan * JoeSchaefer * JMeterAdmin - 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 - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 6 December 2010 21:45, Milamber milam...@apache.org wrote: Hello, I have got last checkout last JMeter SVN, and executed ant's task dist. With a simple test plan, I have this error with a new HTTP HC4 sampler: 2010/12/06 21:08:45 ERROR - jmeter.threads.JMeterThread: Error while processing sampler 'Page2' : org.apache.commons.lang.NotImplementedException: Code is not implemented at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:43) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:970) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:956) at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:369) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:262) at java.lang.Thread.run(Thread.java:662) Have I forgot something? No - I've not yet finished working on the HC4 sampler. Milamber Le 06/12/2010 11:35, sebb a ecrit : Le 26/11/2010 00:28, sebb a ecrit : On 25 November 2010 23:13, Milamber milam...@apache.org wrote: Hello, Your plan seems very well. Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there has three http samplers thus will introduce some confusing for a new user? (what http sampler is the best for my test?) It will have to be documented. In theory, HC4 will be the best, but it may take a while to get the JMeter interface code working correctly. So I did not want to replace HC3 with HC4. Once it is well established, HC3 can be made optional, at which point JMeter would revert to two choices again. (Actually, my understanding is the Java Http sampler is the legacy and reliable, and Hc3 is new challenger and is better for httpS request...) Another ask: what will be the default sampler? Currently it is the Java sampler, but I plan to make it configurable with a JMeter property. AJP sampler seems not very used like sampler. Keep his independence will be good for the evolution of federated http sampler. Milamber Le 25/11/2010 15:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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 - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] Convert to Maven based build?
On 26 November 2010 16:54, Phil Steitz p...@steitz.com wrote: On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar rahul.akol...@gmail.comwrote: On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien tobr...@discursive.com wrote: On Nov 25, 2010, at 2:29 PM, Peter Lin wool...@gmail.com wrote: even though I haven't been active in jmeter in a while, I am still a jmeter committer. Quantify a while. snip/ No need, we have archives for the curious. I'm still a committee on various projects. Would I veto a change by someone with a defined need who shows initiative? No. If Peter Lynch has the itch, why not let him experiment? This place works on initiative, not a series of subjective objections to a tool he wishes to use. This place works only if people like yourself (like myself) get out of the way of people more active than ourselves. snap/ All good above. Finally, the onus is on those who experiment to convince those who do the work here that the proposed changes are then worthy. +1 As one data point for a potential contributor, I will share the following. I have been lurking on this list for quite some time and intending to eventually propose some ideas/patches for enhancements. We look forward to seeing these! Seeing this thread, i thought it would be a good idea to see how hard it was for me to get set up to build the code and run the tests. The answer is it took me about 10 minutes, which is frankly less time than most maven-built projects take to get going and *way less* than any nontrivial maven build. I particularly like that there is a README as well as a building.html that clearly describe the simple steps necessary to get set up. If you follow the directions to download the dependent jars and replace the Eclipse .classpath file with eclipse.classpath, Eclipse is fully set up. I did not try to actually run anything from within Eclipse, as I find that is in general a bad idea for anything nontrivial; Eclipse can easily be used for running and debugging JMeter, but running some of the JUnit tests can be a bit of a pain as they need the classpath to be set up correctly. but the nicely documented ant build.xml worked for me out of the box. It was impressive to me that I did not have to fuss with any local property settings, given the amount of config that Jmeter and its tests use. [I did get the following test failure: [java] 1) runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError: serialization of org.apache.jmeter.functions.gui.FunctionHelper failed: java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI Looks Apple-specific. I am running java version 1.6.0_22 Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)] It does seem to be Apple-specific, though perhaps the field that holds the GUI item could be made transient to avoid the problem. The JMeter GUI does not need to be serialisable - only the test element etc. that are required for running in client-server mode. The FunctionHelper is GUI only, so could be dropped entirely from the serialisation tests. Two of the ten minutes were spent fussing with Eclipse because I had replaced the classpath before downloading the jars. Closing and reopening the project was not enough to get Eclipse to stop thinking the jars were missing. I had to recreate it after the jars were in place. It might be better to change the instructions to remind people to download the jars before creating the Eclipse project. I can submit a patch for that if others agree this is a good idea. +1 So I am personally finding it hard to believe that mavenizing the build is really going to make it easier for people to get involved with Jmeter. If there are Jmeter artifacts of general usefulness, I think it would be a *good thing* to develop either Ant or Maven targets to get them published. That would be a much easier task than trying to get the full Jmeter build working in Maven. +1 Seems to me to be a useful gain. Is that something that can be easily done in Maven, using the current directory layout and jar contents? Patches welcome (via Bugzilla please). I agree strongly with Rahul and Peter Lin though that this decision belongs to them who do the work. Thanks. I'm not against Maven per se, but I have not seen it used on a project with so many output jars and which makes assumptions about locations of jars. I may be wrong, but I can see no benefit to converting to a Maven build, and there are several potential blockers which I (and others) have already mentioned else-thread. I can see no point in starting the process when it might not be possible to achieve its goal. So I don't intend personally to spend any time working on creating a Maven build for JMeter. Phil -Rahul - To
[JMeter] HTTP Sampler consolidation of implementations
Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
On 25 November 2010 23:13, Milamber milam...@apache.org wrote: Hello, Your plan seems very well. Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there has three http samplers thus will introduce some confusing for a new user? (what http sampler is the best for my test?) It will have to be documented. In theory, HC4 will be the best, but it may take a while to get the JMeter interface code working correctly. So I did not want to replace HC3 with HC4. Once it is well established, HC3 can be made optional, at which point JMeter would revert to two choices again. (Actually, my understanding is the Java Http sampler is the legacy and reliable, and Hc3 is new challenger and is better for httpS request...) Another ask: what will be the default sampler? Currently it is the Java sampler, but I plan to make it configurable with a JMeter property. AJP sampler seems not very used like sampler. Keep his independence will be good for the evolution of federated http sampler. Milamber Le 25/11/2010 15:45, sebb a ecrit : Just a heads up that I'm currently working on trying to combine the HTTP implementations (Java, HttpClient3) into a single GUI, with run-time choice of implementation. The rationale for this is that HttpClient 4 is now available, and it would be good to add that, but I think we should keep HttpClient for backwards compatibility and comparison. Creating another GUI/Sampler set is easy enough, but it would be useful to be able to switch implementations easily - currently that requires switching samplers (e.g. by editting the JMX file). The current plan is to allow the implementation to be specified on the HTTP Request Defaults config screen as well as on the HTTP Request screen. The code is a bit involved, because the Config settings are processed at run-time after the test plan has been built. [But even the Sampler GUI needs to create the sampler before it can store the sampler settings - and the implementation can then be changed.] Currently I use a Sampler Proxy that dispatches to the appropriate implementation class. These classes have to extend an abstract class that provides the necessary methods to interface with the Proxy test element and thus provide access to the test element properties. That part seems to be working OK. The next phase is to ensure that existing JMX files can be converted (during load) to use the new sampler. The intention is to keep the existing Java and HttpClient samplers, so that subclasses will continue to work, but not expose them in the GUI. I've not finally decided about the AJP sampler - it can be easily converted, but I don't think there's much of a use case for switching between AJP and another implementation. - 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: r1036752 - /jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
On 19 November 2010 07:28, milam...@apache.org wrote:
Author: milamber
Date: Fri Nov 19 07:28:51 2010
New Revision: 1036752
URL: http://svn.apache.org/viewvc?rev=1036752view=rev
Log:
Seems to miss a close parenthesis
Thanks!
[Was using a different system to do the edit does not have a suitable
compiler. Thought I could do without!]
Modified:
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
Modified:
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java?rev=1036752r1=1036751r2=1036752view=diff
==
---
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
(original)
+++
jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/proxy/HttpRequestHdr.java
Fri Nov 19 07:28:51 2010
@@ -439,7 +439,7 @@ public class HttpRequestHdr {
// Set the file uploads
sampler.setHTTPFiles(urlConfig.getHTTPFileArgs().asArray());
// used when postData is pure xml (eg. an xml-rpc call) or for PUT
- } else if (postData.trim().startsWith(?) ||
PUT.equals(sampler.getMethod()) {
+ } else if (postData.trim().startsWith(?) ||
PUT.equals(sampler.getMethod())) {
sampler.addNonEncodedArgument(, postData, );
} else if (contentType == null ||
contentType.startsWith(HTTPConstants.APPLICATION_X_WWW_FORM_URLENCODED) ){
// It is the most common post request, with parameter name
and values
-
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: r1036578 - /jakarta/jmeter/trunk/build.xml
On 18 November 2010 19:14, milam...@apache.org wrote: Author: milamber Date: Thu Nov 18 19:14:25 2010 New Revision: 1036578 URL: http://svn.apache.org/viewvc?rev=1036578view=rev Log: Update URL for get package list (javadoc generating) Well spotted! Modified: jakarta/jmeter/trunk/build.xml Modified: jakarta/jmeter/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/jmeter/trunk/build.xml?rev=1036578r1=1036577r2=1036578view=diff == --- jakarta/jmeter/trunk/build.xml (original) +++ jakarta/jmeter/trunk/build.xml Thu Nov 18 19:14:25 2010 @@ -1568,7 +1568,7 @@ run JMeter unless all the JMeter jars ar packagenames=org.apache.jmeter.*,org.apache.jorphan.* excludepackagenames=org.apache.jorphan.timer classpath refid=classpath/ - link href=http://java.sun.com/j2se/1.5.0/docs/api// + link href=http://download.oracle.com/javase/1.5.0/docs/api// /javadoc /target - 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: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/
On 3 November 2010 09:32, sebb seb...@gmail.com wrote:
On 3 November 2010 08:03, Milamber milam...@apache.org wrote:
Hello,
When I use Ant script [tests] (on same project), I have the following
errors :
* 1 error with jdk1.6_21
* 1 error + 4 failures with jdk1.6_22
For the error, I think that must remove a slash in
test/src/org/apache/jmeter/services/TestFileServer.java
on this line : infile=findTestPath(/testfiles/test.csv);
to infile=findTestPath(testfiles/test.csv);
Oops!
No idea why this works on Windows.
For failures, I don't understand now (I don't really searching the root
cause)
Me neither, but I will investigate.
Looks like the HTTP implementation has changed - it no longer seems to
send the Content-Length header with POST requests.
I'm also updating the build script and test code so Hudson should
catch failures better.
== JDK1.6 u21=
[echo]
[echo] gump.run = false
[echo] java.awt.headless = ${java.awt.headless}
[echo] test.headless =
[echo] user.dir =
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[echo] basedir =
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[echo] test dir = build/test
[echo] test dir gump = build/test
[echo] testsaveservice.saveout = ${testsaveservice.saveout}
[echo]
[java] Setting JMeterHome:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[java] Setting up logging props using file:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] Using initializeProperties() from
org.apache.jmeter.util.JMeterUtils
[java] Setting up initial properties using:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] Initializing Properties:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] java.version=1.6.0_21
[java] java.home=/home/milamber/opt/jdk1.6.0_21/jre
[java]
user.dir=/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin
[java] os.name=Linux
[java] os.version=2.6.32-5-amd64
[java] +++
[java] java.awt.headless=
[java] java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
[java]
[java] Creating test suite
[java] Scanning build/test for test cases
[java] ClassFinder found: 87 TestCase classes
[java] INFO: JMeterGUIComponent: skipping some tests
org.apache.jmeter.testbeans.gui.TestBeanGUI
[java] Created: 87 tests including 8 suites
[java] Starting test run, test count = 1999
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] ...E..
[java] .
[java
Re: svn commit: r1028515 - in /jakarta/jmeter/trunk: bin/ bin/examples/ src/core/org/apache/jmeter/reporters/ src/core/org/apache/jmeter/services/ xdocs/ xdocs/usermanual/
On 3 November 2010 10:18, sebb seb...@gmail.com wrote:
On 3 November 2010 09:32, sebb seb...@gmail.com wrote:
On 3 November 2010 08:03, Milamber milam...@apache.org wrote:
Hello,
When I use Ant script [tests] (on same project), I have the following
errors :
* 1 error with jdk1.6_21
* 1 error + 4 failures with jdk1.6_22
For the error, I think that must remove a slash in
test/src/org/apache/jmeter/services/TestFileServer.java
on this line : infile=findTestPath(/testfiles/test.csv);
to infile=findTestPath(testfiles/test.csv);
Oops!
No idea why this works on Windows.
For failures, I don't understand now (I don't really searching the root
cause)
Me neither, but I will investigate.
Looks like the HTTP implementation has changed - it no longer seems to
send the Content-Length header with POST requests.
Appears to be related to this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6996110
as setting sun.net.http.allowRestrictedHeaders=true allows the test
to complete successfully.
Unfortunately sun.net.http.allowRestrictedHeaders does not appear to
be documented anywhere yet apart from the bug report.
I'm also updating the build script and test code so Hudson should
catch failures better.
== JDK1.6 u21=
[echo]
[echo] gump.run = false
[echo] java.awt.headless = ${java.awt.headless}
[echo] test.headless =
[echo] user.dir =
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[echo] basedir =
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[echo] test dir = build/test
[echo] test dir gump = build/test
[echo] testsaveservice.saveout = ${testsaveservice.saveout}
[echo]
[java] Setting JMeterHome:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration
[java] Setting up logging props using file:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] Using initializeProperties() from
org.apache.jmeter.util.JMeterUtils
[java] Setting up initial properties using:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] Initializing Properties:
/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin/testfiles/jmetertest.properties
[java] java.version=1.6.0_21
[java] java.home=/home/milamber/opt/jdk1.6.0_21/jre
[java]
user.dir=/home/milamber/W-workspaces/Workspaces-JMeter/JMeter-Integration/bin
[java] os.name=Linux
[java] os.version=2.6.32-5-amd64
[java] +++
[java] java.awt.headless=
[java] java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
[java]
[java] Creating test suite
[java] Scanning build/test for test cases
[java] ClassFinder found: 87 TestCase classes
[java] INFO: JMeterGUIComponent: skipping some tests
org.apache.jmeter.testbeans.gui.TestBeanGUI
[java] Created: 87 tests including 8 suites
[java] Starting test run, test count = 1999
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java
Re: New JMeter Skin
On 2 November 2010 20:10, Joe Rice joerice...@gmail.com wrote: Hi, I have been an avid JMeter user / fan for years. I would like to port JMeter from Swing to SWT (eclipse) to give it a fresh interface and also allow eclipse plugin support. I also have a number of suggested improvements around managing load test runs, but first things first. First step would be a port to Eclipse. I am setting up a Google Code project to accomplish this. Before getting too far, I wanted to get feedback acceptance from the community on this idea. If there is anyone interested in helping, that would be awesome, too :-). thoughts? JMeter is intended to be a pure Java application so that it runs on any compliant JVM. However SWT is not pure Java and is not supported on as many platforms as Swing, so would not be acceptable for the JMeter project. Likewise, JMeter is not currently tied to any IDE. An optional Eclipse add-on would of course be OK. Thanks, Joe - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: [JMeter] Extending JMeter: Shared Data Set
On 9 September 2010 13:05, Jens Müller jen...@hotmail.com wrote: Hello, JMeter does not seem to include a test element that allows a string out of a list to be assinged to a variable, guaranteeing at most once semantics for all users, even in distributed mode. Meaning that every element of the list will only be used once, even trhoughout multiple test runs. I have the following in mind: Creating a ConfigTestElement (currently a TestBean) which allows the user to add a list of values. When starting the test, this list would be put into a centrally accessible singleton and everytime a value would be read in iterationStart, it would be removed from this central list and assigned to a variable, similarly to CSV Data Set Config, only that the value is not read from a file. So far possible. But it will require large amounts of memory. When the test is completed, only the remaining unused values should be present in the test element. How can I modify a specific element in the test tree? If I implement TestListener and change the list in testEnded, this change is not applied to the test element if I open it in the test plan. It is probably cloned, but even by overriding clone and keeping a reference to the original element, I cannot get the test element's values changes. Furthermore, in distributed mode, I would need to split the list in equal parts to the different client hosts. This could be done somewhere in ClientJMeterEngine#Configure, not cloning the element, but taking a sublist of the complete list. The total number of hosts and the number of the current host would need to be known for this. These two values could be filled into some context in RemoteStart#doAction. Every host would then perform its test run and at the end, they would need to send back the sublist of unused items. As far as I understand, only the Listeners are wrapped with RemoteListenerWrapper so that they can transfer back information. Maybe the information which elements of the list were not used can be piggybacked somewhere on testEnded? The compund list of remaining items would then again need to be incorporated into the original test element - a problem I already described above. Any help in solving any of these sub tasks is very appreciated. It will be complicated to do this as you describe it. The StringFromFile function has a feature which allows it to read from multiple files. This was created to solve a problem whereby we could only use an account number once in a test. So we created lots of files, each with a different subset of the valid numbers. For each test, we made a note of which files had been used, and updated the start and end numbers accordingly. One way to do this in distributed mode might be to enhance CSV DataSet. - add a starting line number, so it would skip that number of lines when opening the file. - log the finishing line number; this can be used for determining the next test starting value. - for multiple remote servers, you could also add an increment value, so it would only read every Nth record. Start and end line numbers for CSV Dataset might be useful anyway, and should be easy to add. Likewise increment. However I'm not sure how you get each server to start with a different line. Perhaps JMeter could set a special property to the server number when starting multiple server tests. One could just edit the properties on each server, but that would be tedious. You could play around with reading a database table, and use the hostname as the key to the CSV start/increment/ending variables. Jens - 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
[ANNOUNCE] JMeter 2.4 is released
The Apache JMeter team announces the availability of Apache JMeter 2.4 r961953. This is a new release which corrects a lot of bugs and adds many new features. JMeter 2.4 requires Java 1.5 or later to run. == All users are recommended to upgrade. == Apache JMeter is a Java application designed to test server applications. It can be used to: * generate test loads * test functional behaviour * measure performance. It includes support for protocols such as HTTP(S), JDBC, JMS, FTP, and others. It can also be extended with user-written code. See http://jakarta.apache.org/jmeter/ The release can be downloaded from: http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi When downloading, please verify signatures using the KEYS file. Only the binary archive is needed to run JMeter - there is no need to download the source archive. However there are some optional libraries which are not included. See the Getting Started page for details: http://jakarta.apache.org/jmeter/usermanual/get-started.html The list of changes since version 2.3.4 can be found at: http://jakarta.apache.org/jmeter/changes.html All users are recommended to upgrade to this release. Enjoy! The JMeter team - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
