Re: Thread sleeps forever on LoggedDataInputStream

Arjen Smedes wrote:

>Why do you use in.available in the first place ? in.read() is blocking as 
>well.
>  
>

Because I need to check the "Thread.interrupted()". Interrupt 
unfortunately does not interrupt in.read() method and therefore the 
command could not be killed from within the IDE if read() waits for data.

>For the time being, I'll work around it by streamlining the amount of 
>concurrent threads. I'd be interested to read about the final solution.
>  
>

It will most probably not be into NetBeans 4.0, we're approaching 
high-resistance mode. SocketChannel seems to have more flexibility, but 
the current API would have to change considerably, since streams are 
used quite heavily throughout the JavaCVS library.

I've submitted issue #50850 for this problem.

>if you need anything from me, let me know.
>  
>

Thanks,
Martin

>
>On Tuesday 26 October 2004 13:51, Martin Entlicher wrote:
>  
>
>>Aha, so the server closes the connection? In such a case I would expect
>>that "in.available()" would throw an exception. There does not seem to
>>be enough control in InputStream API, we can try to reimplement it using
>>NIO.
>>
>>Regards,
>>Martin
>>
>>Arjen Smedes wrote:
>>    
>>
>>>I do, there is a PServerConnection for every command. We have already
>>>figured out that the problem originates from the CVS server, which
>>>prevents a DOS (denial of service) attack. But the readLine()
>>>implementation doesn't seem to handle this situation properly and 'hangs'
>>>on the 'loop : while (true)' construct.
>>>
>>>On Tuesday 26 October 2004 11:39, Martin Entlicher wrote:
>>>      
>>>
>>>>Hi Arjen,
>>>>
>>>>do you have the n instances of Client over a single connection? It seems
>>>>that the problem can be caused by multiple commands sharing the same
>>>>stream.  Please assure that you have a different connection for every
>>>>command.
>>>>
>>>>Regards,
>>>>Martin
>>>>
>>>>Arjen Smedes wrote:
>>>>        
>>>>
>>>>>Hi,
>>>>>
>>>>>I have found a few issues that deal with multi-threading in the javacvs
>>>>>library. I haven't found the problem I am facing at the moment.
>>>>>
>>>>>I am running n parallel Client threads (RlogCommands or UpdateCommands)
>>>>>on a cvs repository. Sometimes it works fine, but sometimes my
>>>>>application blocks. If I debug the lot, it turns out that a few threads
>>>>>are waiting forever. Here's a snippet from the thread dump:
>>>>>
>>>>>"Thread-91" prio=1 tid=0x08073038 nid=0x2fc0 waiting on condition
>>>>>[4efa2000..4efa2cd0]
>>>>>	at java.lang.Thread.sleep(Native Method)
>>>>>	at
>>>>>org.netbeans.lib.cvsclient.util.LoggedDataInputStream.readLine(LoggedDat
>>>>>aI nputStream.java:51) at
>>>>>org.netbeans.lib.cvsclient.connection.PServerConnection.openConnection(P
>>>>>Se rverConnection.java:188) at
>>>>>org.netbeans.lib.cvsclient.connection.PServerConnection.open(PServerConn
>>>>>ec tion.java:300) at
>>>>>org.netbeans.lib.cvsclient.Client.ensureConnection(Client.java:270) at
>>>>>org.netbeans.lib.cvsclient.command.log.RlogCommand.execute(RlogCommand.j
>>>>>av a:263) at
>>>>>org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:533) at
>>>>>nl.toolforge.karma.core.vc.cvsimpl.CVSRunner.executeOnCVS(CVSRunner.java
>>>>>:5 64) at
>>>>>nl.toolforge.karma.core.vc.cvsimpl.CVSRunner.log(CVSRunner.java:453) at
>>>>>nl.toolforge.karma.core.vc.cvsimpl.threads.CVSLogThread.run(CVSLogThread
>>>>>.j ava:65)
>>>>>
>>>>>
>>>>>The more I increase "Thread.currentThread().sleep(200);" in
>>>>>LoggedDataInputStream.readLine(), the more certain I am from this
>>>>>blocking situation happening, although if I set it to 0, it happened to
>>>>>me as well.
>>>>>
>>>>>I haven't got a clue as yet.
>>>>>
>>>>>In the mean time, I'll keep looking myself, as it is blocking for my
>>>>>project.
>>>>>
>>>>>Any help is appreciated.
>>>>>
>>>>>Regards,
>>>>>
>>>>>Arjen.
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [email protected]
>>>>>For additional commands, e-mail: [email protected]
>>>>>          
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [email protected]
>>>>For additional commands, e-mail: [email protected]
>>>>        
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [email protected]
>>>For additional commands, e-mail: [email protected]
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
>  
>