JLAN copying large files fails sometimes from Windows 7 clients to server

[bpiepers]

For the past months I have been working with the relatively old open source project called JLAN to extend it for a project that is using it for copying large files from and to the shares. I have integrated it with Kerberos and have extended the functionality so that a virtual directory structure is created based on the user that is logged in. 

We are currently struggling with a problem in the code that we are unable to fix yet but before I dive in, I would like to ask if this is the correct channel or location to submit questions to for this project? Are there people out there that are using the file transfer functionality of Alfresco (currently embedded in the product in the jar "alfresco-jlan-embed-6.2.jar")? Are there people here that are familiar with its code base and have built extensions/refactored it? 

Thanks in advance

[afaust]

There are people that are using the CIFS file server functionality embedded in Alfresco. There typically are no / very, very few that have built extensions on it or tried to refactor it. It is such a massively outdated codebase that it typically is just too much risk / effort to deal with, and there are usually very little benefits to be gained without extensive work.

You can ask your questsions here anyway - there is no other community site that remotely deals with JLAN. But you should not expect too much as well...

[bpiepers]

Thank you for your reply anyway, Mister Faust. Hopefully some useful comments here wrt the problem nevertheless: Our JLAN instance runs on a Red Hat Enterprise Linux environment as a service using the Tanuki software Wrapper in a Oracle 1.7 JVM. 

JLAN uses the java.nio.channels.SocketChannel to read and write from and to a TCP socket. When we copy very large files, at unpredictable moments, the connection between the client and JLAN is suddenly dropped. This does not happen all the time, approximately 95% of the files are written to the share successfully.

Diving into the code we see that in the TcpipSMBChannelHandler class' readPacket method, this method is trying to read the header from the SocketChannel first. In situations, however, where the problem occurs reading the header of the tcp packet fails to receive the expected 4 bytes. JLAN in that case simply throws an IOException and drops the connection entirely (seems to be a little bit of an over reaction but the developer must have thought this situation is so severe that dropping the connection entirely would be the only solution in these cases). When this happens, in most cases JLAN only receives 3 bytes, sometimes even less. If we, however, analyse the TCP packet that seems to be the cause of the failure using Wireshark we do not see any problems with that packet itself. It has a valid header and nothing seems to be wrong with the content either.

My question, of course, is what could be the root cause of this problem?

In the attachment a screenshot of a Wireshark capture. In packet 782979 the WriteAndX command with its contents in the "Reassembled TCP" panel. In packet 782986 the connection reset that followed after JLAN disconnected.

Adding log statements to the code that dump the contents of the package to a log file we see that JLAN makes the following of the Write AndX request:

2017-01-30 15:55:21.265 - Dumping contents of package with length: 4
0 - 00 00 00 64 ff 53 4d 42 32 00 00 00 00 98 01 c8 - ...d?SMB2......?

My guess is that there is some kind of concurrency problem (although no other clients are connected) or JLAN appears to be reading the contents of a socket channel buffer that has already been processed or has not been populated completely yet with the TCP packet.

Any help would be highly appreciated.

[bpiepers · Accepted solution]

This was solved by making some slight changes to the code. There are several packet handlers that first read the header of the packet that is processed but assume it can be read in one read action. This is not right and was changed to loop until the buffer was read.