On 10-11-12 00:07, Peter Firmstone wrote:
tried developing experimental code directly in trunk unsuccessfully. I
think we need to clarify our development processes.
Lightweight.
Only commit code that compiles.
(s)he who breaks the build fixes the build. idem testing.
No jumbo patches. No
On 10-11-12 11:32, peter_firmst...@apache.org wrote:
Author: peter_firmstone
Date: Sat Nov 10 10:32:46 2012
New Revision: 1407747
URL: http://svn.apache.org/viewvc?rev=1407747view=rev
Log:
Enable Reggie to handle a ServerSocket caught in the 4 minute TCP 2MSL
TIME_WAIT state, can be safely
See https://builds.apache.org/job/River-QA-ubuntu-jdk7/58/changes
Changes:
[sijskes] private constructor
[sijskes] javadoc.
[peter_firmstone] Fix new recent test failures
[peter_firmstone] Fix new recent test failures
[peter_firmstone] Fix NullPointerException bug revealed by MS Windows
On 10-11-12 12:51, Peter Firmstone wrote:
Why did you not use ServerSocket.setReuseAddress(true)?
1. It's platform dependent and causes issues on windows platforms.
Bold statement. Which issues?
On 10-11-12 12:51, Peter Firmstone wrote:
Why did you not use ServerSocket.setReuseAddress(true)?
3. You can't reconnect to the same remote TCP IP address during the
TIME_WAIT period.
Which caveat are you refering to? TIME_WAIT? You mean at the client
side? Shouldnt the client get
See https://builds.apache.org/job/River-QA-windows/63/changes
Changes:
[sijskes] private constructor
--
[...truncated 8818 lines...]
[java] Test Passed: OK
[java]
[java] -
[java]
Simon IJskes - QCG wrote:
On 10-11-12 12:51, Peter Firmstone wrote:
Why did you not use ServerSocket.setReuseAddress(true)?
3. You can't reconnect to the same remote TCP IP address during the
TIME_WAIT period.
Which caveat are you refering to? TIME_WAIT? You mean at the client
On 10-11-12 21:53, Peter Firmstone wrote:
It's set to true for most Unix platforms, as far as I'm aware. If the
client side remotely closes the ServerSocket, then there's no TIME_WAIT
period, it's only when the ServerSocket is closed by the server.
I'm kinda stretched for time right now, I'll
I'm trying to solve failures on the ARM platform, for now I've changed the Reggie ServerSocket to wait for 4 minutes for the
TCP TIME_WAIT period then retry, unfortunately the port is still in use after waiting, which tends to indicate a stale process.
Reggie works in other tests, at least
Simon IJskes - QCG wrote:
On 10-11-12 21:53, Peter Firmstone wrote:
It's set to true for most Unix platforms, as far as I'm aware. If the
client side remotely closes the ServerSocket, then there's no TIME_WAIT
period, it's only when the ServerSocket is closed by the server.
I'm kinda stretched
Ubuntu x64 JDK6 is passing.
Solaris sparc JDK6 is passing.
Ubuntu x64 JDK7 one test failure:
[java] -
[java] com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td
[java] Test Failed: Test Failed:
On 10-11-12 22:41, Peter Firmstone wrote:
I'm trying to solve failures on the ARM platform, for now I've changed
the Reggie ServerSocket to wait for 4 minutes for the TCP TIME_WAIT
period then retry, unfortunately the port is still in use after waiting,
which tends to indicate a stale process.
12 matches
Mail list logo
