Bug 3063 - jCIFS does not always recover from server errors
jCIFS does not always recover from server errors
Product: jCIFS
Classification: Unclassified
Component: core
All Linux
: P3 normal
: ---
Assigned To: Michael B. Allen
Depends on:
  Show dependency treegraph
Reported: 2005-09-05 07:05 UTC by Robert Marcano
Modified: 2005-09-20 23:04 UTC (History)
0 users

See Also:

Test code using jakarta commons-vfs (965 bytes, text/x-java)
2005-09-05 07:06 UTC, Robert Marcano
no flags Details
Workaround patch (712 bytes, text/x-patch)
2005-09-05 07:08 UTC, Robert Marcano
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Marcano 2005-09-05 07:05:59 UTC
I have an jCIFS application running inside a J2EE container, it dumps data to a
legacy application by exporting files to a remote smb resource. When a
communication error happens, for example the remote server is down, jCIFS
reports an exception, but when the server is available again jCIFS does not
recovers from the error state, it is needed to restart the entire J2EE container
JVM to do that.

The application using jCIFS is running on a Linux server.

I can reproduce the problem with a test program that creates a file in a remote
Windows XP each 20 seconds. After a few files are created, remove the cable
connection on the Windows XP, let the test application signal a few errors (40
seconds), then reconnect the cable. At this time jCIFS is unable to restablish
new connections.
Comment 1 Robert Marcano 2005-09-05 07:06:53 UTC
Created attachment 1413 [details]
Test code using jakarta commons-vfs
Comment 2 Robert Marcano 2005-09-05 07:08:02 UTC
Created attachment 1414 [details]
Workaround patch

This patch is a quick workaround I made, It is not he better solution
Comment 3 Michael B. Allen 2005-09-05 12:13:18 UTC
That patch might be ok but I thought once the transport goes into state=4
(meaning in error) the next attempt throws an exception *but also resets the
state back to 0*. I suppose that behavior is kind of odd regardless so I'll add
this to The List. But I'm not going to look at it asap so if your patch works
for you go with that. Or try 1.1.11. It has the old transport layer. It doesn't
have the state machine code that is ultimately causing the problem here.
Comment 4 Michael B. Allen 2005-09-20 23:04:25 UTC
This is fixed. Actually the problem was really that some calls to doSend where
not being caught and handled properly. So disconnect( hard ) was not being
called as it should when an IOException occured (e.g. Broken pipe due to socket
failure). The code should now recover gracefully. Also note that this is limited
to the new transport introduced in 1.2.