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
Created attachment 1413 [details]
Test code using jakarta commons-vfs
Created attachment 1414 [details]
This patch is a quick workaround I made, It is not he better solution
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.
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.