On 05/23/2012 09:25 AM, Valerie (Yu-Ching) Peng wrote:
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
With this line, the compile won't show so many warnings on sun.* class
reference. It's not really necessary, but I want to jtr to be cleaner.
BTW, there is typo on line 43, "tp" should be "to"
Oh.
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?
On Mac, connect() does not call the native connect so PUE is not thrown.
It simply waits until a SocketTimeoutException is thrown. The reason is
7122794.
Thanks
Max
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 [email protected]
*** Last Edit: 2012-04-19 02:57:44 GMT+00:00 [email protected]
