[jcifs] Infinite loop of error messages
Michael B Allen
mba2000 at ioplex.com
Thu Sep 28 19:14:51 GMT 2006
On Thu, 28 Sep 2006 19:58:16 +0200
Christophe Bouthier <Christophe.Bouthier at inpl-nancy.fr> wrote:
> We are using the jcifs (version 1.2.7) in a uPortal channel (uPortal
> is a java portal for education). Since a few days, we get from times
> to times our logs files filled with this error message:
> jcifs.util.transport.TransportException: Invalid state: 2
> at jcifs.util.transport.Transport.disconnect(Transport.java:
> at jcifs.util.transport.Transport.loop(Transport.java:124)
> at jcifs.util.transport.Transport.run(Transport.java:242)
> at java.lang.Thread.run(Thread.java:595)
> And when I say filled, it's filled unitl the partition is full. The
> only solution we have then is to delete the log file and restart the
> After searching on google, we have found only one reference to this
> kind of error, but it was when someone interrupted the connection.
> Here, the code calling the jcifs lib is not ours, but checking it we
> didn't found any interrupt() references.
I have never heard of this occurring without interrupt() but it is
still possible that there is an error in our logic. Look at the log for
> Does someone has already got this kind of problem ? Can someone gives
> us a clue or a hint to start searching ?
> After reading the source code of the jcifs.util.transport.Transport
> class, it seems that in the loop method, if an exception is raised,
> the exception is logged in the log file, but without leaving the
> loop. (This is the reason why it's filling the disk partition). Is it
> a normal behaviour ? Why not leaving the loop if an exception is
> raised ?
Because then the transport would stop processing data. The transport
should only exit after disconnect() is called successfully.
> Especially if it is this exception
> (jcifs.util.transport.TransportException: Invalid state: 2) ?
In this case, yes, I suppose a more drastic measure should be taken since
an "Invalid state" exception means that the transport is fatally defunct.
> Also, what is the difference between the "run connected" (2) state
> and the "connected" (3) state ? Why is it an error to disconnect
> when in the "run connected" state when it is not in the "connected"
> state" ?
Even if run() calls doConnect() the Transport isn't considered "connected"
until control is returned to the thread calling connect(). Meaning
Transport.connect() needs to wait until the new thread calls run(). Then
control is passed back to connect(). To coordiate that requires an
extra state (run connected vs connected).
Michael B Allen
PHP Active Directory SSO
More information about the jcifs