[jcifs] Timeout under load
Michael B Allen
mballen at erols.com
Sat Jan 19 15:51:56 EST 2002
On Fri, 18 Jan 2002 15:02:13 -0800
Rob Wygand <rob at filefish.com> wrote:
> Using beta4 (which admittedly I should upgrade, but I cannot at the
You gotta upgrade if I'm going to track this stuff down Rob. I don't
remember what the problems with beta 4 were exatly but there were some
tryClose adjustments that might fix the problem you're seeing. I thought
you were using listFiles? Other than that the API hasn't changed so
there's no reason why you shouldn't use the latest. If there are issues,
report them an I'll fix them. You couldn't possibly be better off with
a fleeting release like b4.
On the other hand, I have been thinking about the problems seen by
Dmitry and even though they were dismissed as user error I think there
may really be an issue with beta5 related to what you're seeing. I think
the jcifs.util.ThreadInterruptor isn't quite working. If a host does not
respond (I have seen hosts that do not respond to SYN packets at all) the
new Socket() call will hang indefinately. So I created a ThreadInterruptor
class to interrupt these hung calls. It works but unfortunately I don't
think they can be interrupted again after that. I don't know a lot about
it. I will have to investigate but that's the only thing I can think of
right now that might be the cause of your problems.
> I'm seeing an odd exception under load. If I load our server up
> with simulated users and have them continually perform actions for say,
Sounds like a great test. Is there any chance I could reproduce that simulation?
> 20 minutes or more, I will eventually see this exception: Exception
> listing file: Timeout waiting for response from server.
> 0.0.0.0<00>/10.1.3.202. The error class is 0x20 and the error code is 5000.
That's just a CLI exception meaning the client timed out waiting for
a reponse from the server. The question is wheather or not the client
really didn't receieve the exception and if it didn't how to properly
handle the problem. I think you really need that tryClose code that went
into a later betas.
> Samba is still running on the machine in question, and I can access it
> just fine using smbfs or smbclient, so it's definetly something on the
> client side. Also, once this exception occurs, that jCIFS no longer
> works -- it continues to report the same exception even though the
> server is running.
> Was/is this a known issue? If not, any thoughts on what might be causing it?
The way we deal with an error like that is to close the connection thus
causing the upper level calls to reestablish the connection. I think
you have to try the upgrade. Did you guys really modify this stuff so
much that you can't pop in the latest and see how it performs?
May The Source be with you.
More information about the jcifs