Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

H2 Synchronization problem with tests that are sending duplicate frames #9602

Closed
loriadi opened this issue Oct 31, 2019 · 1 comment · Fixed by #9643
Closed

H2 Synchronization problem with tests that are sending duplicate frames #9602

loriadi opened this issue Oct 31, 2019 · 1 comment · Fixed by #9643
Assignees
Labels
in:Transport release bug This bug is present in a released version of Open Liberty release:20001 team:Sirius

Comments

@loriadi
Copy link
Contributor

loriadi commented Oct 31, 2019

Scenario:

  1. The H2 test sends two identical Headers frames, both with eos set
  2. The server starts to process the first frame on stream 3, and gets interrupted part way through processing. At this point the stream is in HALF_CLOSED_REMOTE state. We have read in the headers but have not sent the request on to be processed.
  3. The second identical frame comes in for stream 3 with eos set.
  4. The server recognizes that the stream is closing, can't accept a new read frame and sends a goaway frame saying the stream is already closed.
  5. The server cleans up all things stream 3 related.
  6. The server then gets back to processing the original valid HEADERS frame, but the resources have been deleted, and we get the NPE.
@loriadi loriadi self-assigned this Oct 31, 2019
@loriadi loriadi added the release bug This bug is present in a released version of Open Liberty label Nov 4, 2019
@loriadi
Copy link
Contributor Author

loriadi commented Dec 9, 2019

Exception = java.lang.NullPointerException
Source = com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.init
probeid = 1
Stack Dump = java.lang.NullPointerException
at com.ibm.ws.tcpchannel.internal.TCPConnLink.getRemoteAddress(TCPConnLink.java:367)
at com.ibm.ws.http.channel.h2internal.H2TCPConnectionContext.getRemoteAddress(H2TCPConnectionContext.java:58)
at com.ibm.ws.http.channel.internal.HttpServiceContextImpl.init(HttpServiceContextImpl.java:916)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.init(HttpInboundServiceContextImpl.java:119)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:298)
at com.ibm.ws.http.channel.h2internal.H2StreamProcessor$Http2Ready.run(H2StreamProcessor.java:1597)
at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:239)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:825)
]
at componenttest.custom.junit.runner.FATRunner.blowup(FATRunner.java:296)
at componenttest.custom.junit.runner.FATRunner.access$500(FATRunner.java:64)
at componenttest.custom.junit.runner.FATRunner$1.evaluate(FATRunner.java:246)
at componenttest.custom.junit.runner.FATRunner$2.evaluate(FATRunner.java:314)
at componenttest.custom.junit.runner.FATRunner.run(FATRunner.java:167)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in:Transport release bug This bug is present in a released version of Open Liberty release:20001 team:Sirius
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants