db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Solberg <Ole.Solb...@Sun.COM>
Subject Re: test failures caused by firewall software? (was Re: Regression Test Failure! - Derby 430109 - Sun DBTG)
Date Thu, 10 Aug 2006 11:57:31 GMT
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, Ole.Solberg@sun.com <Ole.Solberg@sun.com> 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.

> 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 

> 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

View raw message