[jcifs] How to make jCIFS 1.3.14 more stable

[Del Merritt]

Mike wrote:
> On Mon, May 31, 2010 at 5:18 PM, calle henning <calle.henning at lapino.se>
> wrote:
>> Hi,
>>
>> I'm working for a client who uses jCIFS in some of their applications;
>> this to access their file servers located on different geographical
>> locations (even different countries). This client has had quite a lot of
>> issues accessing their file shares and the cause has always been said to
>> be badly configured servers, but I started to look at jCIFS as a another
>> possible cause for the client's issues and I found a couple of bugs in
>> jCIFS.
>>
>> The first bug that I found was a glitch in
>> jcifs.util.Transport.connect(long) that causes a time-out exception to
>> be thrown although no time-out has actually occurred.
>
> Hi Calle,
>
> It seems to me you just want to call
>
>   run_thread.notify();
>
> just before the return in run() when run_thread != thread? If yes,
> then you don't need the else and connected stuff. Just add the one
> line above.

I implemented Mike's version of the Transport.java change and it worked well;
it improved stability on the BlackBerry simulator and didn't seem to
adversely
impact the actual device.  Looks like a win to me.

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.

-Del

>
>> The second bug that I found was that jcifs.smb.SmbFile.doConnect() keeps
>> on using the same IP address on retries if the server resolves to
>> multiple IP addresses. The log message states that a new address is
>> being used but the same Transport instance is being used.
>
> Try the following:
>
>  884     void doConnect() throws IOException {
>  885         SmbTransport trans;
>  886         UniAddress addr;
>  887
>  888         addr = getAddress();
>  889         trans = SmbTransport.getSmbTransport(addr, url.getPort());
>  890         tree = trans.getSmbSession(auth).getSmbTree(share, null);
>  891
>  892         String hostName = getServerWithDfs();
>
> Meaning just take out the if (tree != null) { trans =
> tree.session.transport; part. That looks like it was just an
> optimization. You don't need the else disconnect stuff.
>
> Try both of the above simplifications and let me know if they work. If
> they are ok, I will try to apply them and run the usual tests.
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>