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-issue-importer opened this issue Nov 25, 2019 · 8 comments
Closed

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

Modified by: @mrotteveel

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

resolution: Fixed [ 1 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 25, 2019

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