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.
Created attachment 1413 [details] Test code using jakarta commons-vfs
Created attachment 1414 [details] Workaround patch 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.