directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: AddIT.testAddPDUExceedingMaxSizeLdapApi hangs on Windows Hudson (was: Build failed in Hudson: dir-apacheds-jdk16-win » ApacheDS Server Integration #53)
Date Tue, 30 Nov 2010 11:23:25 GMT
On 11/28/10 7:34 PM, Stefan Seelmann wrote:
> Hi guys,
> I reactivated the ApacheDS Windows build on Hudson, after I have
> tested extensively on my Windows7 virtual machine. Unfortunately the
> build failed again with hanging server-integ tests. Niklas Gustavsson
> was so kind to create a thread dump of the hanging surefire process
> [1], the relevant part is:

The way it works on the client side is that when w  write some data to 
the server we create a WriteFuture, and wait on it :

         // Send the request to the server
         WriteFuture writeFuture = ldapSession.write( modRequest );

         // Wait for the message to be sent to the server
         if ( !writeFuture.awaitUninterruptibly( getTimeout( 0 ) ) )

The client then write the request into the channel to the server, and 
when done, we notify the future while processing the MessageSent event.

Here, it seems that we never get notified. The reason not to be notified 
are limited :
- we don't see the SelectionKey as ready for Write (the socket is full)
- the Future we use to get notified has changed (very unlikely)
- the messageSent event is never fired

I would rather expect that the issue is #3, which can occurs when there 
are some remaining bytes in the buffer to send :

         if (!buf.hasRemaining() || !hasFragmentation && 
localWrittenBytes != 0) {
             // Buffer has been sent, clear the current request.
             int pos = buf.position();

             fireMessageSent(session, req);

             // And set it back to its position

We need to add some log to detect this problem; What could happen is 
that we can't send all the bytes to the server, so the buffer remains 
with pending bytes, and for some reason, we don't send them to the server.

In any case, we need to set some timeout on the client to get out of 
this blockage. The "if ( !writeFuture.awaitUninterruptibly( getTimeout( 
0 ) ) )" is not a good idea, we must replace 0 by some decent value. 
That will not solve the issue, but at least, we won't block for ever.

Emmanuel Lécharny

View raw message