Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
On 7/2/2013 8:29 PM, Xuelei Fan wrote: On 7/3/2013 8:30 AM, Brad Wetmore wrote: http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/ 261 // If both failed, return the curthread's exception. 262 local.initCause(remote); The mix the initial cause of the exception would make it hard to parse the real cause of a exception. I would like to dump both exception in the log so that we would know both exceptions in client and server. An exception can have both an init cause and one or more suppressed exceptions: Exception in thread main java.lang.Exception: Main block at Foo3.main(Foo3.java:7) Suppressed: Resource$CloseFailException: Resource ID = 2 at Resource.close(Resource.java:26) at Foo3.main(Foo3.java:5) Suppressed: Resource$CloseFailException: Resource ID = 1 at Resource.close(Resource.java:26) at Foo3.main(Foo3.java:5) Caused by: java.lang.Exception: I did it at Foo3.main(Foo3.java:8) This is a very contrived example, but you'll see something that looks like this: [brwetmor@flicker-vm1] 319 java SSLSocketTemplate Server died... Exception in thread main java.lang.Exception: My client died... at SSLSocketTemplate.doClientSide(SSLSocketTemplate.java:127) at SSLSocketTemplate.startClient(SSLSocketTemplate.java:310) at SSLSocketTemplate.init(SSLSocketTemplate.java:191) at SSLSocketTemplate.main(SSLSocketTemplate.java:175) Suppressed: java.lang.Exception: Some kind of other problem at SSLSocketTemplate.init(SSLSocketTemplate.java:199) ... 1 more Caused by: java.lang.Exception: Server problem at SSLSocketTemplate$1.run(SSLSocketTemplate.java:266) Thanks, Brad
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
Good. :-) Learn something new today. Thanks! Xuelei On 7/6/2013 9:18 AM, Brad Wetmore wrote: On 7/2/2013 8:29 PM, Xuelei Fan wrote: On 7/3/2013 8:30 AM, Brad Wetmore wrote: http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/ 261 // If both failed, return the curthread's exception. 262 local.initCause(remote); The mix the initial cause of the exception would make it hard to parse the real cause of a exception. I would like to dump both exception in the log so that we would know both exceptions in client and server. An exception can have both an init cause and one or more suppressed exceptions: Exception in thread main java.lang.Exception: Main block at Foo3.main(Foo3.java:7) Suppressed: Resource$CloseFailException: Resource ID = 2 at Resource.close(Resource.java:26) at Foo3.main(Foo3.java:5) Suppressed: Resource$CloseFailException: Resource ID = 1 at Resource.close(Resource.java:26) at Foo3.main(Foo3.java:5) Caused by: java.lang.Exception: I did it at Foo3.main(Foo3.java:8) This is a very contrived example, but you'll see something that looks like this: [brwetmor@flicker-vm1] 319 java SSLSocketTemplate Server died... Exception in thread main java.lang.Exception: My client died... at SSLSocketTemplate.doClientSide(SSLSocketTemplate.java:127) at SSLSocketTemplate.startClient(SSLSocketTemplate.java:310) at SSLSocketTemplate.init(SSLSocketTemplate.java:191) at SSLSocketTemplate.main(SSLSocketTemplate.java:175) Suppressed: java.lang.Exception: Some kind of other problem at SSLSocketTemplate.init(SSLSocketTemplate.java:199) ... 1 more Caused by: java.lang.Exception: Server problem at SSLSocketTemplate$1.run(SSLSocketTemplate.java:266) Thanks, Brad
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
Michael wrote:
I'd agree with this. If the exception is being swallowed now, how
will we know when the test fails?
The peer thread saves off any Exceptions into {server,client}Exception
volatile variable, which is then examined by the main thread at the end,
and the stacktrace would be sent to System.out in the case of both the
client/server throwing an exception. Stuart pointed where exceptions
were truly being swallowed when the threads are being created, and I've
updated the webrev to address that.
Also, I don't see where the change is invoking the newer framework? Am I
looking
at the right webrev?
Sorry, I used the word framework when I should have used template.
JSSE has a test template that I wrote back in the unbundled 1.0.3 days
(2004) because we needed to do client/server-side testing, and we were
always spending too much time getting the details worked out. So I made
a general template that most of the tests now use. Most of the time
only the top half of the test needs modification, but there are
occasions where the initialization needs tweaking.
It could be made into a framework/library. I've filed:
JDK-8019776: Make the JSSE Test Templates into a library
There was no initCause/Suppressed back in those days, but those are good
additions to add now. We got the same debug info by printing the stack
trace of any secondary exceptions.
Stuart wrote:
The open URL to view this bug is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333
Whoops, my apologies.
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.
Good point, I'll capture that and add it as either the root cause, the
init cause, or a suppressed exception (depending on what others there
are to report), both here and in SSLSocketTemplate and friends.
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.
I believe we talked about that in earlier versions of the template. If
there's an Error, that's a more serious problem and nothing should be
trusted coming out. I would think the jtreg framework will output Errors.
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.
Sounds good. I think I'd go with the initCause for peerException, and
add a suppressed exception if there is an additional exception (unlikely).
New webrev under:
http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/
Brad
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
On 28/06/13 02:38, Stuart Marks wrote: 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. I'd agree with this. If the exception is being swallowed now, how will we know when the test fails? Also, I don't see where the change is invoking the newer framework? Am I looking at the right webrev? Michael 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
RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
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 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/ 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. Brad P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;)
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
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
