Disconnect() issue - thread hangs with "waiting for monitor" status

Hello,

I have a custom GTalk client using Smack API.

Everything works fine, but sometimes a thread that calls XMPPConnection object’s disconnect() method hangs.

It does not happen everytime, actually it’s very rare case, but anyway it’s not nice.

Below is a part of the thread dump that indicates the issue:

“Timer-1” prio=1 tid=0x92bab238 nid=0x4898 waiting for monitor entry http://0x9249d000…0x9249df40

at java.io.BufferedReader.close(BufferedReader.java:500)

  • waiting to lock <0x9d43aa78> (a java.io.InputStreamReader)

at org.jivesoftware.smack.XMPPConnection.shutdown(XMPPConnection.java:583)

at org.jivesoftware.smack.XMPPConnection.disconnect(XMPPConnection.java:643)

at org.jivesoftware.smack.XMPPConnection.disconnect(XMPPConnection.java:618)

Any suggestion to avoid this problem?

Hey Pavel,

Do you see a deadlock in the thread dump? At the end of the dump you should find deadlock information. Do you see any other thread locking 0x9d43aa78 ?

Thanks,

– Gato

No, there is no other thread with that ID…

Hold on. I’ve noticed that my log file with thread dump is corrupted, and the process has been restarted already so I can’t make a new thread dump

I’ll wait for the next occurence of this issue. It seems logical that if there is a sync issue in Smack classes - it may cause a deadlock.

All I need is to find where is it and change code to make it thread safe.

Hey Pavel,

That is not a thread ID but a hash (unique ID) of an object. If nothing else is locking that object then maybe you need to get a few thread dumps separated by a few seconds to confirm that threads are in fact locked and not working.

Regards,

– Gato

Ok, it has happened again and here is what I have from the thread dump:

  1. My thread that is locked:

“Timer-1” prio=1 tid=0x908568e0 nid=0x2151 waiting for monitor entry http://0x8d8a2000…0x8d8a2ed0

at java.io.BufferedReader.close(BufferedReader.java:500)

  • waiting to lock <0x9f1c4228> (a java.io.InputStreamReader)

at org.jivesoftware.smack.XMPPConnection.shutdown(XMPPConnection.java:583)

at org.jivesoftware.smack.XMPPConnection.disconnect(XMPPConnection.java:643)

at org.jivesoftware.smack.XMPPConnection.disconnect(XMPPConnection.java:618)

at … some my classes here…

  1. Another thread created by Smack that probably causes the deadlock:

“Smack Packet Reader (293)” daemon prio=1 tid=0x8c029ca0 nid=0x1214 runnable http://0x83759000…0x83759e50

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)

at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)

  • locked <0x9f1db338> (a java.lang.Object)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:68 0)
    at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
  • locked <0x9f1c42b8> (a com.sun.net.ssl.internal.ssl.AppInputStream)
    at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
    at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
  • locked <0x9f1c4228> (a java.io.InputStreamReader)
    at java.io.InputStreamReader.read(InputStreamReader.java:167)
    at java.io.BufferedReader.fill(BufferedReader.java:136)
    at java.io.BufferedReader.read1(BufferedReader.java:187)
    at java.io.BufferedReader.read(BufferedReader.java:261)
  • locked <0x9f1c4228> (a java.io.InputStreamReader)

at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2971)

at org.xmlpull.mxp1.MXParser.more(MXParser.java:3025)

at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1384)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:368)

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:44)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:76)

What would you suggest?

Hey Pavel,

I see what is happening now. So the read/parsing thread is parsing something and at the same time you have another thread that asked to shutdown the connection. I’m curious why we didn’t hit this problem before. Which version of Smack are you using?

Thanks,

– Gato

I think it’s Smack 3.0.4 version (smack.jar file size is 268,021 bytes).

I also want to mention that I use this Smack version for a long time already, but the problem started to occur only several weeks ago.

Before it was rock solid stable. No code changes were done…

May be there are changes at Google GTalk side that affected Smack?

I’m wondering if there is a way to MANUALLY stop org.jivesoftware.smack.PacketReader thread for a connection object?

It should solve my problem by adding a little of extra code before I call “disconnect()” method.

I see there are several methods available like removePacketListener() and others, but I’m not sure if it’s a correct way to use them here…

Please advise.

Just bumping it up.

We still experience this problem on our servers and need to find any solution/workaround to solve that.

Any suggestions?