Re: Do not JDK-6967684 backport to JDK6?
Don’t have an answer this but CC-ing openjdk6-dev Ivan On 23 Jun 2014, at 07:03, KUBOTA Yuji wrote: > Hi all, > > I got ArrayIndexOutOfBoundsException at java.text.SimpleDateFormat.subFormat > via sun.net.httpserver.ExchangeImpl when I used com.sun.net.httpserver > with OpenJDK6 as the tail of this mail. > > The reason why this exception occured is that httpserver (ExchangeImpl) uses > a non thread-safe SimpleDateFormat which has been modified at OpenJDK7 > by JDK-6967684. > > Bug database: http://bugs.java.com/view_bug.do?bug_id=6967684 > Patch: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1371a2d5f3a8 > ML: http://mail.openjdk.java.net/pipermail/net-dev/2010-July/001946.html > > > And the HEAD of jdk6 repos do not include this patch. > If anyone knows why this patch do not backport to OpenJDK6, please tell me. > > --Exception details--- > # java -version > java version "1.6.0_28" > OpenJDK Runtime Environment (IcedTea6 1.13.0pre) > (rhel-1.66.1.13.0.el6-x86_64) OpenJDK 64-Bit Server VM (build 23.25-b01, > mixed mode) > > # stack trace > java.lang.ArrayIndexOutOfBoundsException: -2147483648 > java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1066) > java.text.SimpleDateFormat.format(SimpleDateFormat.java:899) > java.text.SimpleDateFormat.format(SimpleDateFormat.java:869) > java.text.DateFormat.format(DateFormat.java:333) > sun.net.httpserver.ExchangeImpl.sendResponseHeaders(ExchangeImpl.java:206) > sun.net.httpserver.HttpExchangeImpl.sendResponseHeaders(HttpExchangeImpl.java:86) > com.sun.xml.internal.ws.transport.http.server.ServerConnectionImpl.getOutput(ServerConnectionImpl.java:145) > com.sun.xml.internal.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:321) > com.sun.xml.internal.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:82) > com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:470) > com.sun.xml.internal.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:233) > com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:95) > com.sun.xml.internal.ws.transport.http.server.WSHttpHandler$HttpHandlerRunnable.run(WSHttpHandler.java:117) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > java.lang.Thread.run(Thread.java:679) > -- > > Thanks in advance for your help! > > Best regards, > KUBOTA Yuji. >
Re: RFR 8049220: URL.factory data race
On Jul 3, 2014, at 6:33 PM, Alan Bateman wrote: > On 03/07/2014 09:43, Peter Levart wrote: >> Hi, >> >> I noticed a data race in java.net.URL: >> >>https://bugs.openjdk.java.net/browse/JDK-8049220 >> >> I propose the following simple patch: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ >> > A good catch and the change looks good to me. Yes, well spotted. May i suggest that the following comment is updated: 1109 factory = fac; // volatile write to say something about ensuring safe publication of a constructed handle? since it is often quite tricky to reason about why a volatile write is needed (to stamp in, at least, a StoreStore barrier). For JMM v9 we may not need to mark such a ref as volatile. > I assume it just wasn't noticed because it can only be set once and probably > rared used too. > Yeah, i wonder whether it would ever get optimized/inlined to the point at which re-ordering could practically happen. Paul. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFR: 8048212 Two tests failed with "java.net.SocketException: Bad protocol option" on Windows after 8029607
On 30/06/14 19:43, Alan Bateman wrote: On 30/06/2014 17:53, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8048212/webrev.1/ It fixes a problem caused by the fix for 8029607. The changes for that fix should not have been applied to Windows. So, this fix ensures that the IPv4 option is used always on Windows. I don't know if Windows supports setting IP_TOS on an IPv6 socket but in any case, it might be simplest to just go back to the original behavior which was for this case to be a no-op. The spec allows for that. -Alan Sorry for the delay in getting back to this. The following is a simpler change that restores the original NIO behavior on Windows http://cr.openjdk.java.net/~michaelm/8048212/webrev.2/ Michael
Re: RFR: 8048212 Two tests failed with "java.net.SocketException: Bad protocol option" on Windows after 8029607
On 04/07/2014 19:33, Michael McMahon wrote: Sorry for the delay in getting back to this. The following is a simpler change that restores the original NIO behavior on Windows http://cr.openjdk.java.net/~michaelm/8048212/webrev.2/ Yes, this much simpler. A minor nit is that L300 in Net.c should probably also check that the level is IPPROTO_IPV6. The comment could be updated too. -Alan
