RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

[Mark Sheppard]

It appears to be negative logic.  If it's not false then its true.
As the default value is false, would it be less ambiguous if only a 
property value of  true sets
the keepAlive variable to true?

if ((value != null) && ("true".equalsIgnoreCase(value))
      keepAlive = true;


WRT testing, should we be accessing impl classes from tests, keeping in 
mind the
desire to restrict access to the corba.impl classes in future jdk releases?
This then might force this to be a packet level test?

regards
Mark


On 03/09/2013 13:58, Chris Hegarty wrote:
> Sean,
>
> I remember discussing this (offlist) with you a while back, and I 
> agree with the proposed solution.
>
> The logic for checking the system property looks a little odd. But I 
> will admit views differ on exactly what values should be accepted. So, 
> trivially I would suggest making keepAlive final and always setting it 
> in the static initializer.
>
> Otherwise, looks fine to me.
>
> -Chris.
>
> On 09/03/2013 01:04 PM, Seán Coffey wrote:
>> Sockets created by the
>> com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be
>> affected by firewalls if that connection is left idle for long periods
>> of time. (closed out). A workaround for such an issue could be to have a
>> simple corba thread send some simple ping traffic on the socket at
>> scheduled intervals. That may not be possible for legacy applications.
>>
>> Proposed solution is to add an implementation specific system property
>> flag which would have the keepAlive feature turned on for sockets
>> returned by the CORBA DefaultSocketFactoryImpl class. The application is
>> then in a better position to manage the keepAlive settings via the OS.
>> This had been fixed in Java SE 6 and I'm looking to port the new
>> property to jdk7u & jdk8.
>>
>> http://cr.openjdk.java.net/~coffeys/webrev.8017195/
>>
>> regards,
>> Sean.