db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: test failures caused by firewall software? (was Re: Regression Test Failure! - Derby 430109 - Sun DBTG)
Date Thu, 10 Aug 2006 13:08:24 GMT
Ole Solberg wrote:

>> 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.
Just FYI,  I think there is something  not quite right with network 
server's interaction with firewall software or maybe , where one can get 
a hang even though the software is set to allow connections.   I have 
not been able to reproduce it reliably.  If you can it would be worth 
investigating.  I know Bryan expressed interest in this issue.

The history is that with  the following firewall software:

Check Point Integrity Flex version
TrueVector security engine version
Driver version

On Windows XP machine, NSInSameJVM sometimes hangs and does not pop up 
with a window requesting access, but I cannot  reproduce reliably.  
Other times, the window would pops up so I can allow access but the test 
will not proceed.

I had a user report on Windows 2003 that a simple network server/client 
program would hang with the same software.
The  ultimate resolution of this issue was that Integrity Flex was not 
supported on Windows 2003.    But, before we got to that point we saw 
that just a simple attempt to make a client connection  through ij would 
hang.  Using a small java program to just simulate the client/server 
socket interactions, I could not reproduce.

My gut feeling was that perhaps something in network server was not 
getting flushed or something else is just not quite right with the 
socket interaction in network server/client, but again never got close 
enough to a reproducible case to really track it down.

Another clue with regard to NSInSameJVM is  DERBY-589.  This is reported 
not to reproduce with jdk 1.5, but again seems to illustrate a 
fragility  of network server or NSINSameJVM that can cause a hang.

Anyway, short story, if you can reproduce this reliably, before you 
disable your firewall software take a few minutes to document how to 
reproduce this elusive problem and file a bug and  point to this thread.  


View raw message