Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAH9fUpa4fbH3-SHGTPbym=5KDtitMt0eTiUaxZqvxxpQLq-cVw@mail.gmail.com>
References: 
 <CAH9fUpafy=oB4F+P=3Se+jnCZAkmvk1JxaaP8z=kaLq4FarscA@mail.gmail.com>
	<54C3F8ED.3010106@internetallee.de>
	<CAOGo0VbeWmPmkjzCSVLvQEptxtNV8tipK+ZsuiTzbLFVa19DgA@mail.gmail.com>
	<CAH9fUpYxiLN59D4J+=5-tudia8D7MrZz+e10YHSAUc7X3C--NA@mail.gmail.com>
	<CAOGo0Va6GJdFW0uv5xVTvA4woVJ=BEYRFfRp77Pyq9iZdj-Fgg@mail.gmail.com>
	<CAH9fUpZA7Gvfn0BNmwquYGVJELJaJ0L4dgiKSbnuBD2cVb=3Bw@mail.gmail.com>
	<CAH9fUpa4fbH3-SHGTPbym=5KDtitMt0eTiUaxZqvxxpQLq-cVw@mail.gmail.com>
Date: Tue, 27 Jan 2015 21:47:56 +0000
Message-ID: 
 <CAOGo0Va_t8+ZZ_2pPybmbfWo855Uh0K86PD3aDWJY50gaTUmkw@mail.gmail.com>
Subject: Re: Release 2.13 ?
From: sebb <sebbaz@gmail.com>
To: dev@jmeter.apache.org
Content-Type: text/plain; charset=UTF-8

On 26 January 2015 at 12:25, Philippe Mouawad
<philippe.mouawad@gmail.com> wrote:
> Hi,
> I think I will delay performance optimization as I upgraded yesterday
> evening to HttpClient 4.4 and there are a lot of deprecations that need to
> be fixed before implementing this enhancement.
> @sebb, as I asked many times, I thought you had started the upgrade ? did
> you or did  I misunderstood ?

Yes, I made a start. I've created a branch - HC4 - with some changes,
but it is far from complete.

> Is there a migration guide from 4.2.X to 4.4.X ? Reading website I didn't
> see one, it only spoke about the examples to follow to use new API.

No, there does not seem to be a migration guide.

The deprecated classes have pointers to the replacements, but there
have been some fundamental changes that mean one cannot just rename
the classes.

I think we will basically have to rewrite HTTPHC4Impl using the examples.

There are one or two other classes - e.g. MeasuringConnectionManager -
that will also need rewriting.

I tried to start with the smaller classes, but the larger classes are
dependent on them, so I think one just has to start at the top and
work down.

This will clearly need to wait until a future release.

