BUG 52048
Hello Sebb, Regarding 52048 bug, what is the solution or policy if we want to implement it ? I had integrated the patch and noted that it broke parsing of current test plan because we removed BSFSamplerGui.java Did you handle this case before ? if yes how ? we keep BSFSamplerGui and deprecate it ? there is some migration feature ? Thanks. Regards Philippe
BUG 52048
Hello Sebb, Is it OK for you if I commit the patch once I have updated upgrade.properties or you want to close issue as wontfix ? Thanks. Regarding Mirror, in fact I had this "bad ?" :-) idea when debugging Cookie issue a while ago , I noticed lot of threads were being launched and Eclipse Debugger went crazy so I had to kill Eclipse. In my understanding of Mirror, it is just used during writing phase, so number of thread is low. If you want to put high numbers then in current implementation, JMeter performance will go really down since Thread creation has a big cost, so putting a limit on this is better on this point. Another use of this modification is that you can simulate Server refusing requests by putting a low value to Threads. I don't really understand in which case you will use a mirror in Batch Mode so an example will help me. I can rollback it all if you think it's a bad idea. Regards Philipe
Re: BUG 52048
I saw this was handled by upgrade.properties Is there some documentation ? Thanks. On Thu, Jan 12, 2012 at 11:20 PM, Philippe Mouawad < philippe.moua...@gmail.com> wrote: > Hello Sebb, > Regarding 52048 bug, what is the solution or policy if we want to > implement it ? > > I had integrated the patch and noted that it broke parsing of current test > plan because we removed BSFSamplerGui.java > > Did you handle this case before ? if yes how ? > we keep BSFSamplerGui and deprecate it ? > there is some migration feature ? > > Thanks. > Regards > Philippe > > -- Cordialement. Philippe Mouawad.
Re: BUG 52048
On 12 January 2012 22:33, Philippe Mouawad wrote: > I saw this was handled by upgrade.properties Not sure it will work with change to using TestBean. Might need to update the XStream reader to do the conversion. Alternatively, perhaps it would be easier to modify the gui layout to match the test bean more closely? However, whatever approach is taken, I don't think it's worth spending a lot of time on. > Is there some documentation ? Only what is in the file itself. > Thanks. > > On Thu, Jan 12, 2012 at 11:20 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > >> Hello Sebb, >> Regarding 52048 bug, what is the solution or policy if we want to >> implement it ? >> >> I had integrated the patch and noted that it broke parsing of current test >> plan because we removed BSFSamplerGui.java >> >> Did you handle this case before ? if yes how ? >> we keep BSFSamplerGui and deprecate it ? >> there is some migration feature ? >> >> Thanks. >> Regards >> Philippe >> >> > > > -- > Cordialement. > Philippe Mouawad.
Re: BUG 52048
On 18 January 2012 20:37, Philippe Mouawad wrote: > Hello Sebb, > Is it OK for you if I commit the patch once I have updated > upgrade.properties or you want to close issue as wontfix ? If you can get it to work without breaking anything, then I have no objection. Documentation (screenshots and descriptions) also need to be updated. Seems like a lot of work for a minor visual improvement, but if you want to spend the time on it, go ahead. > Thanks. > > > Regarding Mirror, I will respond in a separate thread. (please use separate e-mails for separate topics)
Change to Mirror threading [was: BUG 52048]
On 18 January 2012 20:37, Philippe Mouawad wrote: > Regarding Mirror, in fact I had this "bad ?" :-) idea when debugging Cookie > issue a while ago , I noticed lot of threads were being launched and > Eclipse Debugger went crazy so I had to kill Eclipse. > > In my understanding of Mirror, it is just used during writing phase, so > number of thread is low. Not sure what you mean by "writing phase". I use it for debugging, e.g. seeing what is in a POST request. > If you want to put high numbers then in current implementation, JMeter > performance will go really down since Thread creation has a big cost, so > putting a limit on this is better on this point. Possibly. > Another use of this modification is that you can simulate Server refusing > requests by putting a low value to Threads. Yes, that could be useful. > I don't really understand in which case you will use a mirror in Batch Mode > so an example will help me. See above (POST). > I can rollback it all if you think it's a bad idea. As (I thought) I already wrote, I think it's a bad idea to change the default behaviour. Having an option to limit the threads and limit the queued requests would be useful. So I suggest making the default values 0, and only creating the thread pool and queue if the value is > 0. Again, the documentation needs to be updated to describe how to use the new settings. > Regards > Philipe
