[jcifs] patch for exposing transports
parkerman at gmail.com
Tue Aug 5 22:57:09 GMT 2008
>> - I know that it would be more scalable and efficient to re-use
>> transports, but I haven't been able to successfully do so without
>> having sporadic StatusAccessDenied errors, even when using smb
> That sounds like the "hiccup bug" which was diagnosed a few weeks ago.
> I also posted a message regarding fixing the issue:
> And someone posted a refcount based patch (that I can't speak for).
Yes, that's another valid approach. Are you considering including that
patch instead? Or are you not accepting patches? i really am not
partial to my patch, i'd just like something in the main line of jcifs
to fix this so that i don't have to maintain a locally modified
>> signing. This solution is scalable enough for my needs, and allows me
>> to choose between whether it's okay to fail occasionally with better
>> performance, or to never fail but with a heavier network/server load.
>> - using ssnLimit doesn't work well for me
> That should work so if it doesn't you might try to figure out why.
i know why--without some kind of patch to jcifs, servicing multiple
clients over the same transport causes what appears to be the "hiccup
bug" as you describe, which means that the transport may disconnect
before all auths have been serviced. why would anyone want
non-deterministic auth failures in their system when there are simple
>> - setting soTimeout to something like 1000 prevents lingering
> Actually increasing soTimeout should increase "lingering" connections.
i don't disagree. but since the default is 35000, setting it to 1000
is indeed a decrease.
>> connections. the whole auth process should never take more than 1
> It should take less than 1/10th of a second regardless of how soTimeout is set.
actually it depends on how long it takes the client to process the
type 2 and send the type 3 which may be more. but my statement was
meant to reflect that 1 second should be plenty of time.
More information about the jcifs