Failures in these tests have been arriving ever since these test
results started being sent to this list. Synapses connected with
regard to a recent problem I had running tests on a specific machine.
So, I'm wondering...
On 8/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[Auto-generated mail]
</snip lots of different results on different machines>
I recently had some problems running some tests on a machine due to
overaggressive firewall software on that machine. Considering that
these mails involve tests running on different operating systems
presumably running on different machines, and that a lot of them
involve access to network resources, is there a possibility that the
differences in these test runs are due to various firewall or network
access controls on these machines?
e.g., in the JDK 1.4 runs above, the Linux tests pass completely,
while there are two failures in the Cygwin environment:
a) derbynetmats/NSinSameJVM.diff, failure is "FAIL Network Server did not start"
or, is it not reachable because of overaggressive firewall software on
the machine preventing access?
b) derbynetmats/DerbyNet/multi/stress.diff
No clear idea on this one, maybe failure to communicate to the client
threads that they should shut down?
For the 1.4 SunOS tests in the same run, 9 errors in derbynetmats, do
we need to grant permissions in our policy file for db2jcc.jar? e.g.
java.net.SocketPermission read,write? Or are the ports used by the
tests being blocked at the OS level? This error makes me especially
suspicious:
Could not access database through the network server.
java.net.ConnectException : Error opening socket to server
xxxFILTERED_HOSTNAMExxx on port 31415 with message : Connection refused
6 del
refused why?
Now, the 1.5 tests:
Cygwin:
NSinSameJVM, same as above.
dcl/encryption_key/encryptDatabaseTest3, overaggressive firewall
software blocking URLs with subsubsubprotocols, maybe? The problem in
each of these cases is with URLs starting with 'jdbc:derby:jar' or
'jdbc:derby:classpath'.
upgradeTest, I think the property that points to the older Derby jars
is not being passed in properly.
SunOS 10-x86:
derbynetmats/ShutDownDBWhenNSShutsDownTest.junit, communication blocked
derbynetmats/sysinfo_withproperties.java, test policy problem?
permissions not granted to db2jcc.jar in test policy?
derbynetmats/testconnection.java, communication blocked
derbynetclientmats/parameterMapping.java, communication blocked
derbynetclientmats/xaSimplePositive.java, not sure about this one, but
it looks like the first real read from on the client side, maybe
communication blocked on the client end?
SunOS 9 / 11:
procedureInTrigger looks like a recent trigger problem, not sure why
it only shows up here.
It would be great if we could figure out why we constantly get these
reminders of why these tests only fail in these specific environments,
despite efforts to reproduce them in similar environments elsewhere.
HTH,
andrew
