Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.9K Databases
- 221.6K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.9K SQL & PL/SQL
- 21.3K SQL Developer
- 295.4K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 400 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
TCP behavior with OJDBC

Hello,
I hope this is the right place to ask, do not hesitate to correct me if needed.
I have an issue with the TCP handshake of the JDBC version 19.12.0.0.0. The connection to the Oracle DB is not established because during the initial handshake, the driver sends a packet with the TCP flags "PSH, ACK, URG" and this very packet is dropped by the firewall sitting between the client and the server because it is considered as "malformed".
I have tested with and the OJDBC version 12.2.0.1.0 and we don't have any issue because there's no special TCP flags used.
My question is : is the use of the TCP flags "PSH, ACK, URG" an expected behavior from the OJDBC driver ? Why did it change between those two OJDBC versions ?
Thanks in advance for your help.
Best regards
Best Answer
-
Hi there,
I believe this is JDBC testing if the network connection will support out-of-band (OOB) TCP urgent bytes. The driver can send an OOB byte to cancel a long running database call (this typically happens when a statement timeout expires).
If this is causing an issue, then you can try setting a connection property that disables the use of OOB entirely:
oracle.net.disableOob=true
Cancelling database calls with OOB is a bit faster than the alternative of cancelling with an in-band message. That is, you'll see the ORA-01013 error come back sooner than you would otherwise. If you really want fast cancellation, then allowing OOB bytes to pass through the firewall would be another option.
Thanks,
Michael
Answers
-
Hi there,
I believe this is JDBC testing if the network connection will support out-of-band (OOB) TCP urgent bytes. The driver can send an OOB byte to cancel a long running database call (this typically happens when a statement timeout expires).
If this is causing an issue, then you can try setting a connection property that disables the use of OOB entirely:
oracle.net.disableOob=true
Cancelling database calls with OOB is a bit faster than the alternative of cancelling with an in-band message. That is, you'll see the ORA-01013 error come back sooner than you would otherwise. If you really want fast cancellation, then allowing OOB bytes to pass through the firewall would be another option.
Thanks,
Michael
-
Great ! You were right and changing the property solved my issue.
Thanks a lot Michael.