Possible deadlock on SmbFile.getInputStream()?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Possible deadlock on SmbFile.getInputStream()?

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


On Tue, Mar 15, 2016 at 3:27 AM, Robin Jansohn <[hidden email]> wrote:

> 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
Java Active Directory Integration
http://www.ioplex.com/

Reply | Threaded
Open this post in threaded view
|

Re: Possible deadlock on SmbFile.getInputStream()?

ryan90
This post has NOT been accepted by the mailing list yet.
This post was updated on .
In reply to this post by Robin Jansohn
I have also seen this error and have not been able to find a fix. Do you know what device you were connecting to that caused the hang, this may give us the insight?
Reply | Threaded
Open this post in threaded view
|

Re: Possible deadlock on SmbFile.getInputStream()?

Robin Jansohn
In my case those are all Windows 7 clients.
Reply | Threaded
Open this post in threaded view
|

Re: Possible deadlock on SmbFile.getInputStream()?

ryan90
This post was updated on .
I have been able to get a packet capture of the problem; It is showing a malformed packet exception, which looks like it is causing the problem. The Error "Unknown SMB , from NT 3.5 response"

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