Sessions being left open with "closing session... err: EOF session not found in openRequests" #23
Assignees
Labels
bug
Something isn't working
help wanted
Extra attention is needed
wontfix
This will not be worked on
Comments
|
Hello @jessebye, which version of ktunnel are you using on the cluster's end? do you instrument it with the cli? |
|
Hi @omrikiei , I was using |
|
Hi @jessebye, it seems that after the connection is closed on the pod, data is received from the client(dev machine) and this yields the error.. |
|
@omrikiei hmm, so we are having this happen when using xdebug. The problem is that the php request never finishes, leaving a hanging xdebug connection. We have to kill the process every time before we send another request. I remember a while back you helped fix another xdebug issue; any chance you'd be willing to set up that stack again and see if you can reproduce this issue? |
|
it sounds like maybe the connection closes too soon, so the client tries to send data back to the xdebug pod after the connection is closed (possibly trying to finish the php thread?) and causes the error |
|
are there any timeouts that we might be hitting that would close the connection prematurely? |
|
Dial timeout was increased to 500ms in version 1.2.7(found here in the releases) could you see if the issue reproduces with that one? |
|
I updated to 1.2.7, but still getting errors like this: I notice that adding a breakpoint will cause the "session not found in openRequests" message to appear. It seems like the session is closed when the IDE expects it to be open. And it makes sense, because we see the "closing session" messages above that. The question is what is causing the "closing session" to be triggered prematurely? |
|
Here are debug logs, if they are helpful. Local host: ktunnel expose container: |
|
Hey @jessebye - a new beta version now signals the client when a connection is closed on the server side, I think it might solve this issue. Since it's a change on the server code - I don't think you need to do anything but try to reproduce the issue and see what happens(it will pull the latest image from quay.io), let me know if the issue persists. |
|
Still seeing this issue with the latest image, unfortunately. |
omrikiei
pushed a commit
that referenced
this issue
Aug 1, 2020
|
Hi @jessebye - I modified the server to only close the connection if it was by a signal from the client. the fix is currently branched out to v_1_3 which I hope to release later this week. however if you'd like, you can clone build it locally and explicitly call the server version with the ./ktunnel expose -i quay.io/omrikiei/ktunnel:v_1_3 xdebug 9000I made some tests to make sure it doesn't break anything and that debugging works but it would be great to get a validation from a real PHP app(I was using a simple hello world) |
|
Hey @omrikiei , that is looking better but it still seems like there might be a problem: Usually I wouldn't need to hit the "Stop" button there after resuming program execution. It seems like the "EOF" message from ktunnel might be related? |
|
hey @jessebye, thanks for the feedback... i committed a minor fix to the branch - could you check now? |
|
Interesting, no longer see the "EOF" in the logs, but the same issue happens - the php thread never goes away on its own. |
|
Debug logs: |
|
@omrikiei sorry, we're still having some trouble because of this. Any idea how to resolve it? |
|
Not yet, I'll try to continue troubleshooting in the next couple of days.. |
omrikiei
added
help wanted
|
hi @jessebye, I'm finding it difficult to make time to troubleshoot and debug this issue, so it might take longer. I'm sorry :( |
|
Hey @jessebye, v1.3.0 now released and connection terminations are handled in a more graceful manner - could you please check if the issue persists on this version? |
|
Hi @omrikiei! I just upgraded to v1.3.0 and am really pleased to say the issue is gone! Thank you so much for your attention and work to get this fixed!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are using
ktunnelto usexdebugagainst our remote php pods. It works great, but we noticed that all connections are left open indefinitely.The
ktunnellogs show errors that seem to be related:How do we resolve this?
The text was updated successfully, but these errors were encountered: