>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 <[email protected]> > 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. >>> >>> >> >> >
