[jcifs] Re: Re: Disconnect from a share
asaupp at web.de
Fri Oct 14 12:16:08 GMT 2005
i saw two patch proposals on the mailing list - and wanted to ask kindly for a chance
to get them into one of the following versions.
>From: Michael B Allen <mba2000 <at> ioplex.com>
>Subject: Re: Disconnect from a share
>Date: 2005-08-12 20:21:22 GMT (8 weeks, 6 days, 15 hours and 22 minutes ago)
>On Fri, 12 Aug 2005 14:23:41 +0200
>Mathias Dietz <MDIETZ <at> de.ibm.com> wrote:
>> After some debugging (comparing tcp packages from smbclient with jcifs), I
>> found two causes for the "Broken Pipe" error.
>> 1) doDisconnect() sends a LogoffAndX packet and doesn't wait for the
>> This causes a server error message (Error writing xx bytes to client).
>> Solution: In SMBSession.logoff(boolean) replace
>> transport.send( request, null );
>> transport.send( request, new SmbComLogoffAndX(null));
>Ok, I think I see what's happening. But first, note that second
>parameter to SmbTransport.send() is actually a response object so
>passing an SmbComLogoffAndX is invalid. You got lucky because the
>SmbComLogoffAndXResponse decodes no data. A more appropriate object
>would be SmbComBlankResponse.
>But passing null to the transport indicates that it should not to wait
>for the response. This is slightly faster since we can move on to other
>things rather than sit there collecting a logging off response which
>has no useful information in it.
>The problem is that first of "other things" is to close the socket but
>apparently Samba hasn't written it's response yet so when it tries to
>do so it get's an error (albeit a harmless one).
I would be very interessted to have the Patch Michael proposed inside - putting
a 'new SmbComBlankResponse()' instead of null avoids that nasty errors Mathias mentioned.
Any chance to get that fix into one of the next versions?
>> I'm still very interessted in a disconnect() method , because I use jcifs
>> to monitor multiple samba servers (up to 100).
>> And I must create a new connection each 10-15 seconds.A disconnect() method
>> would help to save a lot of
>> resources (# of threads) und would make life easier.
>Again, the proper solution here is to add refcounting to the
>transport. That way you can leave soTimeout at 15 seconds (actually in
>your case you would probably want to make it 5 seconds) but when a request
>is outstanding on the transport it cannot be closed. That change is too
>invasive for me to add to mainline while we're in a stable period so
>you might elect to simply extend SmbFile to add your disconnect() method.
Is there a JCIFS roadmap showing in which version / around what time its planned to have the
refcounting feature? Is that something you are working on allready?
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
More information about the jcifs