[jcifs] Raise Condition in SmbFile.java

Michael B Allen mba2000 at ioplex.com
Wed Jun 2 18:53:55 GMT 2004


David Fahlander said:
> Dear colleagues, you only need to read a book about thread programming to
> see the that it is a bug. You always have to signal when a state has
> changed
> before you go into a wait! (In SmbFile.WriterThread.run() after setting
> ready = true).

Can you produce a thread dump or do you need to read a book for that?

>
> Except this error, I really adore the libraries (jcifs and smbdav). Easy
> to
> come in to and very usable. Thanks guys!
>
> This is what happened:
>
> 1) The Davenport servlet hanged after some frequently HTTP MOVE commands
> (which in it's turn used the SmbFile.copyTo() command)
>
> 2) I stopped all threads and found one thread that was waiting infinitely
> for 'ready' to become true in SmbFile.copyTo0() (while ( !w.ready )
> {w.wait()} ). This happened several times when I tested... always the same
> location.
>
> 3) I found the error (which to me obviously breaks the way of how to do
> thread communications).
>
> 4) The davenport servlet stopped hanging on MOVE commands after applying
> my
> patch!
>
> /David
>
> -----Original Message-----
> From: Michael B Allen [mailto:mba2000 at ioplex.com]
> Sent: den 2 juni 2004 00:44
> To: David Fahlander
> Cc: jcifs at samba.org
> Subject: Re: [jcifs] Raise Condition in SmbFile.java
>
> David Fahlander said:
>> The bug is that it may hang infinitely when for example calling
>> SmbFile.copyTo(). This only happens sometimes though since it is a race
>> condition. notify() must be called directly after changing ready = true,
>> otherwise other threads can wait for ever for a notification that it is
>> writeable.
>
>>From this description I'm not convinced. If you are observing a deadlock
> then post a thread dump (Ctrl-Break on Win32 or Ctrl-\ on *NIX I believe).
>
> Mike
>
>



More information about the jcifs mailing list