Issue Details (XML | Word | Printable)

Key: JDBC-599
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Mark Rotteveel
Reporter: Josef Melich
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Jaybird SocketInputStream.socketRead0 thread blocking

Created: 25/Nov/19 07:42 AM   Updated: 25/Nov/19 03:41 PM
Component/s: JDBC driver
Affects Version/s: Jaybird 3.0.5, Jaybird 3.0.6, Jaybird 3.0.7
Fix Version/s: Jaybird 3.0.8, Jaybird 4.0.0-beta-2, Jaybird 4

Environment: Windows Server 2012 R2


 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 25/Nov/19 09:15 AM
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.

Josef Melich added a comment - 25/Nov/19 09:22 AM
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.

Mark Rotteveel added a comment - 25/Nov/19 09:24 AM
On the other hand, maybe it gives me some additional insights. You can email me at: mark (at) lawinegevaar (dot) nl

Mark Rotteveel added a comment - 25/Nov/19 02:14 PM
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.