>
> Thanks
> Regards
>
>
> On Sun, Jan 25, 2015 at 8:07 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>>
>>
>> On Sunday, January 25, 2015, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 25 January 2015 at 14:30, Philippe Mouawad
>>> <philippe.mouawad@gmail.com> wrote:
>>> > On Sun, Jan 25, 2015 at 1:20 AM, sebb <sebbaz@gmail.com> wrote:
>>> >
>>> >> OK to name it 2.13 and to release it.
>>> >>
>>> >
>>> > Thanks
>>> >
>>> >>
>>> >> Given that there have been some issues with using RSyntaxTextArea, I
>>> >> wonder whether what it provides for the LoggerPanel is worth the
>>> >> potential disadvantages.
>>> >>
>>> >> I have just had a look at the display, and I'm not sure it provides
>>> >> much apart from line numbering..
>>> >>
>>> >> I can see that RSTA is beneficial for the GUI fields, but these are
>>> >> generally quite small, whereas the logging panel can grow without
>>> >> bound.
>>> >>
>>> >> At the moment the user has no choice as to whether to use it.
>>> >>
>>> >> Rather than release 2.13 and hope that the issues have been solved, I
>>> >> think it would be better to at least provide the option to disable
>>> >> RSTA for the LoggerPanel. This could be done with a property.
>>> >>
>>> >> We do not hope issues are solved , we have explanation of source of
>>> issues
>>> > and they are fixed now (1 (limit) by change in constructor, the second
>>> by
>>> > reverting to old way of adding events).
>>> > I made some tests enabling LoggerPanel and making logs huge, I didn't
>>> > notice memory leak, but other checks are welcome.
>>> > We are expecting a fix from RTSA but we can work without it.
>>> >  Adding a new property does not seem to me a good idea:
>>> > - Another new one (we have for something like 237 JMETER PROPERTIES),
>>>
>>> So what?
>>
>>
>> Makes it hard for newbies.
>> And less maintainable for us.
>> It is great that we handle backward compatibility but maybe at some
>> version we should remove properties that allowed to retain old behaviour.
>>
>>
>>
>>> > - adding a new one to propose a choice for customizing logger panel does
>>> > not seem suitable for me. If we are not satisfied with RTSA for this,
>>> then
>>> > let's just drop it.
>>>
>>> Fine by me if you want to drop it.
>>> However if it is kept, then I want there to be a way of disabling it
>>> if necessary which does not involve creating a new release.
>>>
>>> > By the way making some review and documenting properties would may be a
>>> > good idea to ensure they are all useful and still up to date. Shall I
>>> open
>>> > a bugzilla for this ?
>>>
>>> OK.
>>
>> Will do soon
>>
>>>
>>> >
>>> > At least then there would be a work round if RSTA proves problematic.
>>> >
>>> > As I said, in current nightly build, issue is fixed but other commiters
>>> > double checks are welcome to be sure.
>>>
>>> There's no guarantee that tests will find all the issues.
>>>
>>> Since it has caused problems in the past, and the log is unbounded in
>>> size, I think it is quite likely that this use of RSTA will be
>>> problematic.
>>
>>
>> yes but we bounded the number of lines to retain in logs.
>>
>>
>>> Even if it does not have a memory leak, it may well require more
>>> memory than a standard TextArea.
>>
>> But is it worth ? Shouldn't we quantify ?
>>
>>
>>>
>>> So it seems sensible to provide an opt-out that does not require
>>> re-releasing JMeter.
>>>
>>>
>>
>>> >
>>> >>
>>> >> On 24 January 2015 at 19:56, Felix Schumacher
>>> >> <felix.schumacher@internetallee.de> wrote:
>>> >> > Am 24.01.2015 um 16:30 schrieb Philippe Mouawad:
>>> >> >
>>> >> >> Hello,
>>> >> >> It appears 2.12 suffers from an OOM in GUI mode :
>>> >> >>
>>> >> >>     - https://issues.apache.org/bugzilla/show_bug.cgi?id=57440
>>> >> >>
>>> >> >> This OOM seems to be due to RSyntaxTexarea bug:
>>> >> >>
>>> >> >>     - https://github.com/bobbylight/RSyntaxTextArea/issues/99
>>> >> >>
>>> >> >> It appeared after the rework of LoggerPanel#processEvent way of
>>> >> appending
>>> >> >> event.
>>> >> >>
>>> >> >> Now that it receivs log event even when closed this OOM has more
>>> chances
>>> >> >> to
>>> >> >> appear.
>>> >> >>
>>> >> >> I reverted to 2.11 way of appending events to fix OOM waiting for
>>> answer
>>> >> >> from rsyntaxtarea project.
>>> >> >>
>>> >> >> There was also a bug in the way limit=0 was set that had no effect,
>>> I
>>> >> >> fixed
>>> >> >> it as part of the bug.
>>> >> >>
>>> >> >> There is a workaround which is to set:
>>> >> >>
>>> >> >> - jmeter.loggerpanel.enable_when_closed=false
>>> >> >>
>>> >> >> But if user opens panel, OOM will occur if lot of logs occur
>>> (specially
>>> >> if
>>> >> >> stacktraces).
>>> >> >>
>>> >> >> If we release, it cannot be named 2.12.1 because we have some "big?"
>>> >> >> features in this versions so it would not be a minor one.
>>> >> >>
>>> >> >> Regarding the frequency and impact of this bug, in our company I
>>> had 2
>>> >> >> reports in 5 days of this OOM so I think it is not to be ignored.
>>> >> >>
>>> >> >>
>>> >> >> Thoughts ?
>>> >> >>
>>> >> > +1 to release 2.13. I don't think a we should go for 2.x.y.
>>> >> >
>>> >> > Regards
>>> >> >  Felix
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.