[jcifs] Possible deadlock on SmbFile.getInputStream()?

[Robin Jansohn]

I've written a parser which (for now) sequentially reads a file from around
10000 shares. I'm getting what seems like a deadlock after a couple of hours
of parsing (last time after ~4.5h). I'm not doing any threading yet to keep
it simple, connectionTimeout and readTimeout are set to 30 seconds.

Here's the thread dump of the interesting threads (I can also send the full
thread dump):
"RMI TCP Connection(30)-10.189.22.141" #1603 daemon prio=5 os_prio=0
tid=0x00000000551c3000 nid=0x11ec runnable [0x00000000594fe000]
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:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0x00000000f8780398> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$256(TCPTransport.java:683)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$10/305000138.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Locked ownable synchronizers:
- <0x00000000f87804d8> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"main" #1 prio=5 os_prio=0 tid=0x00000000024af800 nid=0x434 in Object.wait()
[0x000000000283e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:143)
- locked <0x00000000e0780978> (a jcifs.smb.SmbTransport)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
at jcifs.smb.SmbFile.connect(SmbFile.java:954)
at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
at jcifs.smb.SmbFile.open0(SmbFile.java:972)
at jcifs.smb.SmbFile.open(SmbFile.java:1006)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:73)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:65)
at jcifs.smb.SmbFile.getInputStream(SmbFile.java:2844)
at control.Parser.getFileEncoding(Parser.java:205)
at control.Parser.parse(Parser.java:141)
at control.Parser.run(Parser.java:85)
at control.Main.main(Main.java:40)

Locked ownable synchronizers:
- None




--
View this message in context: http://samba.2283325.n4.nabble.com/Possible-deadlock-on-SmbFile-getInputStream-tp4699648.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.

[Michael B Allen]

Hi Robin,

I don't think this is a deadlock. And it doesn't look like it has much
if anything to do with JCIFS. At least it is clear that the thread
shown is just waiting on reading data from the socket. That is deep in
the Java sockets layer.

Verify that your soTimeout is set correctly. If the soTimeout is set
correctly, I would think the socket would have to give up after some
time. Or maybe things are just really really slow and it's just
failing over each operation / server very slowly such that it looks
like it's doing nothing.

Mike

Post by Robin Jansohn
I've written a parser which (for now) sequentially reads a file from around
10000 shares. I'm getting what seems like a deadlock after a couple of hours
of parsing (last time after ~4.5h). I'm not doing any threading yet to keep
it simple, connectionTimeout and readTimeout are set to 30 seconds.
Here's the thread dump of the interesting threads (I can also send the full
"RMI TCP Connection(30)-10.189.22.141" #1603 daemon prio=5 os_prio=0
tid=0x00000000551c3000 nid=0x11ec runnable [0x00000000594fe000]
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:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0x00000000f8780398> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$256(TCPTransport.java:683)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$10/305000138.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
- <0x00000000f87804d8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
"main" #1 prio=5 os_prio=0 tid=0x00000000024af800 nid=0x434 in Object.wait()
[0x000000000283e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:143)
- locked <0x00000000e0780978> (a jcifs.smb.SmbTransport)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
at jcifs.smb.SmbFile.connect(SmbFile.java:954)
at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
at jcifs.smb.SmbFile.open0(SmbFile.java:972)
at jcifs.smb.SmbFile.open(SmbFile.java:1006)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:73)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:65)
at jcifs.smb.SmbFile.getInputStream(SmbFile.java:2844)
at control.Parser.getFileEncoding(Parser.java:205)
at control.Parser.parse(Parser.java:141)
at control.Parser.run(Parser.java:85)
at control.Main.main(Main.java:40)
- None
--
View this message in context: http://samba.2283325.n4.nabble.com/Possible-deadlock-on-SmbFile-getInputStream-tp4699648.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.

[Robin Jansohn]

In my case those are all Windows 7 clients.



--
View this message in context: http://samba.2283325.n4.nabble.com/Possible-deadlock-on-SmbFile-getInputStream-tp4699648p4700767.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.

[ryan90]

I have been able to get a packet capture of the problem;

<Loading Image...>

Does anyone have any insight on NET 3.5 and Jcifis or a encryption problem
this could be indicating?



--
View this message in context: http://samba.2283325.n4.nabble.com/Possible-deadlock-on-SmbFile-getInputStream-tp4699648p4700836.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.