You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2016/11/23 21:16:12 UTC
Ideas for 3.2
Hi all,
now that we released 3.1, it is time to think about the next release.
I think we should update the minimum version of java to 8 (as discussed
before).
We could then use the cache library (was it caffeine?) and use javafx
for html widgets (I would like to see them used for documentation and
template-selection, too).
Philippe has proposed to add a boundary based extractor, which I believe
could be massaged into the normal regex extractor together with a grok
to regex converter.
We discussed the memory usage of the results tree view, where we could
not agree on the implementation. I believe this could be combined with a
filter that sorts samples out, before they even get into the tree view.
That could be used to filter on thread ids or session id, or even (when
implemented as a queue) to emit only those samples, that were collected
shortly before an error (or other event).
Logging. We made the start to use slf4j. Should we change the remaining
classes too?
The documentation has still the pdf howtos, which could be converted to
html and looked through, if they still work.
Drop generated docs from the source tree.
Add source-jars to the maven artefacts.
What are your plans / vetoes? I am sure I missed quite a bit.
Regards,
Felix
Re: Ideas for 3.2
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 25.11.2016 um 08:35 schrieb Milamber:
>
>
> On 23/11/2016 21:16, Felix Schumacher wrote:
>> Hi all,
>>
>> now that we released 3.1, it is time to think about the next release.
>>
>> I think we should update the minimum version of java to 8 (as
>> discussed before).
>
> Agree too.
>
>>
>> We could then use the cache library (was it caffeine?) and use javafx
>> for html widgets (I would like to see them used for documentation and
>> template-selection, too).
>>
>> Philippe has proposed to add a boundary based extractor, which I
>> believe could be massaged into the normal regex extractor together
>> with a grok to regex converter.
>>
>> We discussed the memory usage of the results tree view, where we
>> could not agree on the implementation. I believe this could be
>> combined with a filter that sorts samples out, before they even get
>> into the tree view. That could be used to filter on thread ids or
>> session id, or even (when implemented as a queue) to emit only those
>> samples, that were collected shortly before an error (or other event).
>>
>> Logging. We made the start to use slf4j. Should we change the
>> remaining classes too?
>>
>> The documentation has still the pdf howtos, which could be converted
>> to html and looked through, if they still work.
>
> Yes. I can help to convert some pdf howtos.
Great. The conversion as such is not that big of a problem. I can do
that. The major thing would be to go through the tutorials and look if
they are still valid.
I will convert them to xml and after that everyone can shout out, when
they are working on one.
Regards,
Felix
>
>>
>> Drop generated docs from the source tree.
>>
>> Add source-jars to the maven artefacts.
>>
>> What are your plans / vetoes? I am sure I missed quite a bit.
>
>
> The HTTP/2 must be a priority imho.
> Parallel controller to help to make some specific test plans too.
>
> Milamber
>
>>
>> Regards,
>>
>> Felix
>>
>>
>>
>
Re: Ideas for 3.2
Posted by Milamber <mi...@apache.org>.
On 23/11/2016 21:16, Felix Schumacher wrote:
> Hi all,
>
> now that we released 3.1, it is time to think about the next release.
>
> I think we should update the minimum version of java to 8 (as
> discussed before).
Agree too.
>
> We could then use the cache library (was it caffeine?) and use javafx
> for html widgets (I would like to see them used for documentation and
> template-selection, too).
>
> Philippe has proposed to add a boundary based extractor, which I
> believe could be massaged into the normal regex extractor together
> with a grok to regex converter.
>
> We discussed the memory usage of the results tree view, where we could
> not agree on the implementation. I believe this could be combined with
> a filter that sorts samples out, before they even get into the tree
> view. That could be used to filter on thread ids or session id, or
> even (when implemented as a queue) to emit only those samples, that
> were collected shortly before an error (or other event).
>
> Logging. We made the start to use slf4j. Should we change the
> remaining classes too?
>
> The documentation has still the pdf howtos, which could be converted
> to html and looked through, if they still work.
Yes. I can help to convert some pdf howtos.
>
> Drop generated docs from the source tree.
>
> Add source-jars to the maven artefacts.
>
> What are your plans / vetoes? I am sure I missed quite a bit.
The HTTP/2 must be a priority imho.
Parallel controller to help to make some specific test plans too.
Milamber
>
> Regards,
>
> Felix
>
>
>
Re: Ideas for 3.2
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Great news :-)
2016-11-24 15:30 GMT+01:00 Vladimir Sitnikov <si...@gmail.com>:
> >I would like to have "timer that produces poisson arrivals" from Vladimir
> integreted to 3.2.
> >I will make more test in it
>
> I'm still preparing a talk. Hopefully it will succeed, then I'll have some
> time to push that timer further (update UI, etc, etc)
>
> Vladimir
>
Re: Ideas for 3.2
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I would like to have "timer that produces poisson arrivals" from Vladimir
integreted to 3.2.
>I will make more test in it
I'm still preparing a talk. Hopefully it will succeed, then I'll have some
time to push that timer further (update UI, etc, etc)
Vladimir
Re: Ideas for 3.2
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi,
2016-11-23 23:04 GMT+01:00 Philippe Mouawad <ph...@gmail.com>:
> Hi Felix,
> I am happy too see such enthusiasm !
>
Happy too :-)
>
>
> On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <felix.schumacher@
> internetallee.de> wrote:
>
> > Hi all,
> >
> > now that we released 3.1, it is time to think about the next release.
> >
> > I think we should update the minimum version of java to 8 (as discussed
> > before).
> >
> +1
>
+1
>
> >
> > We could then use the cache library (was it caffeine?)
>
>
> Yes
>
> > and use javafx for html widgets (I would like to see them used for
> > documentation and template-selection, too).
> >
> I will be commiting the patch for Browser.
>
> And +10 for your ideas
>
+10000
>
> >
> > Philippe has proposed to add a boundary based extractor, which I believe
> > could be massaged into the normal regex extractor together with a grok to
> > regex converter.
> >
>
> Yes , go for Grok
> But I think boundary may also be useful in addition to Regex. From what I
> saw (but maybe I missed something) , it does not seems as easy as that to
> use Grok, the boundary extractor is a not brainer, user just put what he
> bounds the data he wants to extract.
> Grok requires a minimum of documentation reading no ?
> Of course I may be wrong Felix, if I missed something please explain.
>
Boundary based extractor are the old way in Loadrunner to extract value
from response.
Why do you want to add it in JMeter?
>
>
> > We discussed the memory usage of the results tree view, where we could
> not
> > agree on the implementation. I believe this could be combined with a
> filter
> > that sorts samples out, before they even get into the tree view. That
> could
> > be used to filter on thread ids or session id, or even (when implemented
> as
> > a queue) to emit only those samples, that were collected shortly before
> an
> > error (or other event).
> >
>
> +1
>
> >
> > Logging. We made the start to use slf4j. Should we change the remaining
> > classes too?
> >
>
> AFAIK, HttpComponents directly migrates to LOG4J2. But I am ok for SLF4J.
> I believe we should not try to migrate existing functionnality of JMeter,
> just plug SLF4J and select log4j2 as implementation and use default
> configuration mechanism. I think we have a lot of other work related to
> CORE features of a load testing tool and should not spend too much energy
> on this part.
>
> We could ask on twitter if users use Logging configuration in JMeter.
>
>
> > The documentation has still the pdf howtos, which could be converted to
> > html and looked through, if they still work.
> >
> +1
>
+1
>
> >
> > Drop generated docs from the source tree.
> >
> No opinion
>
> >
> > Add source-jars to the maven artefacts.
> >
> +10, it has been requested.
>
> >
> > What are your plans / vetoes? I am sure I missed quite a bit.
> >
>
> I would add as TOP priority but more effort:
>
> - HTTP/2 : This one should be high priority, this one will soon be very
> popular and we should implement it.
> - MQTT : There is a PR for this one
>
+1 for adding MQTT
But I don't know if integrate the PR is a good idea because I would like to
integrate other messaging protocol (STOMP, AMPQ...)
I will study it asap
Please, wait for some days
> - Undo/Redo : I sent a mail on this one and a possible way to implement
> it
>
+1
> - Your idea: possible rework of core architecture to at least introduce
> a pool of threads or switch to async model allowing us to take
> advantage of
> async io
> - Websocket
> - Ajax solution : ParallelController ? or another idea an HTTP Sampler
> that could contains a children SubRequest and we would reuse partly
> what we
> have for download embedded resources
>
+1
>
>
> In a previous discussion we had a LOOOOONNNG discussion on DSL.
>
> This seems a bit complex. I am still not convinced that it is useful in all
> fields, but it is useful for:
>
> - easily coding (REST) Services Load Testing. With Microservices
> popularity, this is an argument I think
> - Ease source control comparison in this case. And more widely when
> comparing tests
>
> Couldn't we start simply by trying to replace XML by JSON as an
> output/input format ? XStream has an implementation for this.
>
> We wouldn't drop XML yet.
>
It will be interesting to have a target sample of JSON file to check if
it's easiest to read than XML
I would like to have "timer that produces poisson arrivals" from Vladimir
integreted to 3.2.
I will make more test in it
Regards
Antonio
>
>
>
> > Regards,
> >
> > Felix
> >
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
RE: Ideas for 3.2
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: Philippe Mouawad [mailto:philippe.mouawad@gmail.com]
> Sent: Sunday, November 27, 2016 7:54 AM
> To: dev@jmeter.apache.org
> Subject: Re: Ideas for 3.2
>
> On Sun, Nov 27, 2016 at 11:57 AM, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>>> Couldn't we start simply by trying to replace XML by JSON as an
>>> output/input format ? XStream has an implementation for this.
>>>
>> I JSON really that much more readable compared to XML?
>>
> JSON is more readable but the XStream one might not be, I can investigate
> this more
More readable? Eeeeeeh, sorta. It's certainly (a lot) lighter-weight to
parse and it's a decent bog-standard textual data format. But readability
(for humans) can become awfully spotty when you start nesting data
structures. If the XStream JSON output is as neurotic as the XML, it'll be
much, much worse.
Honestly, rather than simply abandoning XML, JMeter could do substantially
better just by using it as a proper format instead of a serialisation.
>>> We wouldn't drop XML yet.
>>>
>> We shouldn't.
>>
>I agree
Though it'll probably end up being painful to maintain, especially never
remove the ability to load it. Keeping backward compatible reading is much
more important than forward compatible export.
Regards,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Re: Ideas for 3.2
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sun, Nov 27, 2016 at 11:57 AM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Am 23.11.2016 um 23:04 schrieb Philippe Mouawad:
>
>> Hi Felix,
>> I am happy too see such enthusiasm !
>>
>>
>> On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <felix.schumacher@
>> internetallee.de> wrote:
>>
>> Hi all,
>>>
>>> now that we released 3.1, it is time to think about the next release.
>>>
>>> I think we should update the minimum version of java to 8 (as discussed
>>> before).
>>>
>>> +1
>>
> Done
>
Thanks
>
>
>> We could then use the cache library (was it caffeine?)
>>>
>>
>> Yes
>>
> Added a patch to the bugzilla entry.
>
I reviewed, +1 for commit
>
>
>> and use javafx for html widgets (I would like to see them used for
>>> documentation and template-selection, too).
>>>
>>> I will be commiting the patch for Browser.
>>
>
Done. Should we remove HTML and HTML+embedded resources renderer ?
I think we should.
>
>> And +10 for your ideas
>>
>> Philippe has proposed to add a boundary based extractor, which I believe
>>> could be massaged into the normal regex extractor together with a grok to
>>> regex converter.
>>>
>>> Yes , go for Grok
>> But I think boundary may also be useful in addition to Regex. From what I
>> saw (but maybe I missed something) , it does not seems as easy as that to
>> use Grok, the boundary extractor is a not brainer, user just put what he
>> bounds the data he wants to extract.
>> Grok requires a minimum of documentation reading no ?
>> Of course I may be wrong Felix, if I missed something please explain.
>>
> I think we should document both additions :) But you are right grok might
> need more than a boundary based one.
>
Using Regexp has the advantage that users will see this new feature, but
might complexify UI but maybe not. Could you share your UI or patch ?.
But no strong opinion on this.
>
> I have a minimal implementation to translate grok expressions to regex
> expressions that gives - as a bonus - a set of names that will be used for
> the extracted varnames. So if a user gives a grok string of
> "%{NUMBER:count} Person" it would be translated into a regex string
> "(-?\d*(?:\.\d+)) Person" and the matching group would be stored into the
> var named "count" (count_... if more then one should be found, like in
> regex mode).
>
> But I am still not sure about, wheter we should add a "mode"-switch to the
> regex extractor or add two new extractors.
>
>
>
>>
>> We discussed the memory usage of the results tree view, where we could not
>>> agree on the implementation. I believe this could be combined with a
>>> filter
>>> that sorts samples out, before they even get into the tree view. That
>>> could
>>> be used to filter on thread ids or session id, or even (when implemented
>>> as
>>> a queue) to emit only those samples, that were collected shortly before
>>> an
>>> error (or other event).
>>>
>>> +1
>>
>> Logging. We made the start to use slf4j. Should we change the remaining
>>> classes too?
>>>
>>> AFAIK, HttpComponents directly migrates to LOG4J2. But I am ok for SLF4J.
>> I believe we should not try to migrate existing functionnality of JMeter,
>> just plug SLF4J and select log4j2 as implementation and use default
>> configuration mechanism. I think we have a lot of other work related to
>> CORE features of a load testing tool and should not spend too much energy
>> on this part.
>>
>> We could ask on twitter if users use Logging configuration in JMeter.
>>
> Well, we added SLF4J as the backend for Excalibur logging and I know I
> refused to include patches, that switched from Excalibur logging to SLF4J
> API in the past. My question really was about which api we use in the
> JMeter code base.
>
> 1. stay with Excalibur (routed to SLF4J)
> 2. switch to SLF4j
> 3. switch to whatever is hip today
>
I would tend to switch to SLF4J and drop excalibur, we can potentially name
next version 4.0 to break more compatibility things, although I am
convinced we don't loose much by dropping current logging configuration.
>
>
>>
>> The documentation has still the pdf howtos, which could be converted to
>>> html and looked through, if they still work.
>>>
>>> +1
>>
>> Drop generated docs from the source tree.
>>>
>>> No opinion
>>
>> Add source-jars to the maven artefacts.
>>>
>>> +10, it has been requested.
>>
>> What are your plans / vetoes? I am sure I missed quite a bit.
>>>
>>> I would add as TOP priority but more effort:
>>
>> - HTTP/2 : This one should be high priority, this one will soon be
>> very
>> popular and we should implement it.
>>
> I thought we were waiting for commons to support it. But otherwise +1
>
>> - MQTT : There is a PR for this one
>>
> +-0 It would be another plugin to support and it could really live on its
> own.
>
>> - Undo/Redo : I sent a mail on this one and a possible way to
>> implement
>> it
>>
> It would be nice to have it working, but it seems like an awful lot to do,
> to get it working.
>
>> - Your idea: possible rework of core architecture to at least
>> introduce
>> a pool of threads or switch to async model allowing us to take
>> advantage of
>> async io
>>
> I still think we should experiment in that direction, but it seems to be a
> really big step and shouldn't be done in a hurry.
>
>> - Websocket
>>
> There seems to be an external plugin already.
>
>> - Ajax solution : ParallelController ? or another idea an HTTP Sampler
>> that could contains a children SubRequest and we would reuse partly
>> what we
>> have for download embedded resources
>>
>>
>> In a previous discussion we had a LOOOOONNNG discussion on DSL.
>>
> The demo looked really intriguing, but I have no knowledge in that
> direction to help out.
>
>>
>> This seems a bit complex. I am still not convinced that it is useful in
>> all
>> fields, but it is useful for:
>>
>> - easily coding (REST) Services Load Testing. With Microservices
>> popularity, this is an argument I think
>> - Ease source control comparison in this case. And more widely when
>> comparing tests
>>
>> Couldn't we start simply by trying to replace XML by JSON as an
>> output/input format ? XStream has an implementation for this.
>>
> I JSON really that much more readable compared to XML?
>
JSON is more readable but the XStream one might not be, I can investigate
this more
>
>> We wouldn't drop XML yet.
>>
> We shouldn't.
>
I agree
>
> Regards,
> Felix
>
>>
>>
>>
>> Regards,
>>>
>>> Felix
>>>
>>>
>>>
>>>
>>
>
--
Cordialement.
Philippe Mouawad.
RE: Ideas for 3.2
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: Felix Schumacher [mailto:felix.schumacher@internetallee.de]
> Sent: Sunday, November 27, 2016 5:58 AM
> To: dev@jmeter.apache.org
> Subject: Re: Ideas for 3.2
>
> Am 23.11.2016 um 23:04 schrieb Philippe Mouawad:
>> - Undo/Redo : I sent a mail on this one and a possible way to
>> implement it
>
> It would be nice to have it working, but it seems like an awful lot to do,
> to get it working.
I'd suggest waiting until you have a better idea of how the internals will
look after refactoring. That'll inform the undo API and might even make
things easier if you play it right.
>> - Your idea: possible rework of core architecture to at least
>> introduce a pool of threads or switch to async model allowing us to
>> take advantage of async io
>
> I still think we should experiment in that direction, but it seems to be a
> really big step and shouldn't be done in a hurry.
IMHO, the first step of any major internals work is divorcing the test plan
export format from the straight serialisation of the ListedHashTree.
>> In a previous discussion we had a LOOOOONNNG discussion on DSL.
>
> The demo looked really intriguing, but I have no knowledge in that
> direction to help out.
Since we're (finally!) nearing the end of this product cycle, I may be able
to argue in favour of allocating some of my time to assist with this. I do
think this is something that's worth committing to.
Regards,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Re: Ideas for 3.2
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 23.11.2016 um 23:04 schrieb Philippe Mouawad:
> Hi Felix,
> I am happy too see such enthusiasm !
>
>
> On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <felix.schumacher@
> internetallee.de> wrote:
>
>> Hi all,
>>
>> now that we released 3.1, it is time to think about the next release.
>>
>> I think we should update the minimum version of java to 8 (as discussed
>> before).
>>
> +1
Done
>
>> We could then use the cache library (was it caffeine?)
>
> Yes
Added a patch to the bugzilla entry.
>
>> and use javafx for html widgets (I would like to see them used for
>> documentation and template-selection, too).
>>
> I will be commiting the patch for Browser.
>
> And +10 for your ideas
>
>> Philippe has proposed to add a boundary based extractor, which I believe
>> could be massaged into the normal regex extractor together with a grok to
>> regex converter.
>>
> Yes , go for Grok
> But I think boundary may also be useful in addition to Regex. From what I
> saw (but maybe I missed something) , it does not seems as easy as that to
> use Grok, the boundary extractor is a not brainer, user just put what he
> bounds the data he wants to extract.
> Grok requires a minimum of documentation reading no ?
> Of course I may be wrong Felix, if I missed something please explain.
I think we should document both additions :) But you are right grok
might need more than a boundary based one.
I have a minimal implementation to translate grok expressions to regex
expressions that gives - as a bonus - a set of names that will be used
for the extracted varnames. So if a user gives a grok string of
"%{NUMBER:count} Person" it would be translated into a regex string
"(-?\d*(?:\.\d+)) Person" and the matching group would be stored into
the var named "count" (count_... if more then one should be found, like
in regex mode).
But I am still not sure about, wheter we should add a "mode"-switch to
the regex extractor or add two new extractors.
>
>
>> We discussed the memory usage of the results tree view, where we could not
>> agree on the implementation. I believe this could be combined with a filter
>> that sorts samples out, before they even get into the tree view. That could
>> be used to filter on thread ids or session id, or even (when implemented as
>> a queue) to emit only those samples, that were collected shortly before an
>> error (or other event).
>>
> +1
>
>> Logging. We made the start to use slf4j. Should we change the remaining
>> classes too?
>>
> AFAIK, HttpComponents directly migrates to LOG4J2. But I am ok for SLF4J.
> I believe we should not try to migrate existing functionnality of JMeter,
> just plug SLF4J and select log4j2 as implementation and use default
> configuration mechanism. I think we have a lot of other work related to
> CORE features of a load testing tool and should not spend too much energy
> on this part.
>
> We could ask on twitter if users use Logging configuration in JMeter.
Well, we added SLF4J as the backend for Excalibur logging and I know I
refused to include patches, that switched from Excalibur logging to
SLF4J API in the past. My question really was about which api we use in
the JMeter code base.
1. stay with Excalibur (routed to SLF4J)
2. switch to SLF4j
3. switch to whatever is hip today
>
>
>> The documentation has still the pdf howtos, which could be converted to
>> html and looked through, if they still work.
>>
> +1
>
>> Drop generated docs from the source tree.
>>
> No opinion
>
>> Add source-jars to the maven artefacts.
>>
> +10, it has been requested.
>
>> What are your plans / vetoes? I am sure I missed quite a bit.
>>
> I would add as TOP priority but more effort:
>
> - HTTP/2 : This one should be high priority, this one will soon be very
> popular and we should implement it.
I thought we were waiting for commons to support it. But otherwise +1
> - MQTT : There is a PR for this one
+-0 It would be another plugin to support and it could really live on
its own.
> - Undo/Redo : I sent a mail on this one and a possible way to implement
> it
It would be nice to have it working, but it seems like an awful lot to
do, to get it working.
> - Your idea: possible rework of core architecture to at least introduce
> a pool of threads or switch to async model allowing us to take advantage of
> async io
I still think we should experiment in that direction, but it seems to be
a really big step and shouldn't be done in a hurry.
> - Websocket
There seems to be an external plugin already.
> - Ajax solution : ParallelController ? or another idea an HTTP Sampler
> that could contains a children SubRequest and we would reuse partly what we
> have for download embedded resources
>
>
> In a previous discussion we had a LOOOOONNNG discussion on DSL.
The demo looked really intriguing, but I have no knowledge in that
direction to help out.
>
> This seems a bit complex. I am still not convinced that it is useful in all
> fields, but it is useful for:
>
> - easily coding (REST) Services Load Testing. With Microservices
> popularity, this is an argument I think
> - Ease source control comparison in this case. And more widely when
> comparing tests
>
> Couldn't we start simply by trying to replace XML by JSON as an
> output/input format ? XStream has an implementation for this.
I JSON really that much more readable compared to XML?
>
> We wouldn't drop XML yet.
We shouldn't.
Regards,
Felix
>
>
>
>> Regards,
>>
>> Felix
>>
>>
>>
>
Re: Ideas for 3.2
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Felix,
I am happy too see such enthusiasm !
On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <felix.schumacher@
internetallee.de> wrote:
> Hi all,
>
> now that we released 3.1, it is time to think about the next release.
>
> I think we should update the minimum version of java to 8 (as discussed
> before).
>
+1
>
> We could then use the cache library (was it caffeine?)
Yes
> and use javafx for html widgets (I would like to see them used for
> documentation and template-selection, too).
>
I will be commiting the patch for Browser.
And +10 for your ideas
>
> Philippe has proposed to add a boundary based extractor, which I believe
> could be massaged into the normal regex extractor together with a grok to
> regex converter.
>
Yes , go for Grok
But I think boundary may also be useful in addition to Regex. From what I
saw (but maybe I missed something) , it does not seems as easy as that to
use Grok, the boundary extractor is a not brainer, user just put what he
bounds the data he wants to extract.
Grok requires a minimum of documentation reading no ?
Of course I may be wrong Felix, if I missed something please explain.
> We discussed the memory usage of the results tree view, where we could not
> agree on the implementation. I believe this could be combined with a filter
> that sorts samples out, before they even get into the tree view. That could
> be used to filter on thread ids or session id, or even (when implemented as
> a queue) to emit only those samples, that were collected shortly before an
> error (or other event).
>
+1
>
> Logging. We made the start to use slf4j. Should we change the remaining
> classes too?
>
AFAIK, HttpComponents directly migrates to LOG4J2. But I am ok for SLF4J.
I believe we should not try to migrate existing functionnality of JMeter,
just plug SLF4J and select log4j2 as implementation and use default
configuration mechanism. I think we have a lot of other work related to
CORE features of a load testing tool and should not spend too much energy
on this part.
We could ask on twitter if users use Logging configuration in JMeter.
> The documentation has still the pdf howtos, which could be converted to
> html and looked through, if they still work.
>
+1
>
> Drop generated docs from the source tree.
>
No opinion
>
> Add source-jars to the maven artefacts.
>
+10, it has been requested.
>
> What are your plans / vetoes? I am sure I missed quite a bit.
>
I would add as TOP priority but more effort:
- HTTP/2 : This one should be high priority, this one will soon be very
popular and we should implement it.
- MQTT : There is a PR for this one
- Undo/Redo : I sent a mail on this one and a possible way to implement
it
- Your idea: possible rework of core architecture to at least introduce
a pool of threads or switch to async model allowing us to take advantage of
async io
- Websocket
- Ajax solution : ParallelController ? or another idea an HTTP Sampler
that could contains a children SubRequest and we would reuse partly what we
have for download embedded resources
In a previous discussion we had a LOOOOONNNG discussion on DSL.
This seems a bit complex. I am still not convinced that it is useful in all
fields, but it is useful for:
- easily coding (REST) Services Load Testing. With Microservices
popularity, this is an argument I think
- Ease source control comparison in this case. And more widely when
comparing tests
Couldn't we start simply by trying to replace XML by JSON as an
output/input format ? XStream has an implementation for this.
We wouldn't drop XML yet.
> Regards,
>
> Felix
>
>
>
--
Cordialement.
Philippe Mouawad.