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 Fri, 11 Aug 2006 07:39:50 GMT
Kathey Marsden wrote:
> 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.
After disabling the Symantec Client Firewall Version 5.1  the test passes!

> 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. 
> Kathey

I updated https://issues.apache.org/jira/browse/DERBY-952 .

Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway

View raw message