Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC
+1
בתאריך 2011 11 13 18:16, מאת "Rahul Akolkar" :
> cc+= {private, dev} for maximum coverage.
>
> +1 from me.
>
> -Rahul
>
> On Thu, Nov 10, 2011 at 1:01 PM, Henri Yandell wrote:
> > A joint vote to retire Jakarta into the Attic and to ask the board to
> > close down the PMC.
> >
> > [ ] +1
> > [ ] -1, because
> >
> > Hen
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: dev-h...@jakarta.apache.org
>
>
Re: transaction controller issue
Hi Franco, Why a Test Action sampler solves the problem? Anyway - for me it works even if the first evaluation is false (no exceptions appear on the log). Regards, Shmuel Krakower. On Thu, Nov 3, 2011 at 5:12 PM, Franco Sabadini wrote: > Be careful Shmuel, because 2.5.1 doesn't fix the whole issue, if the first > evaluation of the IF controller evaluates as false then the issue appears, > the best fix so far is to add a Test Action sampler at the same level as > the transaction controller inside the IF with a delay of 0 ms, that's what > I did. > > Hope that helps. > > > Franco > > > > On Wed, Nov 2, 2011 at 7:56 AM, Shmuel Krakower > wrote: > > > That's great, I was fighting the same problem all morning and was about > to > > post the same question after google wasn't helping. > > JMeter 2.5.1 solved my problem. > > > > > > Shmuel Krakower. > > > > > > On Tue, Nov 1, 2011 at 3:31 PM, Franco Sabadini > wrote: > > > > > Hi, > > > > > > yes that's what I found, I read the bug report yesterday, but is it > > > completelly fixed on JMeter 2.5.1? Or if the first evaluation of the IF > > is > > > false it'll still fail? > > > > > > Thanks. > > > > > > > > > Franco > > > > > > > > > > > > > > > On Mon, Oct 31, 2011 at 6:21 PM, Philippe Mouawad < > > > philippe.moua...@gmail.com> wrote: > > > > > > > Hello, > > > > You may be facing an issue fixed in 2.5.1. > > > > See http://jakarta.apache.org/jmeter/changes.html > > > > If Controller - Catches a StackOverflowError when a condition returns > > > > always false (after at least one iteration with return true) See bug > > > 50618 > > > > > > > > Regards > > > > Philippe > > > > > > > > On Mon, Oct 31, 2011 at 7:38 PM, Franco Sabadini > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm having an issue on JMeter 2.5, when running a test with a > > > transaction > > > > > controller inside an IF controller I get the following error (only > > > > > sometimes): > > > > > > > > > > 2011/10/28 13:36:47 ERROR - jmeter.threads.JMeterThread: Test > failed! > > > > > java.lang.StackOverflowError > > > > >at java.lang.String.indexOf(String.java:1521) > > > > >at java.lang.ClassLoader.checkName(ClassLoader.java:775) > > > > >at > java.lang.ClassLoader.findLoadedClass(ClassLoader.java:947) > > > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:291) > > > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > > > > >at > > > > > > > > > > > > > > > org.mozilla.javascript.DefiningClassLoader.loadClass(DefiningClassLoader.java:72) > > > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > > > > >at java.lang.Class.getDeclaredConstructors0(Native Method) > > > > >at > > > java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > > > > >at java.lang.Class.getConstructor0(Class.java:2699) > > > > >at java.lang.Class.newInstance0(Class.java:326) > > > > >at java.lang.Class.newInstance(Class.java:308) > > > > >at > > > > > > > > > > > > > > > org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:83) > > > > >at > > org.mozilla.javascript.Context.compileImpl(Context.java:2280) > > > > >at > > > org.mozilla.javascript.Context.compileString(Context.java:1284) > > > > >at > > > org.mozilla.javascript.Context.compileString(Context.java:1273) > > > > >at > > > > org.mozilla.javascript.Context.evaluateString(Context.java:1129) > > > > >at > > > > > > > > > > > > > > > org.apache.jmeter.control.IfController.evaluateCondition(IfController.java:110) > > > > >at > > > > > org.apache.jmeter.control.IfController.next(IfController.java:167) > > > > >at > > > > > > > > > > > > > > > org
Re: transaction controller issue
That's great, I was fighting the same problem all morning and was about to post the same question after google wasn't helping. JMeter 2.5.1 solved my problem. Shmuel Krakower. On Tue, Nov 1, 2011 at 3:31 PM, Franco Sabadini wrote: > Hi, > > yes that's what I found, I read the bug report yesterday, but is it > completelly fixed on JMeter 2.5.1? Or if the first evaluation of the IF is > false it'll still fail? > > Thanks. > > > Franco > > > > > On Mon, Oct 31, 2011 at 6:21 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > > > Hello, > > You may be facing an issue fixed in 2.5.1. > > See http://jakarta.apache.org/jmeter/changes.html > > If Controller - Catches a StackOverflowError when a condition returns > > always false (after at least one iteration with return true) See bug > 50618 > > > > Regards > > Philippe > > > > On Mon, Oct 31, 2011 at 7:38 PM, Franco Sabadini > > wrote: > > > > > Hi, > > > > > > I'm having an issue on JMeter 2.5, when running a test with a > transaction > > > controller inside an IF controller I get the following error (only > > > sometimes): > > > > > > 2011/10/28 13:36:47 ERROR - jmeter.threads.JMeterThread: Test failed! > > > java.lang.StackOverflowError > > >at java.lang.String.indexOf(String.java:1521) > > >at java.lang.ClassLoader.checkName(ClassLoader.java:775) > > >at java.lang.ClassLoader.findLoadedClass(ClassLoader.java:947) > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:291) > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > > >at > > > > > > org.mozilla.javascript.DefiningClassLoader.loadClass(DefiningClassLoader.java:72) > > >at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > > >at java.lang.Class.getDeclaredConstructors0(Native Method) > > >at > java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > > >at java.lang.Class.getConstructor0(Class.java:2699) > > >at java.lang.Class.newInstance0(Class.java:326) > > >at java.lang.Class.newInstance(Class.java:308) > > >at > > > > > > org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:83) > > >at org.mozilla.javascript.Context.compileImpl(Context.java:2280) > > >at > org.mozilla.javascript.Context.compileString(Context.java:1284) > > >at > org.mozilla.javascript.Context.compileString(Context.java:1273) > > >at > > org.mozilla.javascript.Context.evaluateString(Context.java:1129) > > >at > > > > > > org.apache.jmeter.control.IfController.evaluateCondition(IfController.java:110) > > >at > > > org.apache.jmeter.control.IfController.next(IfController.java:167) > > >at > > > > > > org.apache.jmeter.control.GenericController.nextIsAController(GenericController.java:187) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:229) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >at > > > > > > org.apache.jmeter.control.GenericController.reInitializeSubController(GenericController.java:230) > > >.. > > > > > > > > > > > > Did anyone else see this? > > > > > > Thanks. > > > > > > > > > Franco > > > > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > > >
Re: [VOTE] Apache JMeter TLP
+1 בתאריך 2011 10 13 20:04, מאת "Rahul Akolkar" : > [This vote is being held on dev@jakarta, please reply there. This > message is being sent to multiple lists to make sure most at Jakarta > are informed.] > > This is a vote for proposing an Apache JMeter TLP resolution to the > board, with sebb nominated as the first Chair. The full text appears > below [1] and is also on the wiki [2]. Vote will remain open for > atleast 72 hours. > > 8< > [ ] +1, its time for an Apache JMeter TLP > [ ] +/- 0 > [ ] -1, because ... > 8< > > Cheers, > -Rahul > > [1] Establish the Apache JMeter Project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project Management > Committee charged with the creation and maintenance of > open-source software related to a Java desktop > application designed to load test functional behavior and > measure performance, for distribution at no charge to the > public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache JMeter Project", > be and hereby is established pursuant to Bylaws of the > Foundation; and be it further > > RESOLVED, that the Apache JMeter Project be and hereby is > responsible for the creation and maintenance of software > that provides a Java desktop application designed to load > test functional behavior and measure performance; and be it > further > > RESOLVED, that the office of "Vice President, Apache JMeter" be > and hereby is created, the person holding such office to > serve at the direction of the Board of Directors as the chair > of the Apache JMeter Project, and to have primary responsibility > for management of the projects within the scope of > responsibility of the Apache JMeter Project; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache JMeter Project: > > * Sebastian Bazley (sebb AT a.o) > * Milamber (milamber AT a.o) > * Peter Lin (woolfel AT a.o) > * Henri Yandell (bayard AT a.o) > * Rahul Akolkar (rahul AT a.o) > * Oleg Kalnichevski (olegk AT a.o) > * Rainer Jung (rjung AT a.o) > * Philippe Mouawad (pmouawad AT a.o) > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sebastian Bazley > be appointed to the office of Vice President, Apache JMeter, to > serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until > death, resignation, retirement, removal or disqualification, > or until a successor is appointed; and be it further > > RESOLVED, that the initial Apache JMeter PMC be and hereby is > tasked with the creation of a set of bylaws intended to > encourage open development and increased participation in the > Apache JMeter Project; and be it further > > RESOLVED, that the Apache JMeter Project be and hereby > is tasked with the migration and rationalization of the Apache > Jakarta JMeter sub-project; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Jakarta JMeter sub-project encumbered upon the Apache Jakarta > Project are hereafter discharged. > > > [2] http://wiki.apache.org/jakarta/TLPJMeter (version 7 of wiki page) > > - > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > >
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
Hi, Why isn't Cookie manager implemented the way Cache manager is (using a thread local hash map)? If it would be implemented the same way - the fix should be the same as on the Cache manager case ( https://issues.apache.org/bugzilla/show_bug.cgi?id=51752) Regards, Shmuel Krakower. On Mon, Oct 3, 2011 at 5:02 PM, sebb wrote: > On 3 October 2011 15:39, Philippe Mouawad > wrote: > > On Mon, Oct 3, 2011 at 4:31 PM, sebb wrote: > > > >> On 3 October 2011 14:04, Philippe Mouawad > >> wrote: > >> > You are right, > >> > Patch was just about quick fix before the more impacting fix. > >> > > >> > Here are my propositions regarding this more impacting fix: > >> > > >> > - Add an option to make conc download use or not cookie, default > value > >> > will be false. > >> > - In AsyncSampler make a Clone with current cookies of Parent > >> > CookieManager (the one that is calling Executor) and store it in > >> ThreadLocal > >> > - Change HttpSamplerBase#getCookieManager to retrieve first in > Thread > >> > Local then in instance > >> > - If option is true, when reading res in Future > loop, > >> > reinject cookies inside ParentCookie otherwise ignore them > >> > >> As I wrote earlier, I'm not sure it ever makes sense to handle cookies > >> from embedded resources, so it would be simpler just to ignore them. > >> > >> I am not sure Frame couldn't be concerned by this case, so in my opinion > it > > should be a parameter not ignored by default. > > I'd overlooked frame. > > > > >> I'm looking at passing the current sampler to the AsyncSampler class, > >> which can then clone it. > >> I think that will create an independent set of cookies, so there can > >> be no need to protect against concurrent updates. > >> > > Agree, that's how I imagined it, but then you agree you have to store > > CookieManager in thread local ? > > If cookies are being ignored, then the cookie manager property can > just be cleared - i.e. there is no cookie manager. > > Alternatively, it will also need to be cloned. > > >> > >> We then need to consider if non-concurrent downloads should still be > >> processed for cookies. > >> > >> > > Conc and serial should have the same behaviour > > > > > PS : Does it mean that you are working on issue and will fix it on your > side > > Not yet decided; we need to agree on the approach first. > > > > >> > >> > Regards > >> > Philippe > >> > > >> > On Mon, Oct 3, 2011 at 2:29 PM, sebb wrote: > >> > > >> >> On 3 October 2011 13:14, Philippe Mouawad < > philippe.moua...@gmail.com> > >> >> wrote: > >> >> > Sebb, > >> >> > Do you want me to provide a patch with ConcurrentHashMap where I > will > >> >> have > >> >> > to handle null keys and values (not same behaviour as HashMap) or > we > >> >> forget > >> >> > about this approach ? > >> >> > >> >> I don't think we have yet decided how best to handle concurrent > >> downloads. > >> >> > >> >> e.g. should they even be setting cookies? > >> >> > >> >> > Regards > >> >> > Philippe > >> >> > > >> >> > On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad < > >> >> philippe.moua...@gmail.com > >> >> >> wrote: > >> >> > > >> >> >> 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 > >> >> >> > >> >> >>
Re: [JMeter] release 2.5.1 to fix issues in 2.5?
Hi, I think that there is a point to release JMeter 2.5.1, due to the HC4 connection leakage. I am also waiting for a couple of bug fixes already made on it. Thanks, Shmuel. On Wed, Sep 14, 2011 at 12:47 PM, sebb 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 > >
