[jcifs] java.net.SocketException: Broken pipe

Michael B Allen ioplex at gmail.com
Mon Jul 20 13:07:48 MDT 2009

PS: Please send all messages to the JCIFS mailing list.

On Mon, Jul 20, 2009 at 3:07 PM, Michael B Allen<ioplex at gmail.com> wrote:
> On Mon, Jul 20, 2009 at 11:37 AM, Yogesh K Shukla<yshukla at lexmark.com> wrote:
>> Michael, like I said once I see the broken pipe error, the app will not be
>> able to connect to the share using jcifs, no matter how long I try.
>> I have done some more tests and seen some strange behavior. For example:
>> even if I give my app permission to do socket operations. The app would work
>> once, and then if I let the socket timeout and try again, it would throw a
>> SocketPermission exception for the same port that it worked before. Is there
> It sounds like there is also a VM setup issue compounding the problem.
> If the socket closes, JCIFS will do 'new Socket(...)' the next time so
> if you get a permissions error at the point there is also something
> else going on.
> You might consider using a separate ClassLoader to load JCIFS each
> time you want to use it.
>> some way I can force jcifs to clean-up connections once I am in an error
>> state?
> If doDisconnect fires, it closes everything and sets things to null so
> I don't think this will help you.
> Again, I don't have much "Free" time anymore so you're going to have
> to dig deeper.
> Mike
>> Michael B Allen <ioplex at gmail.com>
>> 07/17/2009 01:37 PM
>>         To:        Yogesh K Shukla <yshukla at lexmark.com>
>>         cc:
>>         Subject:        Re: [jcifs] java.net.SocketException: Broken pipe
>> I see. So it's an embedded device that can be suspended and when you
>> resume, the socket is of course no longer there so you get "broken
>> pipe".
>> At one point I'm pretty sure JCIFS caught exceptions like that and
>> transparently retried the operation. But the code has changed over the
>> years.
>> The transport is closed when jcifs.smb.client.soTimeout expires and
>> throws a TimeoutException. But that's not where you want to fix the
>> problem.
>> Look at SmbTransport.doSend and doSend0. From looking at doSend0 it
>> looks like it does disconnect the transport if an IOException occurs
>> so it should be able to recover after the error occurs once. So you
>> should be able to catch and retry at the application level.
>> I have added an entry to the TODO to investigate adding a retry loop
>> somewhere (if there isn't one already that isn't just a little broken)
>> to make that particular "broken pipe" exception recover transparently.
>> However don't wait for me to fix this. It could be a year or two
>> before this sort of modification makes it into the standard
>> distribution.
>> Mike
>> On Fri, Jul 17, 2009 at 9:57 AM, Yogesh K Shukla<yshukla at lexmark.com> wrote:
>>> Mike, the device I work on has the JVM tied with the OS and the only way
>>> to
>>> restart my app or the JVM is to reboot the machine. So I can not perform
>>> the
>>> test you requested. I noticed that in the jcifs code does not explicitly
>>> close the socket connections under normal operations. The
>>> SmbTransport.doDisconnect() that closes the sockets is only called during
>>> exception handling. Is this by design? How and when does jcifs close
>>> connections?
>>> Thanks,
>>> Yogesh.
>>> Michael B Allen <ioplex at gmail.com>
>>> 07/14/2009 02:31 PM
>>>         To:        Yogesh Shukla <yshukla at lexmark.com>
>>>         cc:        jcifs at lists.samba.org
>>>         Subject:        Re: [jcifs] java.net.SocketException: Broken pipe
>>> On Tue, Jul 14, 2009 at 1:04 PM, Yogesh Shukla<yshukla at lexmark.com> wrote:
>>>> Did anyone using jcifs ever see SocketException with broken pipe? I am
>>>> getting
>>>> this randomly. This seems to happen very rarely but once it does my app
>>>> fails to
>>>> connect to the network share, unless I reboot the machine. And then again
>>>> it
>>>> would work fine until I see this error and then it would stop working
>>>> again.
>>>> java.net.SocketException: Broken pipe
>>>>        at java.net.SocketImpl.sendStreamImpl(Native Method)
>>>>        at java.net.SocketImpl.write(Unknown Source)
>>>>        at java.net.SocketOutputStream.write(Unknown Source)
>>>>        at jcifs.smb.SmbTransport.doSend(Unknown Source)
>>>>        at jcifs.util.transport.Transport.sendrecv(Unknown Source)
>>>>        at jcifs.smb.SmbTransport.send(Unknown Source)
>>>>        at jcifs.smb.SmbSession.sessionSetup(Unknown Source)
>>>>        at jcifs.smb.SmbSession.send(Unknown Source)
>>>>        at jcifs.smb.SmbTree.treeConnect(Unknown Source)
>>>>        at jcifs.smb.SmbFile.connect(Unknown Source)
>>>>        at jcifs.smb.SmbFile.connect0(Unknown Source)
>>>>        at jcifs.smb.SmbFile.queryPath(Unknown Source)
>>>>        at jcifs.smb.SmbFile.exists(Unknown Source)
>>> This error is not unusual in itself. It simply means the socket
>>> connection was lost.
>>> However, JCIFS should immediately recover. You should not need to
>>> reboot the machine.
>>> The next time it happens, try just restarting the application and not
>>> rebooting the machine. If restarting the JVM fixes the problem, then
>>> it is not a problem with the server in which case I will have to
>>> investigate further. Although it is a little difficult to simulate
>>> socket failures so I need some conclusive information before I add
>>> this to the TODO list.
>>> Mike
>>> --
>>> Michael B Allen
>>> Java Active Directory Integration
>>> http://www.ioplex.com/
>> --
>> Michael B Allen
>> Java Active Directory Integration
>> http://www.ioplex.com/
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/

Michael B Allen
Java Active Directory Integration

More information about the jcifs mailing list