[jcifs] idle sessions on netapp filer

[Michael B Allen]

On Fri, Apr 13, 2012 at 10:49 AM, Volker Müller
<volker.mueller at xsystem.de> wrote:
> 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?

Hi Volker,

I am not familiar with TCP zero windows. But it sounds very much like
something happening at the TCP layer and not the application layer.
Meaning it might be something that is a parameter of the OS or maybe
some kind of JVM parameter. I'm just guessing of course. But because
JCIFS works at the application layer, I don't think this is something
that we can "implement".

However, you might consider that the NetApp people might not be
telling you the whole truth. It is not uncommon for an IT support
group to us some sort of "red herring" to close issues that they do
not want to fix because they have other bigger problems. Meaning if
you really want to fix this, you should figure out what TCP zero
windows is and actually verify what NetApp is claiming before you try
doing something like play around with OS controlled TCP properties.

Mike

> 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
>>
>
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/