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.
