Re: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)
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) 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.
Re: DO NOT REPLY [Bug 52033] Allowing multiple certificates (JKS)
I wanted to add a property called keystore_eager_load=false (by default). 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.
ISSUE 52033
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 ? 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.
Re: JMeter SVN move completed
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. 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.
Start Next Loop fix
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). 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. 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. 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) -- 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.
Issue 51861
Hello Sebb, Did you have some time to review patch for issue 51861 ? If yes Are you OK if I commit it ? In fact I am doing some load tests on GWT and it is really difficult to work without it. Hope you have some time to take it into account. Regards Philippe
Issue 52044
Hello sebb, Regarding: 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. If it was the case then there was an issue in this, because 2 threads could share the same Context in initial implementation. Maybe an issue with perf, I will add thread name to key Regards On Wed, Oct 19, 2011 at 8:02 AM, sebb seb...@gmail.com wrote: 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 -- Cordialement. Philippe Mouawad.
[Bug 52040] Add a toolbar in JMeter main window
Hello Milamber, I vote for it, I find it great : - we gain one click each time - I found icons were very meaningful Some notes (matter of taste :-)): - - and + buttons seem bit wide no ? Maybe one missing icon for Start no pauses. Regards Philippe
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)
On Tue, Oct 11, 2011 at 2:38 PM, sebb seb...@gmail.com wrote: 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. OK So if the raw flag is set, we don't do a merge; otherwise keep current behaviour. OK 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. OK , I will add it to patch . Should it be a boolean in UrlConfigGUI or another class ? (First solution is simple) 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. OK, will add it to patch 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 -- Cordialement. Philippe Mouawad.
sampleStart call differences between HC4 and HC3
Hello, Lookiing at similarities in code between 2 clases, I don't understand why sampleStart is not called at the same place for the 2 classes ? - In HC3 it is called before building httpRequest - In HC4 it is called after that and after building BasicHttpContext Shouldn't the 2 call sampleStart just before calling sendPostData / sendPutData? Regards Philippe
Patch 52001
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. If you give me the go, I will patch it. Regards Philippe
Re: DO NOT REPLY [Bug 52019] Add menu option to enable/disable timers when running Plan
Hello Sebb, Do you agree with this proposition : - Add an Menu Option called Run with timers disabled - This option will set a boolean on GuiPackage#getinstance() called noTimersPause - Timers will consult this option to decide whether to run or not pause - At end of run option will be reset (what would be the best way to detect end, StandardJMeterEngine#run after waitThreadsStopped ?) 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
Re: svn commit: r1183065 - in /jakarta/jmeter/trunk: src/core/org/apache/jmeter/engine/ src/core/org/apache/jmeter/gui/action/ src/core/org/apache/jmeter/gui/util/ src/core/org/apache/jmeter/resources
(Ignoring timer node:+ node); +} +addLast(node); This looks wrong, surely you don't want to add the node? No otherwise you will get NoSuchElementException +} +} +} However, the whole approach looks wrong. Why not just override addLast(), and skip super.addLast() if processing a Timer? Don't understand why - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org -- Cordialement. Philippe Mouawad.
Re: DO NOT REPLY [Bug 52013] View Results Tree does not take into account proxy excluded URLs
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). 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 ? 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.
Issue 51876
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 ? Thank you Regards Philippe
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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. Regarding the need to clone sampler, why do we need this, is there some data that may be corrupted except CookieManager ? 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. 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 Modify HTTPSamplerBase#getCookieManager to get CookieManager first from Thread Local then from testElement. (as today) Waiting for your comments on this. I was thinking that ignoring cookies would simplify the problem, but it does not seem to. So the only change we would need to do is to clone the cookies for each task, and collect them again at the end. No need to make the cookie storage class thread-safe. OK Regards Philippe On Mon, Oct 3, 2011 at 5:02 PM, sebb seb...@gmail.com wrote: On 3 October 2011 15:39, Philippe Mouawad philippe.moua...@gmail.com wrote: On Mon, Oct 3, 2011 at 4:31 PM, sebb seb...@gmail.com wrote
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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.
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).
- Create a Bean AsynSamplerResultHolder that will hold:
- HTTPSampleResult
- Cookie[]
*Conc download:*
- Pass CookieManager to AsynSampler, clone it and add existing cookie,
and store it in ThreadLocal
- 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
*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
Modify HTTPSamplerBase#getCookieManager to get CookieManager first from
Thread Local then from testElement. (as today)
Waiting for your comments on this.
Regards
Philippe
On Mon, Oct 3, 2011 at 5:02 PM, sebb seb...@gmail.com wrote:
On 3 October 2011 15:39, Philippe Mouawad philippe.moua...@gmail.com
wrote:
On Mon, Oct 3, 2011 at 4:31 PM, sebb seb...@gmail.com wrote:
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 am not sure Frame couldn't be concerned by this case, so in my opinion
it
should be a parameter not ignored by default.
I'd overlooked frame.
I'm looking at passing the current sampler to the AsyncSampler class,
which can then clone it.
I think that will create an independent set of cookies, so there can
be no need to protect against concurrent updates.
Agree, that's how I imagined it, but then you agree you have to store
CookieManager in thread local ?
If cookies are being ignored, then the cookie manager property can
just be cleared - i.e. there is no cookie manager.
Alternatively, it will also need to be cloned.
We then need to consider if non-concurrent downloads should still be
processed for cookies.
Conc and serial should have the same behaviour
PS : Does it mean that you are working on issue and will fix it on your
side
Not yet decided; we need to agree on the approach first.
Regards
Philippe
On Mon, Oct 3, 2011 at 2:29 PM, sebb 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
Re: Running ant test fails
Works for me now. Thanks. Regards Philippe On Mon, Oct 3, 2011 at 5:54 PM, sebb seb...@gmail.com wrote: 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 -- Cordialement. Philippe Mouawad.
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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.
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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
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 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
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
On Mon, Oct 3, 2011 at 4:31 PM, sebb seb...@gmail.com wrote:
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 am not sure Frame couldn't be concerned by this case, so in my opinion it
should be a parameter not ignored by default.
I'm looking at passing the current sampler to the AsyncSampler class,
which can then clone it.
I think that will create an independent set of cookies, so there can
be no need to protect against concurrent updates.
Agree, that's how I imagined it, but then you agree you have to store
CookieManager in thread local ?
We then need to consider if non-concurrent downloads should still be
processed for cookies.
Conc and serial should have the same behaviour
PS : Does it mean that you are working on issue and will fix it on your side
?
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
Running ant test fails
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 -- Cordialement. Philippe Mouawad.
Re: Running ant test fails
Apache Ant version 1.7.1 compiled on June 27 2008 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.
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
Hello,
By the way I think there is also an issue in CacheManager due to the use of
InheritableThreadLocal (which is not thread safe).
Indeed this Map is shared by concurrent children thread, so Map is accessed
concurrently but not thread-safe = ISSUE
I made a little main sample that I can attach to an issue if you want to
see Map is shared
See this:
- http://www.ibm.com/developerworks/java/library/j-threads3/index.html
Regards
Philippe Mouawad
On Mon, Oct 3, 2011 at 5:28 PM, sebb seb...@gmail.com wrote:
On 3 October 2011 16:07, Shmuel Krakower shmul...@gmail.com wrote:
Hi,
Why isn't Cookie manager implemented the way Cache manager is (using a
thread local hash map)?
Probably mainly historical.
Cookies are currently stored in an ArrayList, but one could perhaps
use a HashMap instead.
Though that won't work if cookie names can change - the current
implementation does allow pre-defined cookies to be defined in terms
of variables/functions.
Is there a use-case for variable cookie names? Perhaps; it seems quite
likely that variable values would be useful.
I don't know off-hand if that would still work if the code switched to
(Inheritable)ThreadLocal.
If it would be implemented the same way - the fix should be the same as
on
the Cache manager case (
https://issues.apache.org/bugzilla/show_bug.cgi?id=51752)
Regards,
Shmuel Krakower.
On Mon, Oct 3, 2011 at 5:02 PM, sebb seb...@gmail.com wrote:
On 3 October 2011 15:39, Philippe Mouawad philippe.moua...@gmail.com
wrote:
On Mon, Oct 3, 2011 at 4:31 PM, sebb seb...@gmail.com wrote:
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 am not sure Frame couldn't be concerned by this case, so in my
opinion
it
should be a parameter not ignored by default.
I'd overlooked frame.
I'm looking at passing the current sampler to the AsyncSampler class,
which can then clone it.
I think that will create an independent set of cookies, so there can
be no need to protect against concurrent updates.
Agree, that's how I imagined it, but then you agree you have to store
CookieManager in thread local ?
If cookies are being ignored, then the cookie manager property can
just be cleared - i.e. there is no cookie manager.
Alternatively, it will also need to be cloned.
We then need to consider if non-concurrent downloads should still be
processed for cookies.
Conc and serial should have the same behaviour
PS : Does it mean that you are working on issue and will fix it on
your
side
Not yet decided; we need to agree on the approach first.
Regards
Philippe
On Mon, Oct 3, 2011 at 2:29 PM, sebb 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
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
I opened :
https://issues.apache.org/bugzilla/show_bug.cgi?id=51942
and provided patch.
Regards
Philippe
On Mon, Oct 3, 2011 at 6:16 PM, Philippe Mouawad philippe.moua...@gmail.com
wrote:
Hello,
By the way I think there is also an issue in CacheManager due to the use
of InheritableThreadLocal (which is not thread safe).
Indeed this Map is shared by concurrent children thread, so Map is accessed
concurrently but not thread-safe = ISSUE
I made a little main sample that I can attach to an issue if you want to
see Map is shared
See this:
- http://www.ibm.com/developerworks/java/library/j-threads3/index.html
Regards
Philippe Mouawad
On Mon, Oct 3, 2011 at 5:28 PM, sebb seb...@gmail.com wrote:
On 3 October 2011 16:07, Shmuel Krakower shmul...@gmail.com wrote:
Hi,
Why isn't Cookie manager implemented the way Cache manager is (using a
thread local hash map)?
Probably mainly historical.
Cookies are currently stored in an ArrayList, but one could perhaps
use a HashMap instead.
Though that won't work if cookie names can change - the current
implementation does allow pre-defined cookies to be defined in terms
of variables/functions.
Is there a use-case for variable cookie names? Perhaps; it seems quite
likely that variable values would be useful.
I don't know off-hand if that would still work if the code switched to
(Inheritable)ThreadLocal.
If it would be implemented the same way - the fix should be the same as
on
the Cache manager case (
https://issues.apache.org/bugzilla/show_bug.cgi?id=51752)
Regards,
Shmuel Krakower.
On Mon, Oct 3, 2011 at 5:02 PM, sebb seb...@gmail.com wrote:
On 3 October 2011 15:39, Philippe Mouawad philippe.moua...@gmail.com
wrote:
On Mon, Oct 3, 2011 at 4:31 PM, sebb seb...@gmail.com wrote:
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 am not sure Frame couldn't be concerned by this case, so in my
opinion
it
should be a parameter not ignored by default.
I'd overlooked frame.
I'm looking at passing the current sampler to the AsyncSampler
class,
which can then clone it.
I think that will create an independent set of cookies, so there can
be no need to protect against concurrent updates.
Agree, that's how I imagined it, but then you agree you have to store
CookieManager in thread local ?
If cookies are being ignored, then the cookie manager property can
just be cleared - i.e. there is no cookie manager.
Alternatively, it will also need to be cloned.
We then need to consider if non-concurrent downloads should still be
processed for cookies.
Conc and serial should have the same behaviour
PS : Does it mean that you are working on issue and will fix it on
your
side
Not yet decided; we need to agree on the approach first.
Regards
Philippe
On Mon, Oct 3, 2011 at 2:29 PM, sebb 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
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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 ? Regards Philippe On Sun, Oct 2, 2011 at 4:29 PM, sebb seb...@gmail.com wrote: 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 -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release JMeter 2.5.1 RC3
I don't think I can vote, but +1 for me as an unofficial vote :-) 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 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
Re: [VOTE] Release JMeter 2.5.1 RC3
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 - 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.
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show parameters without name (Raw Body)
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 ? No problem for me if it is not taken into account in this release provided it is in next or not too far in the future so that patches are still valid :-) 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. Ubik-Ingénierie
Re: [VOTE] Release JMeter 2.5.1 RC1
Hello Stéphane Hoblinfre, Can you test with last build, issue you submitted has been fixed. Regards Philippe 2011/9/26 Stéphane Hoblingre stephane.hoblin...@gmail.com Yes true, the bug happens also with the DummySampler of our plugins ( http://code.google.com/p/jmeter-plugins/) and appeared from 2.5.1 only. Stef On Mon, Sep 26, 2011 at 9:18 PM, sebb seb...@gmail.com wrote: On 26 September 2011 09:32, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello I attached all infos on ISSUE: - Test case - Log file in DEBUG - Thread Dump Note that I reproduced it every time with what I described in issue. I can also now reproduce the deadlock easily with HC4 and mirror server. I was using a simplified test case that had caused the deadlock prior to my fix, but was not causing the dealock afterwards. This was because it only had one sample - that had been sufficient originally, but was not sufficient later. Sorry, that's my fault; should have stayed with the original test case. The fix I made to HC4 - overriding the retryRequest() method - actually only works for a single sampler, because the interrupted variable is fetched from the class instance that was used to create the override. I introduced the interrupted variable, because the fix from https://issues.apache.org/jira/browse/HTTPCLIENT-1120 did not seem to work. I need to look at that again. This is needed to stop HC4 from retrying aborted requests, which I think is a separate issue from the deadlocks. I now think there's a subtle bug in JMeterThread. I had expected the interrupt to complete, and then the sample to complete, thus the shutdown code would run after the interrupt code. However, it looks as though the sample can complete before the interrupt method returns. This allows the thread to run the shutdown code whilst the interrupt is still in progress. In turn this triggers the deadlock issue in HC4, but could equally cause issues with other samplers. The code needs to ensure that shutdown cannot happen whilst an interrupt is in progress. I'll commit a fix to SVN ASAP. Sorry Milamber, but I think we need to cancel this RC vote. I also attached a patch that works on my tests. I let you check. Regards Philippe Mouawad On Sun, Sep 25, 2011 at 1:46 PM, sebb seb...@gmail.com wrote: On 25 September 2011 12:22, sebb seb...@gmail.com wrote: On 25 September 2011 01:45, Milamber milam...@apache.org wrote: Le 25/09/2011 00:08, sebb a ecrit : 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? Found one Java-level deadlock: = Thread-205: waiting to lock monitor 0x00d0bf78 (object 0xe2c89ba8, a org.apache.http.impl.conn.SingleClientConnManager), which is held by Thread Group 1-1 Thread Group 1-1: waiting to lock monitor 0x0205e638 (object 0xe3425510, a org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter), which is held by Thread-205 Java stack information for the threads listed above: === Thread-205: at org.apache.http.impl.conn.SingleClientConnManager.releaseConnection(SingleClientConnManager.java:258) - waiting to lock 0xe2c89ba8 (a org.apache.http.impl.conn.SingleClientConnManager
Issue 51861
Hello Sebb, Did you have some time to look at patch for issue 51861 ? Are there any pending problems in submitted patch ? Thank you Regards Philippe
Re: [VOTE] Release JMeter 2.5.1 RC1
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
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
uses gzip/defate mode). br/brTo return to settings before version 2.5, set the two properties to false./note /p +p +bRetry handling/bbr/br +In version 2.5 of JMeter, the HttpClient4 sampler used the default retry count, which was 3. +As this can hide server errors, JMeter now sets the retry count to 0 to prevent any automatic retries. +This can be overridden by setting the JMeter property bhttpclient4.retrycount/b. +/p links link href=test_plan.html#assertionsAssertion/link link href=build-web-test-plan.htmlBuilding a Web Test Plan/link - 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 -- Cordialement. Philippe Mouawad. Ubik-Ingénierie
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
Again, I just implemented Retry on HTTPHC3.1 setting it to 0 and I get low 0.12% error like with HTTP 4.1. Do you want me to submit a patch to HTTPHC3.1 ? Regards Philippe On Fri, Sep 23, 2011 at 2:23 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, Don't you think you should keep default to 0 and add same configuration to HTTPHC3 ? Maybe it's a real server issue that is hidden by retry set to 3. Can't we check in Jakarta apache logs to see if these errors are mentionned ? Regards Philippe On Fri, Sep 23, 2011 at 11:12 AM, Milamber milam...@apache.org wrote: Hello, (on JMeter 2.5.1RC1) Don't retry automatically with HC4 sampler seems introduce a bug on load tests using HC4. When you run a load test, some errors The target server failed to respond can appear on response data. With wireshark, this error arrives at the end of TCP conversations: the GET request is sent, but no server response (the connection has been closed, I suppose). If I changes the property httpclient4.retrycount to 3, the load tests works fine, with no errors. This bug is tested on Linux with JVM5/7 and WinXP with JVM7 Test case is the Simple Test Case on this bugs: https://issues.apache.org/bugzilla/show_bug.cgi?id=51863 (Note: no errors with HC3.1) (Questions: retrycount exists on HC3.1? if yes what default value?) Response data org.apache.http.NoHttpResponseException: The target server failed to respond at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247) at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996) at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276) at java.lang.Thread.run(Thread.java:595) = Milamber Le 01/09/2011 17:52, s...@apache.org a ecrit : Author: sebb Date: Thu Sep 1 17:52:41 2011 New Revision: 1164186 URL: http://svn.apache.org/viewvc?rev=1164186view=rev Log: Don't automatically retry with HttpCLient4 sampler Modified: jakarta/jmeter/trunk/bin/jmeter.properties jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.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=1164186r1=1164185r2=1164186view=diff == --- jakarta/jmeter/trunk/bin/jmeter.properties (original) +++ jakarta/jmeter/trunk/bin/jmeter.properties Thu Sep 1 17:52:41 2011 @@ -251,7 +251,7 @@ log_level.jorphan=INFO # 0 now means don't retry connection (in 2.3 and before it meant no tries at all!) #--- -# HTTPClient configuration +# Commons HTTPClient configuration #--- # define a properties file for overriding Commons HttpClient parameters @@ -302,7 +302,7 @@ log_level.jorphan=INFO #log_file.httpclient=httpclient.log -# Apache HttpClient logging examples +# Apache Commons HttpClient logging examples # # Enable header wire + context logging - Best for Debugging #log_level.org.apache.http=DEBUG @@ -320,6 +320,13 @@ log_level.jorphan=INFO #log_level.org.apache.http.client=DEBUG
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
Done: https://issues.apache.org/bugzilla/attachment.cgi?bugid=51882 Regards Philippe On Fri, Sep 23, 2011 at 2:34 PM, sebb seb...@gmail.com wrote: On 23 September 2011 13:29, Philippe Mouawad philippe.moua...@gmail.com wrote: Again, I just implemented Retry on HTTPHC3.1 setting it to 0 and I get low 0.12% error like with HTTP 4.1. Do you want me to submit a patch to HTTPHC3.1 ? Would be useful, thanks. Regards Philippe On Fri, Sep 23, 2011 at 2:23 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, Don't you think you should keep default to 0 and add same configuration to HTTPHC3 ? Maybe it's a real server issue that is hidden by retry set to 3. Can't we check in Jakarta apache logs to see if these errors are mentionned ? Regards Philippe On Fri, Sep 23, 2011 at 11:12 AM, Milamber milam...@apache.org wrote: Hello, (on JMeter 2.5.1RC1) Don't retry automatically with HC4 sampler seems introduce a bug on load tests using HC4. When you run a load test, some errors The target server failed to respond can appear on response data. With wireshark, this error arrives at the end of TCP conversations: the GET request is sent, but no server response (the connection has been closed, I suppose). If I changes the property httpclient4.retrycount to 3, the load tests works fine, with no errors. This bug is tested on Linux with JVM5/7 and WinXP with JVM7 Test case is the Simple Test Case on this bugs: https://issues.apache.org/bugzilla/show_bug.cgi?id=51863 (Note: no errors with HC3.1) (Questions: retrycount exists on HC3.1? if yes what default value?) Response data org.apache.http.NoHttpResponseException: The target server failed to respond at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:101) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:252) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:247) at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:219) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:298) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:265) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1010) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:996) at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:383) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:276) at java.lang.Thread.run(Thread.java:595) = Milamber Le 01/09/2011 17:52, s...@apache.org a ecrit : Author: sebb Date: Thu Sep 1 17:52:41 2011 New Revision: 1164186 URL: http://svn.apache.org/viewvc?rev=1164186view=rev Log: Don't automatically retry with HttpCLient4 sampler Modified: jakarta/jmeter/trunk/bin/jmeter.properties jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.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=1164186r1=1164185r2=1164186view=diff == --- jakarta/jmeter/trunk/bin/jmeter.properties (original) +++ jakarta/jmeter/trunk/bin/jmeter.properties Thu Sep 1 17:52:41 2011 @@ -251,7 +251,7 @@ log_level.jorphan=INFO # 0 now means don't retry connection (in 2.3 and before it meant no tries at all!) #--- -# HTTPClient configuration +# Commons HTTPClient configuration #--- # define a properties file for overriding Commons HttpClient
Re: Classloading issue
Hello,
I added a note to:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=51854
Regards
Philippe
On Fri, Sep 23, 2011 at 1:46 PM, sebb seb...@gmail.com wrote:
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
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
Nightly builds
Hello, I have a question regarding nightly builds, when are they built ? Why for example do we have one with date 09/21 while there has been patches yesterday and today ? Is there some delay ? Thanks Regards Philippe Mouawad
Re: JMeter OS tested
Thanks for your help, I think I don't have the right yet. But now page does not work anymore. Regards Philippe On Tue, Sep 20, 2011 at 4:21 PM, Nermin Caluk nermin.ca...@gmail.comwrote: 1. hit the Edit link (if you have permissions): [image: ScreenShot018.jpg] 2. answer the tricky question: [image: ScreenShot019.jpg] 3. hit Save Changes Nermin On 20 September 2011 16:14, Philippe Mouawad philippe.moua...@gmail.comwrote: Hi Again, I don't see way to edit. I am not sure I have the right. Can you tell me what's the button ? Thanks Regards On Tue, Sep 20, 2011 at 3:56 PM, sebb seb...@gmail.com wrote: 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 -- Cordialement. Philippe Mouawad. Ubik-Ingénierie -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk -- Cordialement. Philippe Mouawad. Ubik-Ingénierie
Re: JMeter OS tested
Page is back, still have :Immutable Page Regards Philippe On Tue, Sep 20, 2011 at 4:26 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Thanks for your help, I think I don't have the right yet. But now page does not work anymore. Regards Philippe On Tue, Sep 20, 2011 at 4:21 PM, Nermin Caluk nermin.ca...@gmail.comwrote: 1. hit the Edit link (if you have permissions): [image: ScreenShot018.jpg] 2. answer the tricky question: [image: ScreenShot019.jpg] 3. hit Save Changes Nermin On 20 September 2011 16:14, Philippe Mouawad philippe.moua...@gmail.comwrote: Hi Again, I don't see way to edit. I am not sure I have the right. Can you tell me what's the button ? Thanks Regards On Tue, Sep 20, 2011 at 3:56 PM, sebb seb...@gmail.com wrote: 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 -- Cordialement. Philippe Mouawad. Ubik-Ingénierie -- *Nermin ČALUK* nermin.ca...@gmail.com http://ba.linkedin.com/in/caluk -- Cordialement. Philippe Mouawad. Ubik-Ingénierie -- Cordialement. Philippe Mouawad. Ubik-Ingénierie
Question about issues management
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 ? Thanks. Regards Philippe
Re: [JMeter] release 2.5.1 to fix issues in 2.5?
Hello, A new one: - 47888 https://issues.apache.org/bugzilla/show_bug.cgi?id=47888 Regards Philippe On Sun, Sep 18, 2011 at 11:25 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, Last 2 patches: - 50617 https://issues.apache.org/bugzilla/show_bug.cgi?id=50617 - 51840 https://issues.apache.org/bugzilla/show_bug.cgi?id=51840 Not urgent for me, can be in another release. Regards Philippe On Sun, Sep 18, 2011 at 10:56 AM, sebb seb...@gmail.com wrote: On 18 September 2011 09:45, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, Thank you very much for your reactivity in taken into accounts the patches. I can submit some more patches if you have some time to answer questions about some: - 51840 https://issues.apache.org/bugzilla/show_bug.cgi?id=51840 = Is there some listener that gets notified when a project is closed ? No, but the TestListener testEnded method would probably be suitable. - 43539 https://issues.apache.org/bugzilla/show_bug.cgi?id=43539 = Shouln't bug be renamed to Monitor results are not saved to file , I asked a question In another issue that you closed as WONTFIX I cannot find it's number, it was about the up part of the panel with filename that is not used at all (monitor results are not saved to file although code seems to do it , because somewhere ResultCollector#out is null) This is going to be complicated to fix, and is not critical, so leave for later - 49462 https://issues.apache.org/bugzilla/show_bug.cgi?id=49462 = Question is in issue I'll have a look at that; solution may have to wait for next release. By the way,I closed 51667https://issues.apache.org/bugzilla/show_bug.cgi?id=51667(If I am wrong reopen) OK Regards Philippe On Sun, Sep 18, 2011 at 1:41 AM, sebb seb...@gmail.com wrote: On 17 September 2011 22:44, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, New submissions that may be integrated: - 51691 https://issues.apache.org/bugzilla/show_bug.cgi?id=51691 Fixed - 51841 https://issues.apache.org/bugzilla/show_bug.cgi?id=51841 Fixed - 49976 https://issues.apache.org/bugzilla/show_bug.cgi?id=49976 Fixed - 51380 https://issues.apache.org/bugzilla/show_bug.cgi?id=51380 = Is patch Ok or must I fix tabs, Milamber I am not sure I understood fully the comment ? Fixed. And about those : 47269 https://issues.apache.org/bugzilla/show_bug.cgi?id=47269 = Duplicate ? Possibly. To be investigated further. 47921 https://issues.apache.org/bugzilla/show_bug.cgi?id=47921 = Closable, if another leak occurs we will have new bug no ? Closed. Thanks for all the patches you have provided recently. Is there anything else urgent we've overlooked that needs to go into the next release? - 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 -- Cordialement. Philippe Mouawad. Ubik-Ingénierie -- Cordialement. Philippe Mouawad. Ubik-Ingénierie
DO NOT REPLY [Bug 51840] JMS : Cache of InitialContext has some issues
Hello, I closed bug as fixed, don't know if I had to do it or it's up to you. 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
Re: [JMeter] release 2.5.1 to fix issues in 2.5?
Hello, New submissions that may be integrated: - 51691 https://issues.apache.org/bugzilla/show_bug.cgi?id=51691 - 51841 https://issues.apache.org/bugzilla/show_bug.cgi?id=51841 - 49976 https://issues.apache.org/bugzilla/show_bug.cgi?id=49976 - 51380 https://issues.apache.org/bugzilla/show_bug.cgi?id=51380 = Is patch Ok or must I fix tabs, Milamber I am not sure I understood fully the comment ? And about those : 47269 https://issues.apache.org/bugzilla/show_bug.cgi?id=47269 = Duplicate ? 47921 https://issues.apache.org/bugzilla/show_bug.cgi?id=47921 = Closable, if another leak occurs we will have new bug no ? Regards Philippe On Fri, Sep 16, 2011 at 12:19 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hi Again, And those 2 ones: - 42141 https://issues.apache.org/bugzilla/show_bug.cgi?id=42141 - 42246 https://issues.apache.org/bugzilla/show_bug.cgi?id=42246 Regards Philippe On Thu, Sep 15, 2011 at 10:54 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: And 51830 https://issues.apache.org/bugzilla/show_bug.cgi?id=51830 and 47921 https://issues.apache.org/bugzilla/show_bug.cgi?id=47921 On Thu, Sep 15, 2011 at 10:43 PM, Benoit Wiart benoit.wi...@gmail.comwrote: 51605 And 51822 the first patch could / should be applied : please do not close the bug as more patch should follow On Wed, Sep 14, 2011 at 11:47 AM, sebb seb...@gmail.com wrote: I'm thinking it might be worth releasing 2.5.1 soon. The main reason is to fix the bug in HttpClient4 connection handling, but there have been a few other useful fixes. What do you think? If there are any quick fix bugs we can squash, let's do those (e.g. I've nearly finished on Bug 48943), but more resistant bugs could be left for a later release. - 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 -- Cordialement. Philippe Mouawad. Ubik-Ingénierie -- Cordialement. Philippe Mouawad. Ubik-Ingénierie
Re: [JMeter] release 2.5.1 to fix issues in 2.5?
And 51830 https://issues.apache.org/bugzilla/show_bug.cgi?id=51830 and 47921 https://issues.apache.org/bugzilla/show_bug.cgi?id=47921 On Thu, Sep 15, 2011 at 10:43 PM, Benoit Wiart benoit.wi...@gmail.comwrote: 51605 And 51822 the first patch could / should be applied : please do not close the bug as more patch should follow On Wed, Sep 14, 2011 at 11:47 AM, sebb seb...@gmail.com wrote: I'm thinking it might be worth releasing 2.5.1 soon. The main reason is to fix the bug in HttpClient4 connection handling, but there have been a few other useful fixes. What do you think? If there are any quick fix bugs we can squash, let's do those (e.g. I've nearly finished on Bug 48943), but more resistant bugs could be left for a later release. - 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
Re: [JMeter] release 2.5.1 to fix issues in 2.5?
Hello, 39219 patch should not be very impacting, maybe you can integrate it in version. Regards Philippe On Wed, Sep 14, 2011 at 11:47 AM, sebb seb...@gmail.com wrote: I'm thinking it might be worth releasing 2.5.1 soon. The main reason is to fix the bug in HttpClient4 connection handling, but there have been a few other useful fixes. What do you think? If there are any quick fix bugs we can squash, let's do those (e.g. I've nearly finished on Bug 48943), but more resistant bugs could be left for a later release. - 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
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
Re: [JMeter] Offer to submit JMeter AMF Sampler to JMeter community
Thank you. I Will do. Regards Philippe On Monday, February 28, 2011, 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. 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 -- 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
[jira] Updated: (DBCP-28) [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
[ http://issues.apache.org/jira/browse/DBCP-28?page=all ]
Philippe Mouawad updated DBCP-28:
-
Attachment:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
ShowsLeaksIfCheckForIsClosed.java
TestUtils.java
Hello,
The files contain an illustration of the problem that will occur when the the
previous patches will be applied in 1.2.2:
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does
not allow double close without throwing (see
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported here because conn.isClosed() will return true and the client will not
call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and the
client may have already called close, so he ends up calling close() twice, see
what happens if the isClosed() in PoolableConnection returns true :
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose
So My question is, what can I do if the double close is not allowed by DBCP
[dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g
driver)
---
Key: DBCP-28
URL: http://issues.apache.org/jira/browse/DBCP-28
Project: Commons Dbcp
Type: Bug
Versions: 1.2 Final
Environment: Operating System: All
Platform: PC
Reporter: Dirk Verbeeck
Fix For: 1.2.2
Attachments: PoolableConnection.patch,
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java,
ShowsLeaksIfCheckForIsClosed.java, TestPoolableConnection.patch,
TestUtils.java
Mail from Hugh Winkler on commons-dev (15-2-2005)
--
PoolableConnection.close() does logic equivalent to :
if ( isClosed()){
throw new SQLException(.);
} else {
_pool.returnObject(this);
}
The isClosed() method is that of ancestor DelegatingConnection, and it does:
if(_closed || _conn.isClosed()) {
return true;
}
return false;
Now nothing prevents the underlying connection from closing itself; that's
why isClosed() checks _conn.isClosed() -- did you close yourself while I
wasn't looking? But in that case PoolableConnection never calls
_pool.returnObject().
I've got a query in Oracle 10g that causes Oracle's connection to close
itself: the famous end of file on connection message causes the connection
to enter the closed state. Doesn't take long to exhaust the pool.
I think the logic we want in PoolableConnection.close() is like so:
if ( _closed ){ // really ask, did *we* close the connection already
throw new SQLException(.);
} else {
_pool.returnObject(this);
}
If I've got some logic wrong please stop me before I deploy that change
here!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-3) [dbcp] PoolableConnection.close() won't allow multiple close
[ http://issues.apache.org/jira/browse/DBCP-3?page=comments#action_12420734
]
Philippe Mouawad commented on DBCP-3:
-
See Comment of [Philippe Mouawad] 12/Jul/06 09:19 PM for a problem that occurs
if this bug is not corrected.
http://issues.apache.org/jira/browse/DBCP-28
Philippe.
[dbcp] PoolableConnection.close() won't allow multiple close
Key: DBCP-3
URL: http://issues.apache.org/jira/browse/DBCP-3
Project: Commons Dbcp
Type: Bug
Versions: Nightly Builds
Environment: Operating System: All
Platform: All
Reporter: Adam Jenkins
Fix For: 1.3
Sun's javadoc for java.sql.Connection.close() specifies that calling close on
an
already closed Connection is a no-op. However, PoolableConnection.close() (v
1.10) throws a SQLException if close() is called on a closed Connection.
PoolableConnection.close() should just return if the Connection is already
closed. Here is a patch:
To demonstrate the bug, just obtain an open PoolableConnection and call
close()
on it twice; the second call will produce a SQLException. According to Sun's
spec, the second close() should just be a no-op. The current behaviour is
preferable to the old behaviour where it returned the Connection to the pool
twice, but it's still not according to the spec.
Here's a patch:
*** PoolableConnection.java.orig2003-09-15 16:07:53.0 -0400
--- PoolableConnection.java 2003-09-15 16:08:11.0 -0400
***
*** 108,114
*/
public synchronized void close() throws SQLException {
if(isClosed()) {
! throw new SQLException(Already closed.);
} else {
try {
_pool.returnObject(this);
--- 108,114
*/
public synchronized void close() throws SQLException {
if(isClosed()) {
! return;
} else {
try {
_pool.returnObject(this);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)
BasicDataSource returns negative values for NumActive when Oracle Driver
Connection#isClosed return true (End of file communication on CHannel)
---
Key: DBCP-193
URL: http://issues.apache.org/jira/browse/DBCP-193
Project: Commons Dbcp
Type: Bug
Versions: 1.2.1, 1.2.2
Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK 1.4.2_08 /
Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
Reporter: Philippe Mouawad
Priority: Blocker
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
http://issues.apache.org/jira/browse/DBCP-3
http://issues.apache.org/jira/browse/DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does
not allow double close without throwing (see
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in http://issues.apache.org/jira/browse/DBCP-28 because
conn.isClosed() will return true and the client will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and the
client may have already called close, so he ends up calling close() twice, see
what happens if the isClosed() in PoolableConnection returns true :
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-193) BasicDataSource returns negative values for NumActive when Oracle Driver Connection#isClosed return true (End of file communication on CHannel)
[ http://issues.apache.org/jira/browse/DBCP-193?page=all ]
Philippe Mouawad updated DBCP-193:
--
Attachment:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
ShowsLeaksIfCheckForIsClosed.java
TestUtils.java
To work, the call isClosed() in PoolableConnection.java must return true (Case
of an End of communication on channel in Oracle):
public synchronized void close() throws SQLException {
boolean isClosed = false;
try {
isClosed = isClosed();
BasicDataSource returns negative values for NumActive when Oracle Driver
Connection#isClosed return true (End of file communication on CHannel)
---
Key: DBCP-193
URL: http://issues.apache.org/jira/browse/DBCP-193
Project: Commons Dbcp
Type: Bug
Versions: 1.2.1, 1.2.2
Environment: Windows / Oracle 10G JDBC driver / Oracle 10G / JDK 1.4.2_08 /
Commons-dbcp-1.2.1.jar / COmmons-pool-1.3.jar
Reporter: Philippe Mouawad
Priority: Blocker
Attachments:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java,
ShowsLeaksIfCheckForIsClosed.java, TestUtils.java
Hello,
This bug occurs if the following conditions are met:
A End of File communication on CHannel occurs
Oracle Driver 10G will return true for Connection#isClosed()
Related bugs:
http://issues.apache.org/jira/browse/DBCP-3
http://issues.apache.org/jira/browse/DBCP-28
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp
does not allow double close without throwing (see
http://issues.apache.org/jira/browse/DBCP-3)
= The problem is that since he calls isClosed, he encounters the same bug
reported in http://issues.apache.org/jira/browse/DBCP-28 because
conn.isClosed() will return true and the client will not call close.
if (!conn.isClosed())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed.java
Case2:
The client tries to find a solution, and calls conn.close() without checking
isClosed(), but the problem is that the client is in a Persistence fwk and
the client may have already called close, so he ends up calling close()
twice, see what happens if the isClosed() in PoolableConnection returns true
: ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] digester XML (call-param-rule)
I found a bug in the digester.
It happens when you use the rules written in xml
instead of writing them in the code (see code below).
The bug happens when you use call-param-rule / in
the xml file.
try
{
FileInputStream fis = new
FileInputStream(configFileName);
// the file config-rules.xml contains rules written
//in xml
URL url = getClass().getResource(config-rules.xml);
BatchContext config = (BatchContext)
DigesterLoader.load(url, getClass().getClassLoader(),
fis, this);
fis.close();
}
catch(DigesterLoadingException dle)
{
throw new BatchException(dle);
}
catch (SAXException ioe)
{
ioe.printStackTrace();
throw new BatchException(ioe);
}
catch (IOException ioe)
{
throw new BatchException(ioe);
}
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
public void addRuleInstances(Digester digester) {
final String ruleClassName = Rule.class.getName();
digester.register(DIGESTER_PUBLIC_ID, getDigesterRulesDTD());
digester.addRule(*/pattern, new PatternRule(digester, value));
digester.addRule(*/include, new IncludeRule(digester));
digester.addFactoryCreate(*/call-method-rule, new CallMethodRuleFactory());
digester.addRule(*/call-method-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/call-method-rule, add, ruleClassName);
//
//
// Modified by Philippe Mouawad
//
digester.addFactoryCreate(*/call-param-rule, new CallParamRuleFactory());
digester.addRule(*/call-param-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/call-param-rule, add, ruleClassName);
//
// End of modification
//
//
digester.addFactoryCreate(*/factory-create-rule, new
FactoryCreateRuleFactory());
digester.addRule(*/factory-create-rule, new PatternRule(digester,
pattern));
digester.addSetNext(*/factory-create-rule, add, ruleClassName);
digester.addFactoryCreate(*/object-create-rule, new
ObjectCreateRuleFactory());
digester.addRule(*/object-create-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/object-create-rule, add, ruleClassName);
digester.addFactoryCreate(*/set-properties-rule, new
SetPropertiesRuleFactory());
digester.addRule(*/set-properties-rule, new PatternRule(digester,
pattern));
digester.addSetNext(*/set-properties-rule, add, ruleClassName);
digester.addRule(*/set-properties-rule/alias, new
SetPropertiesAliasRule(digester));
digester.addFactoryCreate(*/set-property-rule, new SetPropertyRuleFactory());
digester.addRule(*/set-property-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-property-rule, add, ruleClassName);
digester.addFactoryCreate(*/set-top-rule, new SetTopRuleFactory());
digester.addRule(*/set-top-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-top-rule, add, ruleClassName);
digester.addFactoryCreate(*/set-next-rule, new SetNextRuleFactory());
digester.addRule(*/set-next-rule, new PatternRule(digester, pattern));
digester.addSetNext(*/set-next-rule, add, ruleClassName);
}
protected class CallParamRuleFactory extends AbstractObjectCreationFactory {
// Old code
//public Object createObject(Attributes attributes) {
//// create callmethodrule
//int paramNumber = Integer.parseInt(attributes.getValue(paramnumber));
//String methodName = attributes.getValue(attrname);
//Rule callMethodRule = new CallMethodRule(targetDigester, methodName,
//paramNumber);
//return callMethodRule;
//}
// End of old code
//
//
// Modified by Philippe Mouawad
//
//
// Modified by Philippe Mouawad
//
public Object createObject(Attributes attributes) {
// create callmethodrule
int paramNumber = Integer.parseInt(attributes.getValue(paramnumber));
String attrName = attributes.getValue(attrname);
Rule callParamRule = new CallParamRule(targetDigester, paramNumber,
attrName);
return callParamRule ;
}
//
// End of modification
//
//
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
