Thanks Oleg for your answer. Regarding JMeter, having to wait for Java 9 may not be feasible as we'll be just upgrading to Java 8 in next release but I think we'll have to support Java8 for at least 1 year or 2. Java9 will also most probably require some important work due to modules and adoption (not only for JMeter) may take some time.
Regards On Thu, Jan 26, 2017 at 4:15 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Thu, 2017-01-26 at 14:32 +0100, Philippe Mouawad wrote: > > Hello , > > Oleg kindly proposed to help JMeter project in adding HTTP/2 support. > > > > We have started this thread to work on design. > > > > As per Andrei remark, it seems ALPN is not yet supported by current > > HTTPClient 5.x version. > > Is there some visibility on its support ? > > > > > ALPN will be supported as soon as it is supported by the Java platform > (which is not going to happen until Java 9). > > ALPN can be used to advertise server protocol capabilities at the time > of SSL handshake and allow clients to pick the desired protocol from > the list of supported protocols. If one knows supported protocols > beforehand ALPN is completely useless. Clients can go straight to using > HTTP/2 if the server is known to support it. > > In the next release of HttpCore I would like to add protocol detection > logic to enable endpoints to detect HTTP protocol version by examining > the first packet received from the opposite endpoint. This in my > opinion would be a much more practical feature. ALPN presently is very > low on my priority list. > > Having said that ALPN support contribution would be welcome if someone > is willing to develop it. > > Oleg > > > > > Thanks for your help. > > Regards > > > > On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko <a...@ya.ru> wrote: > > > > > Hi, > > > > > > From my experiments, I see that lack of two specific features make > > > it > > > not useful. According to https://hc.apache.org/news.html: > > > > > > * No ALPN support yet > > > * no connection upgrade > > > > > > Especially ALPN part is crucial for protocol functioning. Is there > > > any > > > ETA from Oleg when it will become available? > > > > > > > > > In general, we can start designing the "synchronous way" solution. > > > From > > > my understanding, it is doable and will be good enough for the > > > beginning. > > > > > > > > > Andrey Pokhilko > > > > > > On 25.01.2017 23:38, Philippe Mouawad wrote: > > > > Hello > > > > I'd like to start a thread on this particular item for which an > > > > > > enhancement > > > > exists: > > > > > > > > - https://bz.apache.org/bugzilla/show_bug.cgi?id=59847 > > > > > > > > The aim of this thread is to discuss, throw ideas on how we could > > > > > > implement > > > > this in JMeter. > > > > > > > > Oleg K. from HttpComponents project has nicely proposed to help > > > > on it. > > > > > > > > I see at least 2 parts in this item: > > > > > > > > - The Sampler > > > > - The Recorder > > > > > > > > > > > > > > > > *Sampler:* > > > > We have 2 options: > > > > > > > > - build a usual "synchronous" sampler similar to HTTP: > > > > - Is this realistic ? > > > > - Does it perform well ? > > > > - + : It should not be too complex > > > > - build a new "Asynchronous sampler": > > > > - Is this realistic ? > > > > - + We could gain more performance > > > > - - It is a huge piece of work as we need to change JMeter > > > > model > > > > > > > > *Recorder:* > > > > > > > > I think we need to introduce a new more generic Recorder as the > > > > current > > > > Test Script Recorder is too tightly linked to HTTP 1.X protocol > > > > > > > > > > > > Regards > > > > Philippe M. > > > > @philmdot > > > > > > > > > > > > > > > -- Cordialement. Philippe Mouawad.
