Payara
Payara copied to clipboard
[Regression] New HTTP/2 Warnings
Brief Summary
New warnings appear below. There were no warnings before. These warnings started appearing with Payara 6.2024.3
[#|2024-03-14T16:09:23.862+0000|WARNING|Payara 6.2024.3|org.glassfish.grizzly.http2.frames.SettingsFrame|_ThreadID=91;_ThreadName=http-thread-pool::http-listener-2(3);_TimeMillis=1710432563862;_LevelValue=900;|
Setting 2,794 is unknown and will be ignored|#]
[#|2024-03-14T16:09:32.167+0000|WARNING|Payara 6.2024.3|org.glassfish.grizzly.http2.frames.SettingsFrame|_ThreadID=90;_ThreadName=http-thread-pool::http-listener-2(2);_TimeMillis=1710432572167;_LevelValue=900;|
Setting 6,714 is unknown and will be ignored|#]
Expected Outcome
No warnings
Current Outcome
Warnings
Reproducer
No simple reproducer (at least not yet)
Operating System
Any
JDK Version
Any
Payara Distribution
Payara Server Full Profile
Hi @lprimak,
Could you please provide a simple-to-follow scenario on how to reproduce this on the latest version? A reproducer should ideally follow the SSCCE rules: http://www.sscce.org/. It will greatly help us to find the cause and fix it.
Thank you, Elif
I’m sorry I don’t have one. I have production monitoring logs and this was a new alert since upgrading
Hi @lprimak,
Could you please provide answers to the following questions, it would help us proceed with the issue;
- Can you describe the specific circumstances under which the HTTP/2 warning appears?
- Are you encountering the warning while using an HTTP/2 enabled endpoint in your application
- Could you specify if you're utilizing a particular development framework that may interact with HTTP/2.
It would be great if you could provide as much information as you could for us to get a better understanding.
Thank you, Elif
- I can't tell when this specifically happens, it's random / sporadic.
- Yes, http/2 endpoint is enabled (by default) and that's what I am using.
- JSF and PrimeFaces (latest release version)
I am sorry I can't be more helpful but the nature of this problem prevents this unfortunately.
Greetings, It's been more than 5 days since we requested more information or an update from you on the details of this issue. Could you provide an update soon, please? We're afraid that if we do not receive an update, we'll have to close this issue due to inactivity.
Not abandoned :)
I found a way to consistently reproduce the issue. Stay tuned.
Didn't work
Ok, here's how to reproduce. It's not quite trivial but it's simple and self-contained:
I did it in a docker container, but you don't have to. You can run any JDK starting with 17 and higher
Run docker container:
docker run -it --rm azul/zulu-openjdk-alpine:17-latest
Set up docker container:
apk update && apk add git maven curl firefox
Clone and run tests:
git clone https://github.com/flowlogix/flowlogix.git
cd flowlogix
curl https://raw.githubusercontent.com/lprimak/infra/main/scripts/cloud/docker/_builders/agent-maven-settings.xml -o /flowlogix/settings.xml
mvn verify -ntp -gs /flowlogix/settings.xml -Pui-test -Dwebdriver.browser=firefox -Dtest=none -Dsurefire.failIfNoSpecifiedTests=false
See the output in the logs:
less /flowlogix/target/dependency/payara6/glassfish/domains/domain1/logs/server.log
You will see the errors in the log file
Well, spoke too soon, the reproducer above fails to reproduce the issue. It's still not pinned down when / how this happens but it does.
I guess the only thing I learned today is that it only happens when Chrome is the client
Hi @lprimak,
Thank you for your efforts in reporting this issue. Unfortunately, as we have not received the necessary reproducer to consistently replicate the problem, we are unable to proceed with further investigation. Therefore, we will have to close this issue. If you are able to provide the details needed in the future, please feel free to reopen the issue or submit a new one.
Thank you, Elif
Hi, Elif,
Please reopen this. Just because it's not "reliably reproducible" at the moment doesn't mean the issue doesn't exist. I have worked hard to reproduce this issue, and even if unsuccessful, I don't want to see all that work wasted. Thank you
An advantage to keeping things like this open in the issue tracker can help provide visibility to community users who may run into the issue and have more resources/bandwidth to provide higher quality reproducers that help find the true root cause and and/or fix underlying issues.
Specifically, issues related to http/2 have been notoriously difficult to troubleshoot, fix, detect regressions in, or even make sense of or differentiate between new issues, regressions, or somewhere in between 😬
@lprimak, @phillipross, we understand your comments. We'd have no problem keeping this issue open until a reliable reproducer is created to properly fix the issue. Still, we have a clear support policy that states that all bug reports must be accompanied by a reliable reproducer to be formally escalated to our Platform engineers, so keep this in mind.
However, in the spirit of conceding that HTTP/2 issues are indeed challenging to troubleshoot, we'll keep this issue open for another two months to give you (or other community users) the opportunity to share a reliable (or semi-reliable) reproducer to help us patch the issue. I'm afraid that if no reproducer is found, we'll proceed to close the issue again.