jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows

[Stuart Marks]

On 1/7/13 3:23 AM, Jaroslav Bachorik wrote:
> On 01/04/2013 11:37 PM, Kelly O'Hair wrote:
>> I suspect it is not hanging because it does not exist, but that some other windows process has it's hands on it.
>> This is the stdout file from the server being started up right?
>> Could the server from a previous test run be still running?
>
> Exactly. Amy confirmed this and provided a patch which resolves the
> hanging problem.
>
> The update patch is at
> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.01

Hi Jaroslav,

The change to remove the parentheses from around the server program looks 
right. It avoids forking an extra process (at least in some shells) and lets $! 
refer to the actual JVM, not an intermediate shell process. The rm -f from 
Kelly's suggestion is good too.

But there are other things wrong with the script. I don't think they could 
cause hanging, but they could cause the script to fail in unforeseen ways, or 
even to report success incorrectly.

One problem is introduced by the change, where the Server's stderr is also 
redirected into $URL_PATH along with stdout. This means that if the Server 
program reports any errors, they'll get mixed into the URL_PATH file instead of 
appearing in the test log. The URL_PATH file's contents is never reported, so 
these error messages will be invisible.

The exit status of some of the critical commands (such as the compilations) 
isn't checked, so if javac fails for some reason, the test might not report 
failure. Instead, some weird error might or might not be reported later (though 
one will still see the javac errors in the log).

I don't think the sleep at line 80 is necessary, since the client runs 
synchronously and should have exited by this point.

The wait loop checking for the existence of the URL_PATH file doesn't actually 
guarantee that the server is running or has initialized yet. The file is 
actually created by the shell before the Server JVM starts up. Thus, runClient 
might try to read from it before the server has written anything to it. Or, as 
mentioned above, the server might have written some error messages into the 
URL_PATH file instead of the expected contents. Thus, the contents of the 
JMXURL variable can quite possibly be incorrect.

If this occurs, what will happen when the client runs? It may emit some error 
message, and this will be filtered out by the grep pipeline. Thus, HAS_ERRORS 
might end up empty, and the test will report passing, even though everything 
has failed!

For this changeset I'd recommend at a minimum removing the redirection of 
stderr to URL_PATH. If the server fails we'll at least see errors in the test log.

For checking the notification message, is there a way to modify the client to 
report an exit status or throw an exception? Throwing an exception from main() 
will exit the JVM with a nonzero status, so this can be checked more easily 
from the script. I think this is less error-prone than grepping the output for 
a specific error message. The test should fail if there is *any* error; it 
should not succeed if an expected error is absent.

You might consider having jtreg build the client and server classes. This might 
simplify some of the setup. Also, jtreg is meticulous about aborting the test 
if any compilations fail, so it takes care of that for you.

It would be nice if there were a better way to have the client rendezvous with 
the server. I hate to suggest it, but sleeping unconditionally after starting 
the server is probably necessary. Anything more robust probably requires 
rearchitecting the test, though.

Sorry to dump all this on you. But one of the shell-based RMI tests suffers 
from *exactly* the same pathologies. (I have yet to fix it.) Unfortunately, I 
believe that there are a lot of other shell-based tests in the test suite that 
have similar problems. The lesson here is that writing reliable shell tests is 
a lot harder than it seems.

Thanks,

s'marks