On 6/27/13 4:58 PM, Brad Wetmore wrote:
Chris (and Michael),
As my part of the "intermittently failing test cleanup," I'm looking into a
test of yours that has been intermittently failing.
It's bug:
https://jbs.oracle.com/bugs/browse/JDK-8017333
The open URL to view this bug is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333
which is failing the regression test you added for:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65
You used a really old version of the test framework (pre-2003!) which doesn't
output both the client and server exceptions. I've updated the test to use the
new framework, and would like to put this back as a temporary measure so we can
see what is really happening from any possible swallowed exceptions.
Xuelei/I are stumped as to what might be happening, so hopefully this action
will give some clarity.
8019341: Update CookieHttpsClientTest to use the newer framework.
http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/
Improving the exception handling seems mostly reasonable.
It looks like startServer() and startClient() now both try to catch any
exceptions and store them in variables for later processing. But they still are
declared to throw Exception, and the code that calls them from the constructor
throws away any exception that's caught there. Hm, it's hard to know what
exception might be caught at that point, but since we don't really know what's
going on, we probably shouldn't rule anything out.
Most places catch Exception. One possibility to consider is whether an Error of
some type might be thrown, which isn't caught by "catch (Exception)" clauses.
In the place where you potentially have two exceptions to report, you might
consider using the suppressed exception mechanism. This is bending the
semantics a bit, but if the client is subordinate to the server (or vice versa)
and both throw exceptions, only one can be propagated, so it could seem
somewhat proper to consider one exception to have suppressed the other.
It would be easiest to compare your test to the
test/sun/security/ssl/templates/SSLSocketTemplate.java. They should be the
same except for your test-specific code.
Hm, a template-based framework? Might be worth investigating turning this into
a library at some point.
Brad
P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;)
Yes, indeed. :-)
s'marks
