[hpack] HpackException$SessionException when encoding client PUT request #9168
Comments
|
Jetty 9.x is now at End of Community Support. Please try Jetty 10/11. |
You have a classpath mistake, likely not including the right jars. |
|
@sbordet many thanks for the quick responses.
I wanted to try that already, but since the OpenHab core developers have not yet adopted Jetty 10, I am constrained to remain on 9.4.x for the time being. Sorry for that..
Ah-Ha, but could you kindly be more explicit? And I have the following JARs loaded.. |
|
Similar error reported at Issue #7964 (also on Jetty 9.x) |
|
Opened openhab/openhab-core#3315 |
|
@andrewfg Jetty loads The implementation for HTTP/1.1 is provided in The stack trace shows that you are using HTTP/2, so the HTTP/2 In the manifest for So I think we do the right incantation for OSGi to work. I don't think this is a Jetty issue, so the ball is in your court now. |
@sbordet many thanks. I am not an expert on OSGI module loading, so I rely on the OpenHab core system maintainers to provide the necessary infrastructure to my case. Therefore I wonder if, from your experience, you can give me any tips about what specifically I should ask those guys to do, to ensure that the hpack module gets loaded? |
|
@andrewfg there could be many reasons, from wrong usage of the thread context ClassLoader, to re-packaging of Jetty jars gone wrong, etc. |
|
@sbordet I am so sorry to be a PITA but I am still confused; the OH system runs on Karaf where the
|
|
Reminder, Jetty 9.x is at End of Community Support. Once OpenHAB has upgraded to Jetty 10, and if you have the same problem, we can continue to support you. |
|
@sbordet I do really appreciate you taking the extra time to help me out :) .. and I do also understand @joakime 's insistence on keeping good order .. so I thank you all the more :)
@sbordet yes I think that is indeed the case: I tried putting an SPI manifest file (below) in my addon JAR, and I can confirm that if I call PS and in that case, I am not so sure if migrating from 9.4.x to 10.x or 11.x would actually solve the issue.. (??) manifest file: org.eclipse.jetty.http.HttpFieldPreEncoder |
|
@andrewfg so if that is the case, then it's not Jetty. You have to configure whatever OSGi container you're running on -- this is outside the scope of Jetty, sorry. Try to figure out who's the first to trigger the load via the |
Ummm..
.. maybe Jetty is the culprit after all? Background: the OpenHAB core has built in dependencies on Jetty HTTP/1.0 Jars which are loaded when the OH core starts up. And once the core is running, it starts to Osgi load various third party addons ('bindings') such as mine. And my binding declares dependencies on Jetty HTTP/2.0 Jars, which are are probably therefore loaded last of all. So I think the ServiceLoader call is made -- dare I say it, by Jetty HTTP/1.0 (code below) -- well before the HTTP/2.0 Jars will have been loaded. Or something like that..
|
|
You are using Jetty 9.x, which is at End of Community Support. That's standard That same code in Jetty 10 looks like this ... Which uses the new Other OSGi users of Jetty 9+ (both Eclipse Equinox and Apache Felix) successfully use HTTP/2 without the issues you are experiencing. You need to figure this out, as |
|
@joakime many thanks for your response. The code that you quote in 10.x also has a class static method that loads a class static final field using a ServiceLoader. So in other words, even if I would be using 10.x, I would still have an issue if the application loads the HTTP/2.0 Jars at some time after it has already loaded the HTTP/1.0 jars and thus instatiated that classes static final field. This looks very much to me like a bug on your side. You should probably not have static final fields being initialised by class static methods, but rather should do the initialization when the class is actually instantiated. |
Except it's not. What remains is something peculiar to your configuration, not to Jetty. |
|
Doesn't matter. JPMS and OSGi have the same rules. This is not unique to Jetty. Your problem isn't even unique to ServiceLoader, this kind of late introduction of dependencies would cause issues and bugs to countless other Pool and/or Cache implementations and usages as well. |
|
^ I may try to hack a solution using reflection, but I don't know if reflection allows accessing of static final fields.. Otherwise, I guess that I shall have to ditch Jetty and use some other library. |
|
You'll have the same problem with JDK classes as well. (security, inetaddress resolvers, filesystems, filesystemproviders, cipher suites, etc. At last count there are over 400 such use cases in Java 11, where a ServiceLoader lookup happens once and the values are cached/stored on a static / constant / pool / singleton / etc). |
|
It most certainly works with a core + addons added later, that's what Eclipse RT does with Jetty right now. |
Well.. it works if the whole of Jetty (Http/1.1 AND Http/2 jars) are pre-loaded together in the core. Unfortunately in my case only the Jetty Http/1.1 jars are pre-loaded in the core, whereas Jetty Http/2 jars are post loaded via the addon.
Pity, doesn't work (can't change static final fields).. |
|
We'll fix that. I agree it's not a jetty issue. |
|
Closing as it seems that the OpenHAB core folks are going to resolve this one. |
Issue
In my Java client application, when I send a client HTTP/2.0 PUT request, it throws an 'HpackException$SessionException' as shown in Error Log below; by contrast it succeeds when I send the exact same client HTTP/2.0 request, but with GET instead of PUT, as shown in Success Log below.
I guess this is because PUT is not in the static lookup table, whereas GET is so. ??
Windows 10, Java 17.0.5, OpenHab 4.0.0, Jetty 9.4.46.v20220331
Error Log
Success Log
The text was updated successfully, but these errors were encountered: