[jcifs] Timeout under load

[Rob Wygand]

Mike,

I'll try the upgrade... the only thing stopping me from upgrading has 
been that auditorymodels was down so I was unable to get the latest 
beta. It's back up now, though, and I will upgrade 1st thing monday morning.

... I'll let you know how it goes.

As for the load test, we have some testing software that simulates the 
load. I also wrote a simple test program that spawns X threads and bangs 
samba by doing essentially the same thing as the expensive test 
software. =) I'll send you that on Monday as well, if you'd like.

rjw

Michael B Allen wrote:

> On Fri, 18 Jan 2002 15:02:13 -0800
> Rob Wygand <rob at filefish.com> wrote:
> 
> 
>>Mike,
>>
>>Using beta4 (which admittedly I should upgrade, but I cannot at the 
>>moment)
>>
> 
> 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?
> 
> Mike
> 
>