[jcifs] How to make jCIFS 1.3.14 more stable

[Michael B Allen]

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.

> 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/