river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Build failed in Hudson: River-trunk-QA #40
Date Sat, 23 Oct 2010 00:10:45 GMT
I think what happens is, the socket isn't closed during teardown of one 
test, it's still in use when the next test is set up.  So it only takes 
one tests to cause the socket problem, the remaining tests then have the 
same error.

 From memory anyway.  When it happens locally, I cancel the test run, 
kill the processes and try again.  One would think that after a failed 
qa test run Hudson would clean up all remaining processes, but I don't 
know exactly.

Regards,

Peter.

Patricia Shanahan wrote:
> On 10/21/2010 8:58 PM, Peter Firmstone wrote:
>> Patricia Shanahan wrote:
>>> On 10/21/2010 7:37 AM, Apache Hudson Server wrote:
>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA/40/changes>
>>>>
>>>> Changes:
>>>>
>>>> [pats] RIVER-361: Tidy up GetStateTest. Set a ten minute limit on
>>>> final spin loop, require the aborted transaction to stay aborted, and
>>>> specifically require the UnknownTransactionException.
>>>>
>>>> [pats] RIVER-361: Make TxnManagerImpl conform to TransactionManager
>>>> interface by only throwing CannotAbortException for an attempt to
>>>> abort a COMMITTED transaction. The change lets retries of aborts
>>>> work, so GetStateTest passes.
>>>>
>>> ...
>>>> [copy] Copying 1 file
>>>> to<https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/result>

>>>>
>>>>
>>>> [copy] Copying 1 file
>>>> to<https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/result>

>>>>
>>>>
>>>> [zip] Building
>>>> zip:<https://hudson.apache.org/hudson/job/River-trunk-QA/40/artifact/jtsk/trunk/qa/result/qaresults-i386-Linux-1.6.0_20.zip>

>>>>
>>>>
>>>>
>>>> BUILD FAILED
>>>> <https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/build.xml>:2038:

>>>>
>>>> The following error occurred while executing this line:
>>>> <https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/build.xml>:326:

>>>>
>>>> The following error occurred while executing this line:
>>>> <https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/build.xml>:300:

>>>>
>>>> condition satisfied
>>>
>>> What's the etiquette on who tracks down Hudson failures? My
>>> fingerprints are on the last changes, but the failures do not seem to
>>> be particularly related to them, and both tests pass on one of my
>>> Ubuntu VirtualBoxes.
>>>
>>> Both the failures seem to relate to socket binding:
>>>
>>> Caused by: java.net.BindException: Address already in use
>>> at java.net.PlainSocketImpl.socketBind(Native Method)
>>> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
>>> at java.net.ServerSocket.bind(ServerSocket.java:319)
>>> at java.net.ServerSocket.<init>(ServerSocket.java:185)
>>> at java.net.ServerSocket.<init>(ServerSocket.java:97)
>>> at
>>> javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:157)

>>>
>>>
>>> at com.sun.jini.reggie.RegistrarImpl$UnicastThread.<init>(Unknown 
>>> Source)
>>> at com.sun.jini.reggie.RegistrarImpl.init(Unknown Source)
>>> at com.sun.jini.reggie.RegistrarImpl.access$000(Unknown Source)
>>> at com.sun.jini.reggie.RegistrarImpl$1.run(Unknown Source)
>>> at com.sun.jini.reggie.RegistrarImpl.<init>(Unknown Source)
>>> at com.sun.jini.reggie.TransientRegistrarImpl.<init>(Unknown Source)
>>>
>>> (https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/result/com_sun_jini_test_impl_discoverymanager_RemoveGroupsLocsDiscard.td.txt)

>>>
>>>
>>>
>>> Caused by: java.net.BindException: Address already in use
>>> at java.net.PlainSocketImpl.socketBind(Native Method)
>>> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
>>> at java.net.ServerSocket.bind(ServerSocket.java:319)
>>> at java.net.ServerSocket.<init>(ServerSocket.java:185)
>>> at java.net.ServerSocket.<init>(ServerSocket.java:97)
>>> at com.sun.jini.tool.ClassServer.init(Unknown Source)
>>> at com.sun.jini.tool.ClassServer.<init>(Unknown Source)
>>>
>>>
>>> (https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/result/com_sun_jini_test_spec_lookupdiscovery_RemoveGroupsRemoveAll.td.txt)

>>>
>>>
>>>
>>>
>>> Patricia
>>>
>>
>> I get that error from time to time, I make note of the processes running
>> before and after testing and kill any stale processes. Treads will block
>> waiting for a socket if it hasn't been closed.
>
> Shouldn't Hudson start each test sequence clean?
>
>> I wonder if we can implement a lease-able Socket, with a new
>> SocketFactory, then if the lease expires, close it, activity could
>> automatically refresh the lease.
>>
>> An alternative might be a register of sockets in a SocketManager, you
>> register and lease your socket. If you don't renew the lease, the socket
>> manager closes the socket.
>>
>> Cheers,
>>
>> Peter.
>>
>
>


Mime
View raw message