jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Ideas for 3.2
Date Wed, 23 Nov 2016 22:04:13 GMT
Hi Felix,
I am happy too see such enthusiasm !

On Wed, Nov 23, 2016 at 10:16 PM, Felix Schumacher <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).

> 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).
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).


> 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.

> 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
   - 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

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message