[jcifs] idle sessions on netapp filer

[Volker Müller]

Hi Mike,

a have got a response from the NetApp people.

After analyzing a capture on the filer they find out that the filer 
requests the client to reduce the traffic by sending "tcp zero windows", 
but the client does'nt respond on it.
They know about such problems between NetApp-filer and JCIFS-clients and 
they do'nt support this clients. Thats it.

Do you see any chance to implement the capability to respond on this tcp 
zero windows?


Best regards,

Volker

Am 17.02.2012 18:20, schrieb Michael B Allen:
> On Fri, Feb 17, 2012 at 3:57 AM, Volker Müller
> <volker.mueller at xsystem.de>  wrote:
>> Hi all,
>>
>> we use JCIFS to list, up- and download files on NetApp-filers.
>> There are many users connecting to a number of shares located on different
>> filers. Each user connects to only one share.
>> The actions are running in own threads.
>>
>> Under some circumstands we notice idle sessions on the filer not being
>> cleaned up after jcifs.smb.client.soTimeout. This sessions will never
>>   cleaned up. We found out that uploads forces the problem.
>>
>> I wrote a testclient to isolate the problem.
>> This client starts some lists, downloads and uploads with random delay.
>> Lists and downloads seem not to enforce this problem, only uploads. When we
>> start round about 10 uploads, the problem occurs. Not in every case but more
>> often the more uploads are running.
>>
>> In the management console of the filer are a lot of open files, not only
>> uploads but even downloads. They remain even after the testclient will be
>> terminated. They must be killed manually on the filer.
>>
>> Has anyone an idea what happened and how to prevent from this problem?
>>
>> @Mike:I will send you two network dumps and screenshots from the management
>> console
> Hi Volker,
>
> I don't see anything unusual in these captures. The server is RST-ing
> the connection in the middle of the transfer so there's not much JCIFS
> can do about that. My guess is that NetApp is just not handling a lot
> of current activity well.
>
> Mike
>