code review request: 7162687: enhance KDC server availability detection

[Valerie (Yu-Ching) Peng]

The source changes look fine. The re-trying receive() part seems not 
useful, but if you want to be conservative, that's fine with me too.

What is the following change for?

@compile -XDignore.symbol.file MaxRetries.java

BTW, there is typo on line 43, "tp" should be "to"

>    PortUnreachableException is not available on Mac, new test won't 
> work there. 
So, what is the behavior on Mac then? Is it a different type of 
SocketException or else?

Thanks,
Valerie

On 05/18/12 03:08, Weijun Wang wrote:
> Hi Valerie
>
> Webrev updated:
>
>    http://cr.openjdk.java.net/~weijun/7162687/webrev.01/
>
> Summary:
>
> KdcComm.java and NetClient.java
>
>    1. Make NetClient AutoCloseable, use try-with-resources.
>
>    2. Add a connect() after UDP socket is created, this ensures an 
> immediate PortUnreachableException if the server is not on. When this 
> exception is seen, we won't try the same KDC again.
>
>    3. Now we have
>
>          try {
>              dgSocket.receive(dgPacketIn);
>          }
>          catch (SocketException e) {
> +            if (e instanceof PortUnreachableException) {
> +                throw e;
> +            }
>              dgSocket.receive(dgPacketIn);
>          }
>
> Here I have no idea what benefit the original code gets by retrying 
> receive(). This code has been there at the very beginning. I simply 
> add a new exception check.
>
> test/sun/security/krb5/auto/Unreachable.java
> test/sun/security/krb5/auto/unreachable.krb5.conf
>
>    New test. With PortUnreachableException, the test should finish in 
> a very short time without waiting for 3 timeouts. Hopefully no process 
> is waiting on those 3 ports I hard code.
>
> test/ProblemList.txt
>
>    PortUnreachableException is not available on Mac, new test won't 
> work there.
>
> test/sun/security/krb5/auto/BadKdc.java
> test/sun/security/krb5/auto/MaxRetries.java
>
>    Old tests need to be updated. Start a dummy DatagramSocket to 
> trigger the TimeoutException.
>
> test/sun/security/krb5/auto/TcpTimeout.java
>
>    The test checks for time elapse but quite a lot of our test 
> machines are virtual machines and Windows guests always get timing 
> wrong. Remove that check.
>
> Thanks
> Max
>
>
> On 04/19/2012 11:21 AM, Weijun Wang wrote:
>> Hi Valerie
>>
>> Please take a review at
>>
>> http://cr.openjdk.java.net/~weijun/7162687/webrev.00/
>>
>> Basically I add a connect() before send/receive and if a KDC UDP server
>> is not on, an ICMP Port Unreachable message will be received
>> immediately, and there will be no more retry on the same KDC.
>>
>> In the tests, an idle DatagramSocket must be created to avoid the ICMP
>> message being sent. I also enhance the BadKdc tests to check the new
>> behavior: When no idle DatagramSocket is created, there are no more
>> retries on the same KDC, but you can still see krb5.kdc.bad.policy 
>> working.
>>
>> Thanks
>> Max
>>
>>
>> -------- Original Message --------
>> *Change Request ID*: 7162687
>> *Synopsis*: enhance KDC server availability detection
>>
>> Product: java
>> Category: java
>> Subcategory: classes_security
>> Type: RFE
>>
>> === *Description*
>> ============================================================
>> Currently if there are multiple KDCs defined for a realm, we send UDP
>> request to each one and wait for reply, when no reply is received, we
>> retry. After several unsuccessful retries, we go on to the next KDC. The
>> timeout for the wait is normally 30 seconds. If the KDCs defined are not
>> all turned on, the time spent to finally get a response might be very
>> long. This is especially true for customers having a main KDC and
>> several slave KDCs and the main KDC is in maintenance.
>>
>> In fact, there is a better way to detect if the KDC server is on by
>> connect() to it first. In this way, an IMCP PortUnreachableException
>> will be thrown in a later send/receive method immediately. Also, when
>> this exception is thrown, we can be sure that the KDC server is off and
>> there is no need to retry this one.
>>
>> Please note that if a KDC is on but for various reasons it cannot reply
>> in a timely manner, we will still wait for the timeout and do a retry.
>>
>> *** (#1 of 1): 2012-04-19 02:56:04 GMT+00:00 weijun.wang at oracle.com
>> *** Last Edit: 2012-04-19 02:57:44 GMT+00:00 weijun.wang at oracle.com
>>