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

Jaybird SocketInputStream.socketRead0 thread blocking [JDBC599] #630

Closed
firebird-automations opened this issue Nov 25, 2019 · 8 comments
Closed

Comments

@firebird-automations
Copy link

Submitted by: Josef Melich (josef)

If I open the resultset over large data and start calling the resultSet.next(), sooner or later the thread becomes stuck in native SocketInputStream.socketRead0 method.

Firebird is running on one virtual machine and java application that reads the data is running on the other virtual machine. Both machines are Windows Server 2012 R2, but I think the bug also appears on another system. More detailed description I wrote here: https://stackoverflow.com/questions/58872811/jaybird-socketinputstream-socketread0-thread-blocking

I already have test machines on which the error can be simulated. (@mark, please send me your private mail address and I will send you the access on these test machines)

Thank you for solving.

Commits: c584dbd 32988ae

@firebird-automations
Copy link
Author

Modified by: Josef Melich (josef)

description: If I open the resultset over large data and start calling the resultSet.next(), sooner or later the thread becomes stuck in native SocketInputStream.socketRead0 method.

Firebird is running on one virtual machine and java application that reads the data is running on the other virtual machine. Both machines are Windows Server 2012 R2, but I think the bug also appears on another system. More detailed description I wrote here.

I already have test machines on which the error can be simulated. (@mark, please send me your private mail address and I will send you the access on these test machines)

Thank you for solving.

=>

If I open the resultset over large data and start calling the resultSet.next(), sooner or later the thread becomes stuck in native SocketInputStream.socketRead0 method.

Firebird is running on one virtual machine and java application that reads the data is running on the other virtual machine. Both machines are Windows Server 2012 R2, but I think the bug also appears on another system. More detailed description I wrote here: https://stackoverflow.com/questions/58872811/jaybird-socketinputstream-socketread0-thread-blocking

I already have test machines on which the error can be simulated. (@mark, please send me your private mail address and I will send you the access on these test machines)

Thank you for solving.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

At this time, I'm not sure if I need access to this machine. I am able to reproduce the problem, I'm just not able to find the cause other than that it has something to do with the wire encryption. The fact I can increase the odds of it occurring by increasing the TcpRemoteBufferSize in Firebird, would indicate it is a server problem, but if that were the case then I would expect that not only Jaybird would have these problems. This is further complicated by the fact that I can only reproduce it with a combination of tests (from the Jaybird tests) across multiple connections and multiple databases.

@firebird-automations
Copy link
Author

Commented by: Josef Melich (josef)

Yes, I know that is hard problem. We will test tomorrow wireCrypt=disabled on production version. I will let you know the result. Thank you for solving. Have a nice day, Josef.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

On the other hand, maybe it gives me some additional insights. You can email me at: mark (at) lawinegevaar (dot) nl

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 4.0.0-beta-2 [ 10902 ]

Fix Version: Jaybird 3.0.8 [ 10916 ]

Fix Version: Jaybird 4 [ 10441 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Problem was how padding was read. It used skip, which worked fine with BufferedInputStream(SocketInputStream), but didn't work as Jaybird expected with BufferInputStream(CipherInputStream(SocketInputstream)). When the BufferedInputStream had exhausted its buffer, and the CipherInputStream was at the end of its buffer (or had 1 or 2 bytes remaining), it wouldn't read the full padding. This would then cause subsequent reads to read the wrong data, and eventually either trigger a read blocked waiting for more data, or an "Unsupported or unexpected operation code" exception.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment