Andrew McIntyre wrote:
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?
Thanks Andrew, for the hint!
The 'CYGWIN_NT-5.1_i686-unknown' machine (on my home network) runs
firewall sw. I'll try turning that off.
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.
('CYGWIN_NT-5.1_i686-unknown')
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.
These are on the 'CYGWIN_NT-5.2_i686-unknown' (on our lab network) - no
firewall sw.
The upgrade test should be fixed on next run....
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?
Also on our lab network, as are the other SunOS 5.9/5.10 and Linux-2.6.9
machines.
SunOS 9 / 11:
procedureInTrigger looks like a recent trigger problem, not sure why
it only shows up here.
(SunOS-5.11 on my home network)
For test machines on our lab network I build on SunOS 5.10 x86.
For machines on my home network svn update, build and test is done on
each machine.
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
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
