Results 1 to 4 of 4
  1. #1
    Join Date
    Aug 2003
    Posts
    3

    Exclamation Unanswered: Thread Hangs at SocketInputStream.read

    Running both on Linux Red Hat 7.2 and 8.0 with Oracle 9.2.0, ojdbc14.jar and JDK 1.4.0_02.

    We have been having threads that occasionally freeze. Looking at the JVM thread dump, we see a repeated pattern (see below) where by two threads get stuck at java.net.SocketInputStream.read(SocketInputStream. java:116). The frozen thread socket read commands always originate an oracle.sql.CLOB.getChunkSize command and a normal SQL statement.

    My initial hunch was a concurrency issue at an OS level but seeing that we were able to reproduce the error both under Red Hat 7.2 and 8.0 I must look to either the JVM, the Oracle thin JDBC or the DB itself. Note that reproducing the problem involves generating a very high traffic rate and waiting till the case happens.

    Any similar experiences? Any one with some clues?

    "Thread-31" prio=1 tid=0x0x822aec8 nid=0x3951 runnable [65090000..6509085c]
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream. java:116)
    at oracle.net.ns.Packet.receive(Unknown Source)
    at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine. java:931)
    at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine. java:893)
    at oracle.jdbc.ttc7.v8TTILob.receiveReply(v8TTILob.ja va:955)
    at oracle.jdbc.ttc7.v8TTILob.getChunkSize(v8TTILob.ja va:345)
    at oracle.jdbc.ttc7.TTC7Protocol.getLobChunkSize(TTC7 Protocol.java:3034)
    at oracle.sql.LobDBAccessImpl.getChunkSize(LobDBAcces sImpl.java:686)
    - locked <0x4688f498> (a oracle.sql.LobDBAccessImpl)
    at oracle.sql.CLOB.getChunkSize(CLOB.java:664)
    at oracle.sql.CLOB.getBufferSize(CLOB.java:689)
    at oracle.sql.CLOB.getCharacterStream(CLOB.java:317)
    at upstream.xsys.SQLMgr.readCLOB(SQLMgr.java:75)
    at upstream.xsys.xSmsUserMgr.makeUser(xSmsUserMgr.jav a:205)
    at upstream.xsys.xSmsUserMgr.readUser(xSmsUserMgr.jav a:138)
    at upstream.xsys.xSmsUserMgr.addUser(xSmsUserMgr.java :115)
    ...

    "Thread-30" prio=1 tid=0x0x82e4488 nid=0x394f runnable [64f8d000..64f8e85c]
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputSteam.j ava:116)
    at oracle.net.ns.Packet.receive(Unknown Source)
    at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine. java:931)
    at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine. java:893)
    at oracle.jdbc.ttc7.Oopen.receive(Oopen.java:105)
    at oracle.jdbc.ttc7.TTC7Protocol.open(TTC7Protocol.ja va:586)
    - locked <0x46827428> (a oracle.jdbc.ttc7.TTC7Protocol)
    at oracle.jdbc.driver.OracleStatement.<init>(OracleSt atement.java:385)
    at oracle.jdbc.driver.OracleStatement.<init>(OracleSt atement.java:413)
    at oracle.jdbc.driver.OraclePreparedStatement.<init>( OraclePreparedStatement.java:119)
    at oracle.jdbc.driver.OracleCallableStatement.<init>( OracleCallableStatement.java:77)
    at oracle.jdbc.driver.OracleCallableStatement.<init>( OracleCallableStatement.java:48)
    at oracle.jdbc.driver.OracleConnection.privatePrepare Call(OracleConnection.java:1133)
    at oracle.jdbc.driver.OracleConnection.prepareCall(Or acleConnection.java:988)
    - locked <0x46823830> (a oracle.jdbc.driver.OracleConnection)
    at com.addval.dbutils.DBConnection.prepareCall(DBConn ection.java:232)
    at com.upstreamsystems.sms.outbound.OutboundManager.a ddToTable(OutboundManager.java:360)
    at com.upstreamsystems.sms.outbound.OutboundManager.s endToGateway(OutboundManager.java:334)
    ...

    Patrick Hargitt

  2. #2
    Join Date
    Nov 2003
    Posts
    1

    Re: Thread Hangs at SocketInputStream.read

    I've had a similar problem, which took me quite some time to solve. In my particular case (maybe yours is different), I figured out that the thread hanging at java.net.SocketInputStream.socketRead0 is actually waiting for a transaction to be commited (simply due to basic database locking mechanism).

    You can easilly reproduce this stack by opening 2 different connections on a database. Turn auto-commit off, and update any row on any table from the 1rst connection, without commiting changes. From the second connection, try to read or update the same row in the same table: this thread will block on socketRead0. Commit changes in the 1rst connection, and your hanging thread will resume.

    Now, the question is: if transactions are the explanation, why don't they end up in commit/roll-back, and free the hanging thread? Most probably, the transaction can't be commited or rolled-back because of java synchronization => in other words, the thread hanging at socketRead0 is doing so in a synchronized block or method, which prevent other threads (transactions) from going further and commit/roll-back. A kind of mixed java-db dead-lock...

    I sincerely hope this will help. I found many people having experienced the socketRead0 problem, but not so many solutions (none actually). In my case, it was definitely not related to platform, JDBC, or product version.


    Originally posted by phargitt
    Running both on Linux Red Hat 7.2 and 8.0 with Oracle 9.2.0, ojdbc14.jar and JDK 1.4.0_02.

    We have been having threads that occasionally freeze. Looking at the JVM thread dump, we see a repeated pattern (see below) where by two threads get stuck at java.net.SocketInputStream.read(SocketInputStream. java:116). The frozen thread socket read commands always originate an oracle.sql.CLOB.getChunkSize command and a normal SQL statement.

    My initial hunch was a concurrency issue at an OS level but seeing that we were able to reproduce the error both under Red Hat 7.2 and 8.0 I must look to either the JVM, the Oracle thin JDBC or the DB itself. Note that reproducing the problem involves generating a very high traffic rate and waiting till the case happens.

    Any similar experiences? Any one with some clues?

    "Thread-31" prio=1 tid=0x0x822aec8 nid=0x3951 runnable [65090000..6509085c]
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream. java:116)
    at oracle.net.ns.Packet.receive(Unknown Source)
    at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine. java:931)
    at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine. java:893)
    at oracle.jdbc.ttc7.v8TTILob.receiveReply(v8TTILob.ja va:955)
    at oracle.jdbc.ttc7.v8TTILob.getChunkSize(v8TTILob.ja va:345)
    at oracle.jdbc.ttc7.TTC7Protocol.getLobChunkSize(TTC7 Protocol.java:3034)
    at oracle.sql.LobDBAccessImpl.getChunkSize(LobDBAcces sImpl.java:686)
    - locked <0x4688f498> (a oracle.sql.LobDBAccessImpl)
    at oracle.sql.CLOB.getChunkSize(CLOB.java:664)
    at oracle.sql.CLOB.getBufferSize(CLOB.java:689)
    at oracle.sql.CLOB.getCharacterStream(CLOB.java:317)
    at upstream.xsys.SQLMgr.readCLOB(SQLMgr.java:75)
    at upstream.xsys.xSmsUserMgr.makeUser(xSmsUserMgr.jav a:205)
    at upstream.xsys.xSmsUserMgr.readUser(xSmsUserMgr.jav a:138)
    at upstream.xsys.xSmsUserMgr.addUser(xSmsUserMgr.java :115)
    ...

    "Thread-30" prio=1 tid=0x0x82e4488 nid=0x394f runnable [64f8d000..64f8e85c]
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputSteam.j ava:116)
    at oracle.net.ns.Packet.receive(Unknown Source)
    at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.net.ns.NetInputStream.read(Unknown Source)
    at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine. java:931)
    at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine. java:893)
    at oracle.jdbc.ttc7.Oopen.receive(Oopen.java:105)
    at oracle.jdbc.ttc7.TTC7Protocol.open(TTC7Protocol.ja va:586)
    - locked <0x46827428> (a oracle.jdbc.ttc7.TTC7Protocol)
    at oracle.jdbc.driver.OracleStatement.<init>(OracleSt atement.java:385)
    at oracle.jdbc.driver.OracleStatement.<init>(OracleSt atement.java:413)
    at oracle.jdbc.driver.OraclePreparedStatement.<init>( OraclePreparedStatement.java:119)
    at oracle.jdbc.driver.OracleCallableStatement.<init>( OracleCallableStatement.java:77)
    at oracle.jdbc.driver.OracleCallableStatement.<init>( OracleCallableStatement.java:48)
    at oracle.jdbc.driver.OracleConnection.privatePrepare Call(OracleConnection.java:1133)
    at oracle.jdbc.driver.OracleConnection.prepareCall(Or acleConnection.java:988)
    - locked <0x46823830> (a oracle.jdbc.driver.OracleConnection)
    at com.addval.dbutils.DBConnection.prepareCall(DBConn ection.java:232)
    at com.upstreamsystems.sms.outbound.OutboundManager.a ddToTable(OutboundManager.java:360)
    at com.upstreamsystems.sms.outbound.OutboundManager.s endToGateway(OutboundManager.java:334)
    ...

    Patrick Hargitt

  3. #3
    Join Date
    Nov 2003
    Location
    Bangalore, INDIA
    Posts
    333

    Thumbs up

    Hi,

    The error was due to the fact the table space was running out of space.
    Increase the table space and the problem is resolved.
    SATHISH .

  4. #4
    Join Date
    Apr 2009
    Posts
    1
    Hi Sathish, Castell,

    I am facing a simillar issue.
    Can you please elaborate on the solution??

    Thanks,
    Sourabh

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •