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.

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.

Reply via email to