Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: Chris, I'm not sure immediate native retry make sence here because tipically EAGAIN of getaddrinfo caused by network failure, like unreachable nameserver. (see my previous letter) OK, while not ideal ( please don't shoot! ) what do others think of Thread.yield() before retry. It is an attempt to allow other threads on the system do some work before us, therefore potentially swapping out our failed lookup thread until rescheduled. I'm just trying to avoid baking in a hardcoded sleep/wait value ( since we don't know what that should be ). The use of Thread.yield(), if acceptable, would of course most likely make sense to push the retry logic back up into the Java level. -Chris. -Dmitry On 2013-10-02 23:53, Chris Hegarty wrote: On 10/02/2013 08:40 PM, Brian Burkhalter wrote: So, how about this approach: 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. Sounds good to me. Questions: A) Would it be better to do the retry in the Java layer, perhaps with a very short wait? native, without any wait, should be sufficient. B) Should the message or cause in #2 be explicitly document in the javadoc? I don't think it is necessary for this to be documented. It is more informational. -Chris.
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Chris, On my opinion, it's better to just return meaningful exception to customer and let them deal with network issue (as current webrev does). Typical network failure requires at least couple of milliseconds to recover so immediate retry most probably fails with the same error. >From the other side - cu has lots of possibility to defend against such failures on application level. E.g. popup a message box "please check your wiring and try again" In a future, it might be possible to add a timeout parameter to corresponding Java-level functions and keep trying on Java level until we get result or timeout, but it requires much more work and probably out of scope of this CR. -Dmitry On 2013-10-03 13:11, Chris Hegarty wrote: > On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: >> Chris, >> >> I'm not sure immediate native retry make sence here because tipically >> EAGAIN of getaddrinfo caused by network failure, like unreachable >> nameserver. (see my previous letter) > > OK, while not ideal ( please don't shoot! ) what do others think of > Thread.yield() before retry. It is an attempt to allow other threads on > the system do some work before us, therefore potentially swapping out > our failed lookup thread until rescheduled. I'm just trying to avoid > baking in a hardcoded sleep/wait value ( since we don't know what that > should be ). > > The use of Thread.yield(), if acceptable, would of course most likely > make sense to push the retry logic back up into the Java level. > > -Chris. > >> >> -Dmitry >> >> On 2013-10-02 23:53, Chris Hegarty wrote: >>> On 10/02/2013 08:40 PM, Brian Burkhalter wrote: So, how about this approach: 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. >>> >>> Sounds good to me. >>> Questions: A) Would it be better to do the retry in the Java layer, perhaps with a very short wait? >>> >>> native, without any wait, should be sufficient. >>> B) Should the message or cause in #2 be explicitly document in the javadoc? >>> >>> I don't think it is necessary for this to be documented. It is more >>> informational. >>> >>> -Chris. >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code.
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Thanks Dmitry, I think we have agreement that the cause of the UHE should contain an Exception containing the gai_strerror string message. I can live without adding retry logic. -Chris. On 10/03/2013 10:44 AM, Dmitry Samersoff wrote: Chris, On my opinion, it's better to just return meaningful exception to customer and let them deal with network issue (as current webrev does). Typical network failure requires at least couple of milliseconds to recover so immediate retry most probably fails with the same error. From the other side - cu has lots of possibility to defend against such failures on application level. E.g. popup a message box "please check your wiring and try again" In a future, it might be possible to add a timeout parameter to corresponding Java-level functions and keep trying on Java level until we get result or timeout, but it requires much more work and probably out of scope of this CR. -Dmitry On 2013-10-03 13:11, Chris Hegarty wrote: On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: Chris, I'm not sure immediate native retry make sence here because tipically EAGAIN of getaddrinfo caused by network failure, like unreachable nameserver. (see my previous letter) OK, while not ideal ( please don't shoot! ) what do others think of Thread.yield() before retry. It is an attempt to allow other threads on the system do some work before us, therefore potentially swapping out our failed lookup thread until rescheduled. I'm just trying to avoid baking in a hardcoded sleep/wait value ( since we don't know what that should be ). The use of Thread.yield(), if acceptable, would of course most likely make sense to push the retry logic back up into the Java level. -Chris. -Dmitry On 2013-10-02 23:53, Chris Hegarty wrote: On 10/02/2013 08:40 PM, Brian Burkhalter wrote: So, how about this approach: 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. Sounds good to me. Questions: A) Would it be better to do the retry in the Java layer, perhaps with a very short wait? native, without any wait, should be sufficient. B) Should the message or cause in #2 be explicitly document in the javadoc? I don't think it is necessary for this to be documented. It is more informational. -Chris.
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Chris, On 2013-10-03 14:10, Chris Hegarty wrote: > Thanks Dmitry, > > I think we have agreement that the cause of the UHE should contain an > Exception containing the gai_strerror string message. I can live without > adding retry logic. I'm ok with that. -Dmitry > > -Chris. > > On 10/03/2013 10:44 AM, Dmitry Samersoff wrote: >> Chris, >> >> On my opinion, it's better to just return meaningful exception to >> customer and let them deal with network issue (as current webrev does). >> >> Typical network failure requires at least couple of milliseconds to >> recover so immediate retry most probably fails with the same error. >> >> From the other side - cu has lots of possibility to defend against such >> failures on application level. E.g. popup a message box "please check >> your wiring and try again" >> >> In a future, >> >> it might be possible to add a timeout parameter to corresponding >> Java-level functions and keep trying on Java level until we get result >> or timeout, but it requires much more work and probably out of scope of >> this CR. >> >> -Dmitry >> >> >> On 2013-10-03 13:11, Chris Hegarty wrote: >>> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: Chris, I'm not sure immediate native retry make sence here because tipically EAGAIN of getaddrinfo caused by network failure, like unreachable nameserver. (see my previous letter) >>> >>> OK, while not ideal ( please don't shoot! ) what do others think of >>> Thread.yield() before retry. It is an attempt to allow other threads on >>> the system do some work before us, therefore potentially swapping out >>> our failed lookup thread until rescheduled. I'm just trying to avoid >>> baking in a hardcoded sleep/wait value ( since we don't know what that >>> should be ). >>> >>> The use of Thread.yield(), if acceptable, would of course most likely >>> make sense to push the retry logic back up into the Java level. >>> >>> -Chris. >>> -Dmitry On 2013-10-02 23:53, Chris Hegarty wrote: > On 10/02/2013 08:40 PM, Brian Burkhalter wrote: >> >> So, how about this approach: >> >> 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then >> do one immediate native retry. >> 2) If the retry fails with the same error, then throw a UHE with a >> specific message or cause. > > Sounds good to me. > >> Questions: >> >> A) Would it be better to do the retry in the Java layer, perhaps with >> a very short wait? > > native, without any wait, should be sufficient. > >> B) Should the message or cause in #2 be explicitly document in the >> javadoc? > > I don't think it is necessary for this to be documented. It is more > informational. > > -Chris. >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 811c35a6a58f Author:psandoz Date: 2013-10-02 16:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c35a6a58f 8025534: Unsafe typecast in java.util.stream.Streams.Nodes 8025538: Unsafe typecast in java.util.stream.SpinedBuffer 8025533: Unsafe typecast in java.util.stream.Streams.RangeIntSpliterator.splitPoint() 8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray() Reviewed-by: chegar ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Streams.java Changeset: c55a7941050c Author:psandoz Date: 2013-10-03 10:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a7941050c 8025567: Mark relevant public stream tests as serialization hostile Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java
hg: jdk8/tl/jdk: 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1
Changeset: 5d6dc0cba08f Author:dsamersoff Date: 2013-10-03 16:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d6dc0cba08f 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 01b8604e8268 Author:rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contributed-by: paul.r...@oracle.com ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/serial/TCKDuration.java + test/java/time/tck/java/time/serial/TCKInstant.java + test/java/time/tck/java/time/serial/TCKLocalDate.java + test/java/time/tck/java/time/serial/TCKLocalDateTime.java + test/java/time/tck/java/time/serial/TCKLocalTime.java + test/java/time/tck/java/time/serial/TCKMonthDay.java + test/java/time/tck/java/time/serial/TCKOffsetDateTime.java + test/java/time/tck/java/time/serial/TCKOffsetTime.java + test/java/time/tck/java/time/serial/TCKPeriod.java + test/java/time/tck/java/time/serial/TCKYear.java + test/java/time/tck/java/time/serial/TCKYearMonth.java + test/java/time/tck/java/time/serial/TCKZoneId.java + test/java/time/tck/java/time/serial/TCKZoneOffset.java + test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/serial/TCKZoneRules.java Changeset: e813b58bd6db Author:rriggs Date: 2013-10-03 15:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e813b58bd6db 8024427: Missing java.time.chrono serialization tests Summary: Add tests and cleanup existing serialization tests Reviewed-by: sherman ! src/share/classes/java/time/temporal/ValueRange.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java + test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java + test/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java < test/java/time/tck/java/time/serial/TCKDuration.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java < test/java/time/tck/java/time/serial/TCKInstant.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDate.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDateTime.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java < test/java/time/tck/java/time/serial
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Brian,
On 3/10/2013 5:40 AM, Brian Burkhalter wrote:
I agree that is an ugly style but it guarantees that mistakes such as
if (error = EAI_AGAIN) {}
are caught at compilation time.
True but as I understand it this is not the preferred/common style in
the JDK code.
David
hg: jdk8/tl/langtools: 8025118: Annotation processing api returns default modifier for interface without default methods
Changeset: c13305cf8528 Author:jlahoda Date: 2013-10-04 08:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestTypeElement.java
