[jcifs] Canceling login negotiation

[Michael B Allen]

On Sun, 04 Sep 2005 15:46:06 +0900
Shunji Yamaura <ikemen at starseed.ne.jp> wrote:

> Hi all.
> 
> I am writing a virtual file system library using jCIFS.
> I want it be able to cancel file transfer immediately,
> so I want to know how to cancel negotiation.
> 
> I called interrupt() method of the thread,
> it succeeded to cancel negotiation, but the thread doesn't 
> stop and continues outputting this stack trace forever 
> and spend all CPU resource.
> 
> jcifs.util.transport.TransportException: Invalid state: 2
> 	at jcifs.util.transport.Transport.disconnect(Transport.java:192)
> 	at jcifs.util.transport.Transport.loop(Transport.java:114)
> 	at jcifs.util.transport.Transport.run(Transport.java:229)
> 	at java.lang.Thread.run(Unknown Source)

Well the transport wasn't really designed with interrupt() in mind and I'm not certain it is reasonable to support such a thing as it might complicate the range of states greatly.

> Please tell me how to avoid this problem or whether if I shouldn't call 
> interrupt() method.
> I read Transport.java and found disconnect() method throws Exception
> but doesn't kill the thread if the state is 1 or 2 around 192.

Actually I think calling disconnect() should actually disconnect the transport if you are fully connected. But I don't think you want to actually shutdown the transport. You want to cause the loop that's sending requests through the transport to exit. So find the loop the caller's thread is in during the transfer and look at it's exit condition. Then find a way to influence the exit condition so that the thread returns gracefully. This could be as easy as setting "index = count" or something like that so that the loop thinks it's "done". Then you can extend SmbFile so that you can add a method that reaches down and sets whatever is necessary to trigger the loop exit condition. Do not try to interrupt() or stop() or kill() anything. That's just bad programming.

Mike