Hi, 2016-11-23 23:04 GMT+01:00 Philippe Mouawad <philippe.moua...@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. >
