code review request: 7162687: enhance KDC server availability detection
Valerie (Yu-Ching) Peng
valerie.peng at oracle.com
Wed May 23 01:25:13 UTC 2012
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
>>
More information about the security-dev
mailing list