[jcifs] Software caused connection abort

[eglass1 at comcast.net]

> Hi Guys,
> 
> Sorry to bother you again, I have been trying to figure out an error that is 
> happening sporadically in our J2EE application at the Content Management System 
> side. A user can view content in the CMS using our webapp and this is done via a 
> stream by connecting using sockets to the CMS. 
> 
> The following error occurs fairly often but not reproducably when a client 
> requests to view content;
> 
> 04.20 08:55:46.537	IdcServerThread-2176	Error uploading file 
> 'GBR0077.doc' to client.
> java.net.SocketException: Software caused connection abort: socket write error
> 	at java.net.SocketOutputStream.socketWrite0(Native Method)
> 	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> 	at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> 	at intradoc.server.ServiceHttpImplementor.sendFileResponse(Unknown 
> Source)
> 	at intradoc.server.FileService.doResponse(Unknown Source)
> 	at intradoc.server.Service.doRequest(Unknown Source)
> 	at intradoc.server.ServiceManager.processCommand(Unknown Source)
> 	at intradoc.server.IdcServerThread.run(Unknown Source)
> 
> My question is just whether using the jCIFS NTLM filter could cause such a 
> problem as the CMS vendor believes it is not their IdcServerThread and that it 
> is the network somehow.
> 

I don't believe this would be caused by jCIFS; the filter doesn't do any
filtering on the response output stream itself (it just passes through to
the underlying implementation).

One thing possibly to look at (I'm blue-skying at this point, since I have no
idea what the vendor software does); it appears the server may be writing to
the response from a separate thread.  From section 2.3.3.3 of the servlet
spec:

    Implementations of the request and response objects are not guaranteed to
    be thread safe. This means that they should only be used within the scope
    of the request handling thread.
    References to the request and response objects must not be given to
    objects executing in other threads as the resulting behavior may be
    nondeterministic.

Again, I'm just making wild guesses here, but it might be something to look at.


Eric