river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Costers <jonathan.cost...@googlemail.com>
Subject Re: Build failed in Hudson: River-trunk-QA #40
Date Mon, 01 Nov 2010 16:21:18 GMT
>From what I can see, this started at QA build #34, which was aborted.
When aborting a QA build, you will leave open resources, depending on what
was running at the time of abortion.
There is no easy way around this (that I can think of), but to avoid
aborting QA builds, especially on Hudson.
If you do, you will have to manually kill some processes or reboot.


2010/10/23 Peter Firmstone <jini@zeus.net.au>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message