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
