2

Recently I upgraded from JConn2 Sybase driver to JConn4. My Java jdbc code repeatedly calls a proc. Each proc call is ~1000 times slower with JConn4. JConn2 the avg is ~2ms. With JConn4 it is ~2s.

The proc is called via CallableStatement.

Does anybody know if there are some connection properties that have changed with JConn4 that perhaps need to be set to eliminate this performance issue?

This is Linux environment.

I took the thread dump and all I see is traces like this: 

java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at com.sybase.jdbc4.timedio.RawDbio.reallyRead(RawDbio.java:404)
        at com.sybase.jdbc4.timedio.Dbio.doRead(Dbio.java:257)
        at com.sybase.jdbc4.timedio.InStreamMgr.readIfOwner(InStreamMgr.java:583)
        at com.sybase.jdbc4.timedio.InStreamMgr.doRead(InStreamMgr.java:319)
        at com.sybase.jdbc4.tds.TdsProtocolContext.getChunk(TdsProtocolContext.java:622)
        at com.sybase.jdbc4.tds.PduInputFormatter.readPacket(PduInputFormatter.java:239)
        at com.sybase.jdbc4.tds.PduInputFormatter.read(PduInputFormatter.java:72)
        at com.sybase.jdbc4.tds.TdsInputStream.read(TdsInputStream.java:91)
        at com.sybase.jdbc4.tds.TdsInputStream.readUnsignedByte(TdsInputStream.java:124)
        at com.sybase.jdbc4.tds.Tds.nextResult(Tds.java:2912)
        at com.sybase.jdbc4.jdbc.ResultGetter.nextResult(ResultGetter.java:78)
        at com.sybase.jdbc4.jdbc.SybStatement.nextResult(SybStatement.java:293)
        at com.sybase.jdbc4.jdbc.SybStatement.nextResult(SybStatement.java:275)
        at com.sybase.jdbc4.jdbc.SybStatement.executeLoop(SybStatement.java:2827)
        at com.sybase.jdbc4.jdbc.SybCallableStatement.execute(SybCallableStatement.java:244)
user2879770
  • 23
  • 4
  • Such performance problems are often caused by missing random entropy, is this Linux? You should easily spot that if you create a thread dump. (The cause may be that newer drivers use more secure login methods) – eckes Sep 07 '18 at 15:33
  • yes this is linux – user2879770 Sep 07 '18 at 15:37
  • 2s is such a large delay it will show up in the thread dump and it can only be explained with things like failed connects, timeouts, drained resources. – eckes Sep 07 '18 at 15:46
  • I took the thread dump and all I see is traces like I put in the post above – user2879770 Sep 07 '18 at 19:51
  • Ok, that thread dump does not point to any client side delays. – eckes Sep 09 '18 at 13:42

1 Answers1

1

The primary change between Jconn2 and Jconn4 is the default setting of the DYNAMIC_PREPARE parameter. Try setting it to FALSE in the connect parameters.

This page tells how to change the DYNAMIC_PREPARE parameter.

Adam Leszczyński
  • 1,079
  • 7
  • 13