[jcifs] Re: jcifs-1.2.4 stability fixes

[Michael B Allen]

On Thu, 6 Oct 2005 12:54:01 +0200
Lars heete <hel at admin.de> wrote:

> > I get the feeling you're not particularly interesting in persuing this
> > further. That's ok with me. To be honest, I don't actually use JCIFS
> > anymore so I'm doing this 100% for other people at this point.
>
> Im not using jcifs for own projects, but a customer had asked me to resolve 
> the threading issues. My changes to jcifs seem to work quite well for his 
> application so he is interested in getting them merged back.
> I also have a new version pending, that simplifies my changes and alters the 
> response wakeup-behavior to be more like jcifs-1.1, which was actually much 
> faster on transports with many active requests. (in jcifs 1.2 the notify on 
> response_map then causes many context switches).
> I also have some ideas to resolve the tree/session/transport locking issues 
> you a trying to address, but this is definitly more for a 2.0 version than a 
> 1.x.

One of the main problems with your original patch was that it was mostly
irrelevant stuff. If you resubmit it with only the changes necessary to
make the client behave the way you want then I will reconsider it. Aside
from the bug regarding adding the session back to transport.sessions
introduced in 1.2.5 (and your original "live lock" issue), that code
is relatively stable so make your patch against that. At this point I'd
say the "test" branch is on the shelf.

As for changing response wakeup-behavior [1] or your 2.0 ideas, please be
aware that my priority is stability and simplicity. Java synchronization
and I/O multiplexing is so pathetic I want to try to keep this thing
"as simple as possible, but not simpler". The list has been relatively
quite (until you came along :-) and I like it that way.

So if your solution is not clear and clean it will probably not be
accepted. I got the feeling from your first patch that you just moved
code around until it suited your application. That's ok but the changes
have to be clean enough to see that locking is correct and that they
will not affect the majority use cases. Note that by "simple" I don't
necessarily mean that the number of lines changed needs to be low but
it has to be clear to me that locking is correct.

Mike

[1] Note that lowering jcifs.smb.client.ssnLimit would probably suffice
    to resolve this issue. It was not really anticipated that the number
    of outstanding requests on a transport at one time would be more
    than say 2 or 3.