[jcifs] How to make jCIFS 1.3.14 more stable

[Del Merritt]

Mike wrote:
> On Thu, Jun 3, 2010 at 4:49 PM, Del Merritt <del at alum.mit.edu> wrote:
>> Mike wrote:
>> I didn't try the second patch mentioned below.
>>
>> While on the subject of patches: the getBuffers() method in
>> jcifs.smb.BufferCache.java currently looks like this:
>>
>>    static void getBuffers( SmbComTransaction req,
>> SmbComTransactionResponse rsp ) {
>>        synchronized( cache ) {
>>            req.txn_buf = getBuffer();
>>            rsp.txn_buf = getBuffer();
>>        }
>>    }
>>
>> This causes performance issues on the BlackBerry platform.  I believe
>> this is
>> caused by what to me appears to be excessive use of "synchronized" in
>> that
>> method.  The getBuffer() method, which this calls, already is guarded
>> by:
>>
>>    synchronized( cache ) {...}
>>
>> So I don't believe it is required in getBuffers() as well, at least
>> given the
>> latter's current implementation.
>
>
> The synchronized in getBuffers is required because both buffers must
> be allocated together or not at all. Otherwise, Thread A could grab
> one buffer, Thread B could grab a second buffer at which point, if
> there were no more buffers, you would have a deadlock.

This is not quite true as implemented, though it could be your intent.

If you look closely at jcifs.smb.getBuffer(), you'll see that it will try
to allocate a new buffer whether or not there is room in the buffer cache.
 It is certainly the case that thread A and thread B (with my mod) could
each get a buffer, and then get hit with an Insufficient Memory exception.
 But that would not result in a deadlock unless the caller ignored the
exception(s).

But, again, as implemented, getBuffer() will try to return more than
MAX_BUFFERS of buffers if the system has sufficient memory.

> Also I somewhat doubt the "excessive use of synchronized" theory. You
> should be able to call synchronized any number of times. If you're
> seeing some kind of a problem with buffers I suspect it is simple
> buffer exhaustion. Although on a small handheld device you should
> probably *reduce* the number of buffers by setting
> jcifs.smb.maxBuffers = 4 or so. Each buffer is 16K which is probably
> quite a bit of memory for a phone. Besides, a phone is not going to be
> doing a lot of concurrent requests so it doesn't need a lot of
> buffers.

When I have a chance, I will do some timing studies.  But remember that
not all JVMs are created equal.  In fact, in J2ME CLDC (with MIDP
extensions optional) one is actually using a KVM, which hasa number of
very interesting differences from a "real" JVM.

Having not looked at the KVM implementation details, I could easily see
that any runtime checks on nested "synchronized" blocks that look for
deadlocks could be time consuming.  But I grant it is an untested and
unverified theory.

I still believe I saw "liveness" of the app improve when I removed that
particular synchronized keyword from that particular block.

-Del

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