jargon error on file close

[Guy Warner]

Hi

I have had an error occur when closing a file using jargon. The only
message I have got is below. The client (portal) that was saving a file
is running on the same server and the irods service has not been
affected and shows no errors in its log file that I can find. My server
is irods 2.1 and jargon version is 2.3. I would appreciate any help
that can be given in suggesting what caused it and what I can do to
avoid any repeats.

Thanks

Guy Warner

java.net.SocketException: Socket closed
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at edu.sdsc.grid.io.irods.IRODSConnection.flush(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSCommands.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.finalize(Unknown Source)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
14:34:01,286 ERROR [IRODSCommands:?] IOException closing connection
java.net.SocketException: Socket closed
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at edu.sdsc.grid.io.irods.IRODSConnection.flush(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSCommands.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.finalize(Unknown Source)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
14:34:01,286 ERROR [IRODSFileSystem:?] error on close
org.irods.jargon.core.exception.JargonException: error sending
disconnect on a close operation
at edu.sdsc.grid.io.irods.IRODSCommands.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.finalize(Unknown Source)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
org.irods.jargon.core.exception.JargonException: error sending
disconnect on a close operation
at edu.sdsc.grid.io.irods.IRODSCommands.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.close(Unknown Source)
at edu.sdsc.grid.io.irods.IRODSFileSystem.finalize(Unknown Source)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

--
Dr Guy Warner
E-mail: g...@cs.stir.ac.uk
Address: Room 4B58 Cottrell Building,
Department of Computing Science & Mathematics,
University of Stirling, Scotland, FK9 4LA
Phone: 01786 467433

--
The Sunday Times Scottish University of the Year 2009/2010
The University of Stirling is a charity registered in Scotland,
number SC 011159.

[Conway, Mike]

Hi Dr. Warner, I will take a look. The 'classic' version of Jargon that is
in the iRODS trunk used finalizers at times to clean things up, it appears
that this error was triggered by the running of a finalizer. This is an
annoyance, and should not interfere at all with the operation of iRODS or
Jargon. The issue is structural within the code, and is a primary reason
that there is a newer jargon-core library that handles connections in a
totally different, very explicit way.

If you are creating an IRODSFileSystem, then the best thing to do is close
that IRODSFileSystem, and avoid calling close() on the IRODSFile. The
close() method in IRODSFile is really only important in special
situations, where the caller does not have a reference to an
IRODSFileSystem. If you could send me the surrounding code, I could take a
look and perhaps give some tips on avoiding these messages. I would look
at where the IRODSFileSystem was created, and where close() was called
either on IRODSFileSystem or IRODSFile, or where an object instance was
left to finalizers.

Cheers,
Mike C

Mike Conway
DICE ­ UNC Chapel Hill
http://www.irods.org
skype: michael.c.conway
google: michael....@gmail.com

>--
>"iRODS: the Integrated Rule-Oriented Data-management System; A community
>driven, open source, data grid software solution" https://www.irods.org
>
> iROD-Chat: http://groups.google.com/group/iROD-Chat

[Guy Warner]

Hi

Thanks for help so far. I have attached the class I use for writing
irods files. This class essentially just wraps IRODSFileOutputStream so
as to avoid problems I encountered with not over-writing a file
correctly (I needed complete replacement not bitwise replacement). The
calling code typically uses a single IRODSFileSystem (cached as part of
the portal session) for several IRODSFile objects so I doubt I can call
close on it safely. I normally invoke this class with code along the
lines of:

FileWriteOutputStream fout = new FileWriteOutputStream(ddiFile);
ddiBuilder.marshal(fout);
fout.close();

I am reluctant to switch to a newer version of jargon since everything
else is working fine, but can look into that if necessary - provided it
is fully backwards compatible.

Thanks again.

Guy Warner

>> Department of Computing Science& Mathematics,

[Conway, Mike]

Certainly stay with the 'jargon trunk', it's stable and supported, I
mention that just to describe the nature of the issue. The close on the
output stream will only close the file, not the entire connection to
iRODS. Essentially, when you open a File in jargon, it asks iRODS, and
iRODS assigns a file descriptor internally on its side. Then, calling
close on the File, or on the File via a wrapping stream, does not
terminate the connection to iRODS, rather it sends a message telling iRODS
to release the descriptor.

In your example code, the above is what will happen. The error trace is
no related to the calls that you issued. I wonder if the situation might
be a time-out, or session termination in the portal? In that case, the
connection may have been retained and timed out by preserving the
IRDOSFileSystem in session. When the Session is destroyed, the
IRODSFileSystem finalizer method will be invoked, it's in this chain of
events that I suspect we might find the root cause. One consideration
will be the scope of the IRODSFileSystem connection to iRODS, and whether
it would be a useful strategy to maintain an iRODS connection per request,
rather than via session. It might boil down to the number of open iRODS
connections that are accumulated in the portal sessions during think time
for multiple users. Another approach might be to add an
HttpSessionListener that activates on sessionDestroyed() and calls close
on the IRODSFileSystem, instead of relying on a finalizer.

Treat these suggestions as based on assumptions, the explanation feels
right to me, but we can dig further. I am very interested in formulated
best practices for mid-tier apps interacting with iRODS.