From gnu.andrew at redhat.com Wed Dec 3 15:55:36 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Dec 2014 10:55:36 -0500 (EST) Subject: [PATCH] 6647452: Remove obfuscation, framework and provider self-verification checking In-Reply-To: <5476E79C.6050003@redhat.com> References: <1643270532.10151994.1417038573036.JavaMail.zimbra@redhat.com> <5476E79C.6050003@redhat.com> Message-ID: <314330018.12675659.1417622136852.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 26/11/14 21:49, Andrew Hughes wrote: > > As it's basically removing a no-op, this shouldn't actually change > > anything much, but will make other planned backports easier and > > perhaps help performance very slightly in removing some completely > > unnecessary method calls. > > Ah, thanks. I was thinking "Why on Earth does he want to change > this code now?" but I accept the argument about backports. > > Andrew. > > So, is this ok to push? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Wed Dec 3 16:02:03 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Dec 2014 16:02:03 +0000 Subject: [PATCH] 6647452: Remove obfuscation, framework and provider self-verification checking In-Reply-To: <314330018.12675659.1417622136852.JavaMail.zimbra@redhat.com> References: <1643270532.10151994.1417038573036.JavaMail.zimbra@redhat.com> <5476E79C.6050003@redhat.com> <314330018.12675659.1417622136852.JavaMail.zimbra@redhat.com> Message-ID: <547F33FB.1020709@redhat.com> On 12/03/2014 03:55 PM, Andrew Hughes wrote: > So, is this ok to push? Sure. Andrew. From gnu.andrew at redhat.com Wed Dec 3 16:03:55 2014 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 03 Dec 2014 16:03:55 +0000 Subject: hg: jdk6/jdk6/jdk: 6647452: Remove obfuscation, framework and provider self-verification checking Message-ID: <201412031603.sB3G3t4A007563@aojmv0008> Changeset: 98e143b44620 Author: wetmore Date: 2014-11-26 21:15 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/98e143b44620 6647452: Remove obfuscation, framework and provider self-verification checking Summary: Backported by gnu.andrew at redhat.com Reviewed-by: valeriep, vinnie ! make/com/sun/crypto/provider/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESCipher.java ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SslMacCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/javax/crypto/JarVerifier.java ! src/share/classes/javax/crypto/JceSecurity.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java - src/windows/classes/sun/security/mscapi/JarVerifier.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java From gnu.andrew at redhat.com Wed Dec 3 16:06:23 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Dec 2014 11:06:23 -0500 (EST) Subject: [PATCH] 6647452: Remove obfuscation, framework and provider self-verification checking In-Reply-To: <547F33FB.1020709@redhat.com> References: <1643270532.10151994.1417038573036.JavaMail.zimbra@redhat.com> <5476E79C.6050003@redhat.com> <314330018.12675659.1417622136852.JavaMail.zimbra@redhat.com> <547F33FB.1020709@redhat.com> Message-ID: <1566195081.12681712.1417622783436.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 12/03/2014 03:55 PM, Andrew Hughes wrote: > > So, is this ok to push? > > Sure. > > Andrew. > > Thanks. Pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/98e143b44620 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From nikolay at azulsystems.com Wed Dec 10 12:06:26 2014 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Wed, 10 Dec 2014 15:06:26 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine Message-ID: <54883742.8080506@azulsystems.com> Please, review the fix for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine This is a regression of the fix for OPENJDK6-35 (which is a backport of JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too - it was tracked as JDK-6938454: Unable to determine generic type in program that compiles under Java 6 The solution is to backport the fix for JDK-6938454 to OpenJDK 6. The backport is small and straightforward, but not identical to the original fix - the changes related to "diamond" operator support are not applicable to OpenJDK 6. The practical reason for this fix is that currently OpenJDK 6 fails to compile Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation successfully. Bug: https://java.net/jira/browse/OPENJDK6-40 OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454 Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/ Testing: builds on Windows and Linux, all regression tests for javac, building Apache Flume 1.5.0. Thanks, Nikolay From aph at redhat.com Wed Dec 10 12:31:15 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Dec 2014 12:31:15 +0000 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <54883742.8080506@azulsystems.com> References: <54883742.8080506@azulsystems.com> Message-ID: <54883D13.7000608@redhat.com> On 12/10/2014 12:06 PM, Nikolay Gorshkov wrote: > Please, review the fix for > OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 > compiles fine > > This is a regression of the fix for OPENJDK6-35 (which is a backport of > JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too - > it was tracked as > JDK-6938454: Unable to determine generic type in program that compiles under Java 6 > The solution is to backport the fix for JDK-6938454 to OpenJDK 6. > The backport is small and straightforward, but not identical to the original > fix - the changes related to "diamond" operator support are not applicable > to OpenJDK 6. > > The practical reason for this fix is that currently OpenJDK 6 fails to compile > Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation successfully. > > Bug: https://java.net/jira/browse/OPENJDK6-40 > OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454 > Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/ > > Testing: builds on Windows and Linux, all regression tests for javac, building > Apache Flume 1.5.0. Ah, the bug that will never die. Such changes have a very unfortunate history, and this one goes back over four years. The problem always comes down to the risk of breaking existing code. This has actually happened on at least one occasion when we "fixed" such a bug in order to compile an application server and other packages which have been very stable for a long time failed to build. See http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html So, is it better to take the risk that we'll break something else? It was IMO a mistake to backport 6650759 to OpenJDK 6, but we are where we are. How important is this fix? Andrew. From gnu.andrew at redhat.com Wed Dec 10 16:11:19 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 10 Dec 2014 11:11:19 -0500 (EST) Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <54883742.8080506@azulsystems.com> References: <54883742.8080506@azulsystems.com> Message-ID: <1435404204.16427632.1418227879651.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Please, review the fix for > OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 > compiles fine > > This is a regression of the fix for OPENJDK6-35 (which is a backport of > JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too - > it was tracked as > JDK-6938454: Unable to determine generic type in program that compiles under > Java 6 > The solution is to backport the fix for JDK-6938454 to OpenJDK 6. > The backport is small and straightforward, but not identical to the original > fix - the changes related to "diamond" operator support are not applicable > to OpenJDK 6. > > The practical reason for this fix is that currently OpenJDK 6 fails to > compile > Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation > successfully. > > Bug: https://java.net/jira/browse/OPENJDK6-40 > OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454 > Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/ > > Testing: builds on Windows and Linux, all regression tests for javac, > building > Apache Flume 1.5.0. > > Thanks, > Nikolay > As this is a backport of an OpenJDK fix with an existing bug ID (6938454), there is no need for the OpenJDK 6 bug ID, OPENJDK6-40. These are only used where a fix is unique to OpenJDK 6. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From nikolay at azulsystems.com Wed Dec 10 16:32:55 2014 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Wed, 10 Dec 2014 19:32:55 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <54883D13.7000608@redhat.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> Message-ID: <548875B7.3030106@azulsystems.com> Hi Andrew, I see your point that we chose a risky way and remember discussions around http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html that we had in the past when the fix for OPENJDK6-35 was in review. Well, my opinion is that this risk was taken when we decided to integrate OPENJDK6-35. Unfortunately, we have consequences, and now we need to deal with them. Luckily, the problem is known and resolved by a simple fix. We have verified it by all available means and currently are not aware of any other regressions. In my opinion, this approach (moving forward, fixing regressions) is more preferable than moving to pre- JDK-6650759 state where we had known incompatibilities. Thanks, Nikolay On 10.12.2014 15:31, Andrew Haley wrote: > On 12/10/2014 12:06 PM, Nikolay Gorshkov wrote: >> Please, review the fix for >> OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 >> compiles fine >> >> This is a regression of the fix for OPENJDK6-35 (which is a backport of >> JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too - >> it was tracked as >> JDK-6938454: Unable to determine generic type in program that compiles under Java 6 >> The solution is to backport the fix for JDK-6938454 to OpenJDK 6. >> The backport is small and straightforward, but not identical to the original >> fix - the changes related to "diamond" operator support are not applicable >> to OpenJDK 6. >> >> The practical reason for this fix is that currently OpenJDK 6 fails to compile >> Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation successfully. >> >> Bug: https://java.net/jira/browse/OPENJDK6-40 >> OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454 >> Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/ >> >> Testing: builds on Windows and Linux, all regression tests for javac, building >> Apache Flume 1.5.0. > > Ah, the bug that will never die. Such changes have a very unfortunate > history, and this one goes back over four years. > > The problem always comes down to the risk of breaking existing code. > This has actually happened on at least one occasion when we "fixed" > such a bug in order to compile an application server and other > packages which have been very stable for a long time failed to build. > > See > http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html > > So, is it better to take the risk that we'll break something else? It > was IMO a mistake to backport 6650759 to OpenJDK 6, but we are where > we are. How important is this fix? > > Andrew. > From nikolay at azulsystems.com Wed Dec 10 16:36:42 2014 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Wed, 10 Dec 2014 19:36:42 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <1435404204.16427632.1418227879651.JavaMail.zimbra@redhat.com> References: <54883742.8080506@azulsystems.com> <1435404204.16427632.1418227879651.JavaMail.zimbra@redhat.com> Message-ID: <5488769A.8030300@azulsystems.com> Hi Andrew, OK, I see, thank you for this point! Indeed, the fix is just a backport of JDK-6938454 to OpenJDK 6. Thanks, Nikolay On 10.12.2014 19:11, Andrew Hughes wrote: > ----- Original Message ----- >> Please, review the fix for >> OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 >> compiles fine >> >> This is a regression of the fix for OPENJDK6-35 (which is a backport of >> JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too - >> it was tracked as >> JDK-6938454: Unable to determine generic type in program that compiles under >> Java 6 >> The solution is to backport the fix for JDK-6938454 to OpenJDK 6. >> The backport is small and straightforward, but not identical to the original >> fix - the changes related to "diamond" operator support are not applicable >> to OpenJDK 6. >> >> The practical reason for this fix is that currently OpenJDK 6 fails to >> compile >> Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation >> successfully. >> >> Bug: https://java.net/jira/browse/OPENJDK6-40 >> OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454 >> Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/ >> >> Testing: builds on Windows and Linux, all regression tests for javac, >> building >> Apache Flume 1.5.0. >> >> Thanks, >> Nikolay >> > > As this is a backport of an OpenJDK fix with an existing bug ID (6938454), > there is no need for the OpenJDK 6 bug ID, OPENJDK6-40. These are only used > where a fix is unique to OpenJDK 6. > > Thanks, > From aph at redhat.com Wed Dec 10 16:56:49 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Dec 2014 16:56:49 +0000 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <548875B7.3030106@azulsystems.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> Message-ID: <54887B51.9090508@redhat.com> On 12/10/2014 04:32 PM, Nikolay Gorshkov wrote: > I see your point that we chose a risky way and remember discussions > around > http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html > that we had in the past when the fix for OPENJDK6-35 was in review. > > Well, my opinion is that this risk was taken when we decided to integrate > OPENJDK6-35. Unfortunately, we have consequences, and now we need to deal > with them. Luckily, the problem is known and resolved by a simple fix. > We have verified it by all available means and currently are not aware of > any other regressions. In my opinion, this approach (moving forward, fixing > regressions) is more preferable than moving to pre- JDK-6650759 state where > we had known incompatibilities. I admit that you're probably right, but I still need an answer to my question about how important this patch is. Andrew. From nikolay at azulsystems.com Thu Dec 11 18:59:25 2014 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Thu, 11 Dec 2014 21:59:25 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <54887B51.9090508@redhat.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> Message-ID: <5489E98D.8060704@azulsystems.com> Hi Andrew, Me and my colleagues have a consensus that the patch is important to us - we are responsible for introducing a regression into OpenJDK 6 (breaking Apache Flume 1.5.0 compilation), and so we have to fix it. We have already included this patch into our OpenJDK 6 -based products, and now we are interested in upstreaming it to OpenJDK 6 itself to minimize the difference in codebase. Thanks, Nikolay On 10.12.2014 19:56, Andrew Haley wrote: > On 12/10/2014 04:32 PM, Nikolay Gorshkov wrote: >> I see your point that we chose a risky way and remember discussions >> around >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html >> that we had in the past when the fix for OPENJDK6-35 was in review. >> >> Well, my opinion is that this risk was taken when we decided to integrate >> OPENJDK6-35. Unfortunately, we have consequences, and now we need to deal >> with them. Luckily, the problem is known and resolved by a simple fix. >> We have verified it by all available means and currently are not aware of >> any other regressions. In my opinion, this approach (moving forward, fixing >> regressions) is more preferable than moving to pre- JDK-6650759 state where >> we had known incompatibilities. > > I admit that you're probably right, but I still need an answer to my > question about how important this patch is. > > Andrew. > > From aph at redhat.com Thu Dec 11 19:01:43 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Dec 2014 19:01:43 +0000 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <5489E98D.8060704@azulsystems.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> <5489E98D.8060704@azulsystems.com> Message-ID: <5489EA17.3090806@redhat.com> On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: > Me and my colleagues have a consensus that the patch is important to us - > we are responsible for introducing a regression into OpenJDK 6 (breaking > Apache Flume 1.5.0 compilation), and so we have to fix it. We have already > included this patch into our OpenJDK 6 -based products, and now we are > interested in upstreaming it to OpenJDK 6 itself to minimize the difference > in codebase. Reluctantly, OK. I am crossing my fingers and hoping that this is the last we'll see of this bug! We shall see. Thanks for your patience, Andrew. From kubota.yuji at lab.ntt.co.jp Mon Dec 15 09:50:54 2014 From: kubota.yuji at lab.ntt.co.jp (KUBOTA Yuji) Date: Mon, 15 Dec 2014 18:50:54 +0900 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <5473214B.2060605@azulsystems.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> Message-ID: <548EAEFE.5060308@lab.ntt.co.jp> Hi Ivan, Thank you for your reply. My apologies for the late reply. Unfortunately, I try to search the commit of this fix, but I could not find it. So I wrote the patch to solve this problem. If set less than 1 to the second parameter of HttpServer#create, HttpServer is created with the default socket backlog, i.e. 50([1]). I think that JAX-WS should use the default socket backlog than specific low value like 5. If there is a better method for openjdk community, please advise me. ----- diff -r 48972b9b6536 drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java --- a/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Wed Oct 08 19:12:52 2014 +0100 +++ b/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Fri Dec 05 15:02:18 2014 +0900 @@ -79,7 +79,8 @@ state = servers.get(inetAddress); if (state == null) { logger.fine("Creating new HTTP Server at "+inetAddress); - server = HttpServer.create(inetAddress, 5); + // Creates a new HTTP server with default socket backlog. + server = HttpServer.create(inetAddress, 0); server.setExecutor(Executors.newCachedThreadPool()); String path = url.toURI().getPath(); logger.fine("Creating HTTP Context at = "+path); ----- [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/classes/java/net/ServerSocket.java#l199 Thanks, Yuji On 2014/11/24 21:15, Ivan Krylov wrote: > Not sure what link [1] should be demonstrating. Could you send a link to the diff associated with the fix? > > Thanks, > > Ivan > > On 21/11/2014 07:03, KUBOTA Yuji wrote: >> Hi all, >> >> JDK7 and JAX-WS RI 2.2.6 solved the low socket backlog of HttpServer [1]. >> However, JDK6 still provides the HttpServer which is created with socket backlog 5 [2]. >> >> I could not find the reason why this change do not backport to JDK6. >> Please backport it or update JAX-WS of JDK6, if there is not a blocker of this issue. >> >> Thanks, >> Yuji. >> >> [1]:https://java.net/jira/browse/JAX_WS-945 >> [2]:http://hg.openjdk.java.net/jdk6/jdk6/jaxws/file/48972b9b6536/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java#l82 From gnu.andrew at redhat.com Mon Dec 15 13:17:49 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Dec 2014 08:17:49 -0500 (EST) Subject: The socket backlog of HttpServer is still low. In-Reply-To: <548EAEFE.5060308@lab.ntt.co.jp> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> Message-ID: <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Ivan, > > Thank you for your reply. My apologies for the late reply. > > Unfortunately, I try to search the commit of this fix, but I could not find > it. > > So I wrote the patch to solve this problem. If set less than 1 to the second > parameter > of HttpServer#create, HttpServer is created with the default socket backlog, > i.e. 50([1]). > > I think that JAX-WS should use the default socket backlog than specific low > value like 5. > If there is a better method for openjdk community, please advise me. > > ----- > > diff -r 48972b9b6536 > drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > --- > a/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > Wed Oct 08 19:12:52 2014 +0100 > +++ > b/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > Fri Dec 05 15:02:18 2014 +0900 > @@ -79,7 +79,8 @@ > state = servers.get(inetAddress); > if (state == null) { > logger.fine("Creating new HTTP Server at > "+inetAddress); > - server = HttpServer.create(inetAddress, 5); > + // Creates a new HTTP server with default socket > backlog. > + server = HttpServer.create(inetAddress, 0); > server.setExecutor(Executors.newCachedThreadPool()); > String path = url.toURI().getPath(); > logger.fine("Creating HTTP Context at = "+path); > ----- > > [1] > http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/classes/java/net/ServerSocket.java#l199 > > Thanks, > Yuji > > On 2014/11/24 21:15, Ivan Krylov wrote: > > Not sure what link [1] should be demonstrating. Could you send a link to > > the diff associated with the fix? > > > > Thanks, > > > > Ivan > > > > On 21/11/2014 07:03, KUBOTA Yuji wrote: > >> Hi all, > >> > >> JDK7 and JAX-WS RI 2.2.6 solved the low socket backlog of HttpServer [1]. > >> However, JDK6 still provides the HttpServer which is created with socket > >> backlog 5 [2]. > >> > >> I could not find the reason why this change do not backport to JDK6. > >> Please backport it or update JAX-WS of JDK6, if there is not a blocker of > >> this issue. > >> > >> Thanks, > >> Yuji. > >> > >> [1]:https://java.net/jira/browse/JAX_WS-945 > >> [2]:http://hg.openjdk.java.net/jdk6/jdk6/jaxws/file/48972b9b6536/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java#l82 > > > Yes, this is a problem with the way Sun/Oracle maintain JAXP and JAXWS; the sources are bulk updated outside of security updates, so there's no log of changes. At least now they do keep the sources in the OpenJDK tree rather than as external zip files... To this end, the only log I get for this file in OpenJDK 7 is: $ hg log -R ../../jdk7/jaxws ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java changeset: 321:913b9e4d8c51 user: ohair date: Sun May 13 11:14:50 2012 -0700 summary: 7150322: Stop using drop source bundles in jaxws which is pretty unhelpful. However, the diff between the 6 and 7 versions of the file is pretty close to your patch: $ diff -u ../jaxws/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java --- ../jaxws/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java 2013-09-10 18:09:25.743193221 +0100 +++ ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java 2012-05-14 05:03:15.000000000 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -22,6 +22,7 @@ * or visit www.oracle.com if you need additional information or have any * questions. */ + package com.sun.xml.internal.ws.transport.http.server; import com.sun.net.httpserver.HttpContext; @@ -79,7 +80,8 @@ state = servers.get(inetAddress); if (state == null) { logger.fine("Creating new HTTP Server at "+inetAddress); - server = HttpServer.create(inetAddress, 5); + // Creates server with default socket backlog + server = HttpServer.create(inetAddress, 0); server.setExecutor(Executors.newCachedThreadPool()); String path = url.toURI().getPath(); logger.fine("Creating HTTP Context at = "+path); I'm happy to file an OpenJDK 6 bug for this and apply that patch, unless someone else has any objections. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Mon Dec 15 13:35:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Dec 2014 13:35:28 +0000 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> Message-ID: <548EE3A0.307@oracle.com> On 15/12/2014 13:17, Andrew Hughes wrote: > Yes, this is a problem with the way Sun/Oracle maintain JAXP and JAXWS; the sources > are bulk updated outside of security updates, so there's no log of changes. At least > now they do keep the sources in the OpenJDK tree rather than as external zip files... > What you say is true for the jaxws repo as the master sources comes from about 10 upstream projects. It's different for JAXP as this has been maintained in OpenJDK for a few years now (and the upstream project shutdown). -Alan. From gnu.andrew at redhat.com Mon Dec 15 14:12:15 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Dec 2014 09:12:15 -0500 (EST) Subject: The socket backlog of HttpServer is still low. In-Reply-To: <548EE3A0.307@oracle.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> <548EE3A0.307@oracle.com> Message-ID: <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 15/12/2014 13:17, Andrew Hughes wrote: > > Yes, this is a problem with the way Sun/Oracle maintain JAXP and JAXWS; the > > sources > > are bulk updated outside of security updates, so there's no log of changes. > > At least > > now they do keep the sources in the OpenJDK tree rather than as external > > zip files... > > > What you say is true for the jaxws repo as the master sources comes from > about 10 upstream projects. > > It's different for JAXP as this has been maintained in OpenJDK for a few > years now (and the upstream project shutdown). > Ah ok, I wasn't aware of that; thanks for the correction. It will certainly make it easier to cherry-pick any required changes from there. It may have happened a few years ago for later versions, but it was outside Oracle maintainership of OpenJDK 6 [0]. The end of that pre-dates even the switch to in-tree sources, which we mirrored with our own changes in OPENJDK6-6 [1] and OPENJDK6-7 [2]. [0] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002978.html [2] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002984.html > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ivan at azulsystems.com Mon Dec 15 14:56:39 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 15 Dec 2014 17:56:39 +0300 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> <548EE3A0.307@oracle.com> <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> Message-ID: <548EF6A7.60108@azulsystems.com> Hi Andrew and all, I am about to push this change for Nikolay. Given that last time we had a bit of discussion on the right format of putback message, i want to check with you this the following is fine. Please check the text below and tell me if you see any issues. According to Nikolay, this fix is not a strightforward port but a reworked fix for the 7's 6938454. Thanks, Ivan 6938454: Unable to determine generic type in program that compiles under Java 6 Reviewed-by: aph Contributed-by: nikgor On 15/12/2014 17:12, Andrew Hughes wrote: > ----- Original Message ----- >> On 15/12/2014 13:17, Andrew Hughes wrote: >>> Yes, this is a problem with the way Sun/Oracle maintain JAXP and JAXWS; the >>> sources >>> are bulk updated outside of security updates, so there's no log of changes. >>> At least >>> now they do keep the sources in the OpenJDK tree rather than as external >>> zip files... >>> >> What you say is true for the jaxws repo as the master sources comes from >> about 10 upstream projects. >> >> It's different for JAXP as this has been maintained in OpenJDK for a few >> years now (and the upstream project shutdown). >> > Ah ok, I wasn't aware of that; thanks for the correction. It will certainly > make it easier to cherry-pick any required changes from there. > > It may have happened a few years ago for later versions, but it was outside > Oracle maintainership of OpenJDK 6 [0]. The end of that pre-dates even the > switch to in-tree sources, which we mirrored with our own changes in > OPENJDK6-6 [1] and OPENJDK6-7 [2]. > > [0] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html > [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002978.html > [2] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002984.html > >> -Alan. >> From ivan at azulsystems.com Mon Dec 15 15:03:50 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 15 Dec 2014 18:03:50 +0300 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <548EF6A7.60108@azulsystems.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> <548EE3A0.307@oracle.com> <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> <548EF6A7.60108@azulsystems.com> Message-ID: <548EF856.6050606@azulsystems.com> Oops, wrong thread, sorry. I meant to reply on Nikolay's letter about OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine Thanks, Ivan On 15/12/2014 17:56, Ivan Krylov wrote: > Hi Andrew and all, > > I am about to push this change for Nikolay. > Given that last time we had a bit of discussion on the right format of > putback message, i want to check with you this the following is fine. > Please check the text below and tell me if you see any issues. > According to Nikolay, this fix is not a strightforward port but a > reworked fix for the 7's 6938454. > > Thanks, > > Ivan > > > 6938454: Unable to determine generic type in program that compiles > under Java 6 > Reviewed-by: aph > Contributed-by: nikgor > > > On 15/12/2014 17:12, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 15/12/2014 13:17, Andrew Hughes wrote: >>>> Yes, this is a problem with the way Sun/Oracle maintain JAXP and >>>> JAXWS; the >>>> sources >>>> are bulk updated outside of security updates, so there's no log of >>>> changes. >>>> At least >>>> now they do keep the sources in the OpenJDK tree rather than as >>>> external >>>> zip files... >>>> >>> What you say is true for the jaxws repo as the master sources comes >>> from >>> about 10 upstream projects. >>> >>> It's different for JAXP as this has been maintained in OpenJDK for a >>> few >>> years now (and the upstream project shutdown). >>> >> Ah ok, I wasn't aware of that; thanks for the correction. It will >> certainly >> make it easier to cherry-pick any required changes from there. >> >> It may have happened a few years ago for later versions, but it was >> outside >> Oracle maintainership of OpenJDK 6 [0]. The end of that pre-dates >> even the >> switch to in-tree sources, which we mirrored with our own changes in >> OPENJDK6-6 [1] and OPENJDK6-7 [2]. >> >> [0] >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html >> [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002978.html >> [2] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002984.html >> >>> -Alan. >>> > > From ivan at azulsystems.com Mon Dec 15 15:35:10 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 15 Dec 2014 18:35:10 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <5489EA17.3090806@redhat.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> <5489E98D.8060704@azulsystems.com> <5489EA17.3090806@redhat.com> Message-ID: <548EFFAE.1040108@azulsystems.com> resending to the right mail thread: Hi Andrew and all, I am about to push this change for Nikolay. Given that last time we had a bit of discussion on the right format of putback message, i want to check with you this the following is fine. Please check the text below and tell me if you see any issues. According to Nikolay, this fix is not a strightforward port but a reworked fix for the 7's 6938454. Thanks, Ivan 6938454: Unable to determine generic type in program that compiles under Java 6 Reviewed-by: aph Contributed-by: nikgor On 11/12/2014 22:01, Andrew Haley wrote: > On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: >> Me and my colleagues have a consensus that the patch is important to us - >> we are responsible for introducing a regression into OpenJDK 6 (breaking >> Apache Flume 1.5.0 compilation), and so we have to fix it. We have already >> included this patch into our OpenJDK 6 -based products, and now we are >> interested in upstreaming it to OpenJDK 6 itself to minimize the difference >> in codebase. > Reluctantly, OK. I am crossing my fingers and hoping that this > is the last we'll see of this bug! We shall see. > > Thanks for your patience, > Andrew. > > From gnu.andrew at redhat.com Mon Dec 15 15:40:24 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Dec 2014 10:40:24 -0500 (EST) Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <548EFFAE.1040108@azulsystems.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> <5489E98D.8060704@azulsystems.com> <5489EA17.3090806@redhat.com> <548EFFAE.1040108@azulsystems.com> Message-ID: <1852667002.515657.1418658024605.JavaMail.zimbra@redhat.com> ----- Original Message ----- > resending to the right mail thread: > > > Hi Andrew and all, > > I am about to push this change for Nikolay. > Given that last time we had a bit of discussion on the right format of > putback message, i want to check with you this the following is fine. > Please check the text below and tell me if you see any issues. The main thing that concerns me is the loss of the original author information, but I'm not sure if we have a solution for this as yet. I tend to go with the original author as the changeset author (hg commit --user ) but that also has the downside of not crediting the backporter. I guess both it and the original reviewer could be looked up via the changeset in 7, which is: 6938454: Unable to determine generic type in program that compiles under Java 6 Summary: a redundant dubtyping check causes spurious inference failure Reviewed-by: jjg I think that's meant to be 'subtyping' ;) > According to Nikolay, this fix is not a strightforward port but a > reworked fix for the 7's 6938454. > I hadn't realised this. Is there a reason the following hunks are absent? diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jul 27 11:52:11 2010 -0700 +++ b/src/share/classes/com/sun/tools/javac/comp/Attr.java Thu Jul 29 15:56:25 2010 +0100 @@ -1694,8 +1694,22 @@ //if the type of the instance creation expression is an interface //skip the method resolution step (JLS 15.12.2.7). The type to be //inferred is of the kind C - clazztype = new ForAll(clazztype.tsym.type.allparams(), - clazztype.tsym.type); + clazztype = new ForAll(clazztype.tsym.type.allparams(), clazztype.tsym.type) { + @Override + public List getConstraints(TypeVar tv, ConstraintKind ck) { + switch (ck) { + case EXTENDS: return types.getBounds(tv); + default: return List.nil(); + } + } + @Override + public Type inst(List inferred, Types types) throws Infer.NoInstanceException { + // check that inferred bounds conform to their bounds + infer.checkWithinBounds(tvars, + types.subst(tvars, tvars, inferred), Warner.noWarnings); + return super.inst(inferred, types); + } + }; } else { //if the type of the instance creation expression is a class type //apply method resolution inference (JLS 15.12.2.7). The return type diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Infer.java --- a/src/share/classes/com/sun/tools/javac/comp/Infer.java Tue Jul 27 11:52:11 2010 -0700 +++ b/src/share/classes/com/sun/tools/javac/comp/Infer.java Thu Jul 29 15:56:25 2010 +0100 @@ -458,7 +457,7 @@ /** check that type parameters are within their bounds. */ - private void checkWithinBounds(List tvars, + void checkWithinBounds(List tvars, List arguments, Warner warn) throws InvalidInstanceException { Do the new tests added by the change pass? > Thanks, > > Ivan > > 6938454: Unable to determine generic type in program that compiles under > Java 6 > Reviewed-by: aph > Contributed-by: nikgor > > > > On 11/12/2014 22:01, Andrew Haley wrote: > > On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: > >> Me and my colleagues have a consensus that the patch is important to us - > >> we are responsible for introducing a regression into OpenJDK 6 (breaking > >> Apache Flume 1.5.0 compilation), and so we have to fix it. We have already > >> included this patch into our OpenJDK 6 -based products, and now we are > >> interested in upstreaming it to OpenJDK 6 itself to minimize the > >> difference > >> in codebase. > > Reluctantly, OK. I am crossing my fingers and hoping that this > > is the last we'll see of this bug! We shall see. > > > > Thanks for your patience, > > Andrew. > > > > > > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From nikolay at azulsystems.com Mon Dec 15 16:08:48 2014 From: nikolay at azulsystems.com (Nikolay Gorshkov) Date: Mon, 15 Dec 2014 19:08:48 +0300 Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <1852667002.515657.1418658024605.JavaMail.zimbra@redhat.com> References: <54883742.8080506@azulsystems.com> <54883D13.7000608@redhat.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> <5489E98D.8060704@azulsystems.com> <5489EA17.3090806@redhat.com> <548EFFAE.1040108@azulsystems.com> <1852667002.515657.1418658024605.JavaMail.zimbra@redhat.com> Message-ID: <548F0790.7000206@azulsystems.com> Hi Andrew, On 15.12.2014 18:40, Andrew Hughes wrote: > The main thing that concerns me is the loss of the original author > information, but I'm not sure if we have a solution for this as yet. > I tend to go with the original author as the changeset author > (hg commit --user ) but that also has the downside of > not crediting the backporter. > > I guess both it and the original reviewer could be looked up via > the changeset in 7, which is: > > 6938454: Unable to determine generic type in program that compiles under Java 6 > Summary: a redundant dubtyping check causes spurious inference failure > Reviewed-by: jjg > > I think that's meant to be 'subtyping' ;) As we discussed some time ago, for backports we could add a new commit message header like "Authored-by: ", but it likely requires jcheck modification and updating official rules. > I hadn't realised this. Is there a reason the following hunks are absent? > > diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jul 27 11:52:11 2010 -0700 > +++ b/src/share/classes/com/sun/tools/javac/comp/Attr.java Thu Jul 29 15:56:25 2010 +0100 > @@ -1694,8 +1694,22 @@ > //if the type of the instance creation expression is an interface > //skip the method resolution step (JLS 15.12.2.7). The type to be > //inferred is of the kind C > - clazztype = new ForAll(clazztype.tsym.type.allparams(), > - clazztype.tsym.type); > + clazztype = new ForAll(clazztype.tsym.type.allparams(), clazztype.tsym.type) { > + @Override > + public List getConstraints(TypeVar tv, ConstraintKind ck) { > + switch (ck) { > + case EXTENDS: return types.getBounds(tv); > + default: return List.nil(); > + } > + } > + @Override > + public Type inst(List inferred, Types types) throws Infer.NoInstanceException { > + // check that inferred bounds conform to their bounds > + infer.checkWithinBounds(tvars, > + types.subst(tvars, tvars, inferred), Warner.noWarnings); > + return super.inst(inferred, types); > + } > + }; > } else { > //if the type of the instance creation expression is a class type > //apply method resolution inference (JLS 15.12.2.7). The return type > > diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Infer.java > --- a/src/share/classes/com/sun/tools/javac/comp/Infer.java Tue Jul 27 11:52:11 2010 -0700 > +++ b/src/share/classes/com/sun/tools/javac/comp/Infer.java Thu Jul 29 15:56:25 2010 +0100 > @@ -458,7 +457,7 @@ > > /** check that type parameters are within their bounds. > */ > - private void checkWithinBounds(List tvars, > + void checkWithinBounds(List tvars, > List arguments, > Warner warn) > throws InvalidInstanceException { These parts of the original fix were excluded because they are related to diamond ("<>") operator support, which appeared in Java 7 and is not a part of Java 6. > Do the new tests added by the change pass? Yes, I checked newly added testcases, and also all existing javac jtreg tests (langtools/test/tools/javac) - all of them passed. Thanks, Nikolay > >> Thanks, >> >> Ivan >> >> 6938454: Unable to determine generic type in program that compiles under >> Java 6 >> Reviewed-by: aph >> Contributed-by: nikgor >> >> >> >> On 11/12/2014 22:01, Andrew Haley wrote: >>> On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: >>>> Me and my colleagues have a consensus that the patch is important to us - >>>> we are responsible for introducing a regression into OpenJDK 6 (breaking >>>> Apache Flume 1.5.0 compilation), and so we have to fix it. We have already >>>> included this patch into our OpenJDK 6 -based products, and now we are >>>> interested in upstreaming it to OpenJDK 6 itself to minimize the >>>> difference >>>> in codebase. >>> Reluctantly, OK. I am crossing my fingers and hoping that this >>> is the last we'll see of this bug! We shall see. >>> >>> Thanks for your patience, >>> Andrew. >>> >>> >> >> > > Thanks, > From gnu.andrew at redhat.com Mon Dec 15 16:57:58 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Dec 2014 11:57:58 -0500 (EST) Subject: Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine In-Reply-To: <548F0790.7000206@azulsystems.com> References: <54883742.8080506@azulsystems.com> <548875B7.3030106@azulsystems.com> <54887B51.9090508@redhat.com> <5489E98D.8060704@azulsystems.com> <5489EA17.3090806@redhat.com> <548EFFAE.1040108@azulsystems.com> <1852667002.515657.1418658024605.JavaMail.zimbra@redhat.com> <548F0790.7000206@azulsystems.com> Message-ID: <869847327.563475.1418662678627.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Andrew, > > On 15.12.2014 18:40, Andrew Hughes wrote: > > The main thing that concerns me is the loss of the original author > > information, but I'm not sure if we have a solution for this as yet. > > I tend to go with the original author as the changeset author > > (hg commit --user ) but that also has the downside of > > not crediting the backporter. > > > > I guess both it and the original reviewer could be looked up via > > the changeset in 7, which is: > > > > 6938454: Unable to determine generic type in program that compiles under > > Java 6 > > Summary: a redundant dubtyping check causes spurious inference failure > > Reviewed-by: jjg > > > > I think that's meant to be 'subtyping' ;) > > As we discussed some time ago, for backports we could add a new > commit message header like "Authored-by: ", > but it likely requires jcheck modification and updating official > rules. Yes, I remember this discussion. I was hoping someone might be able to provide feedback on any progress on getting this supported in jcheck, as I've not heard of it being added. > > > I hadn't realised this. Is there a reason the following hunks are absent? > > > > diff -r ed354a00f76b -r 36c4ec4525b4 > > src/share/classes/com/sun/tools/javac/comp/Attr.java > > --- a/src/share/classes/com/sun/tools/javac/comp/Attr.java Tue Jul 27 > > 11:52:11 2010 -0700 > > +++ b/src/share/classes/com/sun/tools/javac/comp/Attr.java Thu Jul 29 > > 15:56:25 2010 +0100 > > @@ -1694,8 +1694,22 @@ > > //if the type of the instance creation expression is an > > interface > > //skip the method resolution step (JLS 15.12.2.7). The type > > to be > > //inferred is of the kind C > > - clazztype = new ForAll(clazztype.tsym.type.allparams(), > > - clazztype.tsym.type); > > + clazztype = new ForAll(clazztype.tsym.type.allparams(), > > clazztype.tsym.type) { > > + @Override > > + public List getConstraints(TypeVar tv, > > ConstraintKind ck) { > > + switch (ck) { > > + case EXTENDS: return types.getBounds(tv); > > + default: return List.nil(); > > + } > > + } > > + @Override > > + public Type inst(List inferred, Types types) throws > > Infer.NoInstanceException { > > + // check that inferred bounds conform to their bounds > > + infer.checkWithinBounds(tvars, > > + types.subst(tvars, tvars, inferred), > > Warner.noWarnings); > > + return super.inst(inferred, types); > > + } > > + }; > > } else { > > //if the type of the instance creation expression is a class > > type > > //apply method resolution inference (JLS 15.12.2.7). The > > return type > > > > diff -r ed354a00f76b -r 36c4ec4525b4 > > src/share/classes/com/sun/tools/javac/comp/Infer.java > > --- a/src/share/classes/com/sun/tools/javac/comp/Infer.java Tue Jul 27 > > 11:52:11 2010 -0700 > > +++ b/src/share/classes/com/sun/tools/javac/comp/Infer.java Thu Jul 29 > > 15:56:25 2010 +0100 > > @@ -458,7 +457,7 @@ > > > > /** check that type parameters are within their bounds. > > */ > > - private void checkWithinBounds(List tvars, > > + void checkWithinBounds(List tvars, > > List arguments, > > Warner warn) > > throws InvalidInstanceException { > > These parts of the original fix were excluded because they are > related to diamond ("<>") operator support, which appeared in > Java 7 and is not a part of Java 6. > Ah, ok. > > Do the new tests added by the change pass? > > Yes, I checked newly added testcases, and also all existing > javac jtreg tests (langtools/test/tools/javac) - all of them passed. > Ok, this looks good to go. > Thanks, > Nikolay > > > > >> Thanks, > >> > >> Ivan > >> > >> 6938454: Unable to determine generic type in program that compiles under > >> Java 6 > >> Reviewed-by: aph > >> Contributed-by: nikgor > >> > >> > >> > >> On 11/12/2014 22:01, Andrew Haley wrote: > >>> On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote: > >>>> Me and my colleagues have a consensus that the patch is important to us > >>>> - > >>>> we are responsible for introducing a regression into OpenJDK 6 (breaking > >>>> Apache Flume 1.5.0 compilation), and so we have to fix it. We have > >>>> already > >>>> included this patch into our OpenJDK 6 -based products, and now we are > >>>> interested in upstreaming it to OpenJDK 6 itself to minimize the > >>>> difference > >>>> in codebase. > >>> Reluctantly, OK. I am crossing my fingers and hoping that this > >>> is the last we'll see of this bug! We shall see. > >>> > >>> Thanks for your patience, > >>> Andrew. > >>> > >>> > >> > >> > > > > Thanks, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ivan at azulsystems.com Mon Dec 15 17:19:46 2014 From: ivan at azulsystems.com (ivan at azulsystems.com) Date: Mon, 15 Dec 2014 17:19:46 +0000 Subject: hg: jdk6/jdk6/langtools: 6938454: Unable to determine generic type in program that compiles under Java 6 Message-ID: <201412151719.sBFHJkRM011877@aojmv0008> Changeset: 20eebcd42dae Author: ikrylov Date: 2014-12-15 21:19 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/20eebcd42dae 6938454: Unable to determine generic type in program that compiles under Java 6 Reviewed-by: aph Contributed-by: nikgor ! src/share/classes/com/sun/tools/javac/comp/Infer.java From ivan at azulsystems.com Mon Dec 15 17:23:35 2014 From: ivan at azulsystems.com (ivan at azulsystems.com) Date: Mon, 15 Dec 2014 17:23:35 +0000 Subject: hg: jdk6/jdk6/langtools: 6938454: 2 new testcases for bug: Unable to determine generic type in program that compiles under Java 6 Message-ID: <201412151723.sBFHNZZQ013513@aojmv0008> Changeset: 4173e592ffa3 Author: ikrylov Date: 2014-12-15 21:23 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/4173e592ffa3 6938454: 2 new testcases for bug: Unable to determine generic type in program that compiles under Java 6 Reviewed-by: aph Contributed-by: nikgor + test/tools/javac/generics/inference/6938454/T6938454a.java + test/tools/javac/generics/inference/6938454/T6938454b.java From kubota.yuji at gmail.com Tue Dec 16 17:31:39 2014 From: kubota.yuji at gmail.com (Yuji Kubota) Date: Wed, 17 Dec 2014 02:31:39 +0900 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> <548EE3A0.307@oracle.com> <1932001913.388125.1418652735864.JavaMail.zimbra@redhat.com> Message-ID: Hi Andrew and Alan, 2014-12-15 23:12 GMT+09:00 Andrew Hughes : > > Ah ok, I wasn't aware of that; thanks for the correction. It will certainly > make it easier to cherry-pick any required changes from there. > > It may have happened a few years ago for later versions, but it was outside > Oracle maintainership of OpenJDK 6 [0]. The end of that pre-dates even the > switch to in-tree sources, which we mirrored with our own changes in > OPENJDK6-6 [1] and OPENJDK6-7 [2]. > > [0] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html > [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002978.html > [2] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-May/002984.html > > Thanks for the detailed background about JAX-WS (and JAXP). I hope the patch will be applied in a way that suits community! Thanks, Yuji -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Dec 24 17:05:46 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Dec 2014 12:05:46 -0500 (EST) Subject: [PATCH] 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK In-Reply-To: <347397298.1014321.1419440373014.JavaMail.zimbra@redhat.com> Message-ID: <1738231452.1014941.1419440746841.JavaMail.zimbra@redhat.com> Webrev: http://cr.openjdk.java.net/~andrew/openjdk6/7201205/ This is a fairly simple backport from OpenJDK 7 [0]. It allows us the option of building OpenJDK with the unlimited crypto policy, rather than hardcoding the limited policy. After a build with UNLIMITED_CRYPTO=true, the TestCryptoLevel Java code from IcedTea [1] runs as follows: $ /mnt/builder/openjdk6/j2sdk-image/bin/java TestCryptoLevel Running with the unlimited policy. Ok to push? [0] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/53fc48ac178f [1] http://icedtea.classpath.org/hg/icedtea6/file/tip/TestCryptoLevel.java -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Wed Dec 24 17:07:42 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 24 Dec 2014 12:07:42 -0500 Subject: [PATCH] 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK In-Reply-To: <1738231452.1014941.1419440746841.JavaMail.zimbra@redhat.com> References: <347397298.1014321.1419440373014.JavaMail.zimbra@redhat.com> <1738231452.1014941.1419440746841.JavaMail.zimbra@redhat.com> Message-ID: <20141224170742.GA8737@redhat.com> * Andrew Hughes [2014-12-24 12:05]: > Webrev: http://cr.openjdk.java.net/~andrew/openjdk6/7201205/ > > This is a fairly simple backport from OpenJDK 7 [0]. It allows > us the option of building OpenJDK with the unlimited crypto policy, > rather than hardcoding the limited policy. > > After a build with UNLIMITED_CRYPTO=true, the TestCryptoLevel Java > code from IcedTea [1] runs as follows: > > $ /mnt/builder/openjdk6/j2sdk-image/bin/java TestCryptoLevel > Running with the unlimited policy. > > Ok to push? Yes, please! Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Dec 24 17:41:50 2014 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 24 Dec 2014 17:41:50 +0000 Subject: hg: jdk6/jdk6/jdk: 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK. Message-ID: <201412241741.sBOHfoT5018367@aojmv0008> Changeset: a685b7a3293f Author: andrew Date: 2012-09-27 17:55 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a685b7a3293f 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK. Summary: Allow OpenJDK to use the unlimited crypto policy. Reviewed-by: wetmore, ohair, omajid ! make/javax/crypto/Makefile From gnu.andrew at redhat.com Wed Dec 24 18:34:48 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Dec 2014 13:34:48 -0500 (EST) Subject: [PATCH] 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK In-Reply-To: <20141224170742.GA8737@redhat.com> References: <347397298.1014321.1419440373014.JavaMail.zimbra@redhat.com> <1738231452.1014941.1419440746841.JavaMail.zimbra@redhat.com> <20141224170742.GA8737@redhat.com> Message-ID: <1307136265.1021708.1419446088241.JavaMail.zimbra@redhat.com> ----- Original Message ----- > * Andrew Hughes [2014-12-24 12:05]: > > Webrev: http://cr.openjdk.java.net/~andrew/openjdk6/7201205/ > > > > This is a fairly simple backport from OpenJDK 7 [0]. It allows > > us the option of building OpenJDK with the unlimited crypto policy, > > rather than hardcoding the limited policy. > > > > After a build with UNLIMITED_CRYPTO=true, the TestCryptoLevel Java > > code from IcedTea [1] runs as follows: > > > > $ /mnt/builder/openjdk6/j2sdk-image/bin/java TestCryptoLevel > > Running with the unlimited policy. > > > > Ok to push? > > Yes, please! > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a685b7a3293f Thanks! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Dec 24 18:38:38 2014 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 24 Dec 2014 18:38:38 +0000 Subject: hg: jdk6/jdk6/jaxws: OPENJDK6-43: Backport JAX_WS-945; Socket backlog may be limiting lwhs performance Message-ID: <201412241838.sBOIccDo029954@aojmv0008> Changeset: ff5dc052d805 Author: andrew Date: 2014-12-24 18:38 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/ff5dc052d805 OPENJDK6-43: Backport JAX_WS-945; Socket backlog may be limiting lwhs performance Summary: Sync ServerMgr.java file with version in OpenJDK 7 Reviewed-by: andrew Contributed-by: KUBOTA Yuji ! drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java From gnu.andrew at redhat.com Wed Dec 24 18:45:11 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Dec 2014 13:45:11 -0500 (EST) Subject: The socket backlog of HttpServer is still low. In-Reply-To: <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> Message-ID: <277118171.1022279.1419446711569.JavaMail.zimbra@redhat.com> ----- Original Message ----- > ----- Original Message ----- > > Hi Ivan, > > > > Thank you for your reply. My apologies for the late reply. > > > > Unfortunately, I try to search the commit of this fix, but I could not find > > it. > > > > So I wrote the patch to solve this problem. If set less than 1 to the > > second > > parameter > > of HttpServer#create, HttpServer is created with the default socket > > backlog, > > i.e. 50([1]). > > > > I think that JAX-WS should use the default socket backlog than specific low > > value like 5. > > If there is a better method for openjdk community, please advise me. > > > > ----- > > > > diff -r 48972b9b6536 > > drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > > --- > > a/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > > Wed Oct 08 19:12:52 2014 +0100 > > +++ > > b/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > > Fri Dec 05 15:02:18 2014 +0900 > > @@ -79,7 +79,8 @@ > > state = servers.get(inetAddress); > > if (state == null) { > > logger.fine("Creating new HTTP Server at > > "+inetAddress); > > - server = HttpServer.create(inetAddress, 5); > > + // Creates a new HTTP server with default socket > > backlog. > > + server = HttpServer.create(inetAddress, 0); > > server.setExecutor(Executors.newCachedThreadPool()); > > String path = url.toURI().getPath(); > > logger.fine("Creating HTTP Context at = "+path); > > ----- > > > > [1] > > http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src/share/classes/java/net/ServerSocket.java#l199 > > > > Thanks, > > Yuji > > > > On 2014/11/24 21:15, Ivan Krylov wrote: > > > Not sure what link [1] should be demonstrating. Could you send a link to > > > the diff associated with the fix? > > > > > > Thanks, > > > > > > Ivan > > > > > > On 21/11/2014 07:03, KUBOTA Yuji wrote: > > >> Hi all, > > >> > > >> JDK7 and JAX-WS RI 2.2.6 solved the low socket backlog of HttpServer > > >> [1]. > > >> However, JDK6 still provides the HttpServer which is created with socket > > >> backlog 5 [2]. > > >> > > >> I could not find the reason why this change do not backport to JDK6. > > >> Please backport it or update JAX-WS of JDK6, if there is not a blocker > > >> of > > >> this issue. > > >> > > >> Thanks, > > >> Yuji. > > >> > > >> [1]:https://java.net/jira/browse/JAX_WS-945 > > >> [2]:http://hg.openjdk.java.net/jdk6/jdk6/jaxws/file/48972b9b6536/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java#l82 > > > > > > > > Yes, this is a problem with the way Sun/Oracle maintain JAXP and JAXWS; the > sources > are bulk updated outside of security updates, so there's no log of changes. > At least > now they do keep the sources in the OpenJDK tree rather than as external zip > files... > > To this end, the only log I get for this file in OpenJDK 7 is: > > $ hg log -R ../../jdk7/jaxws > ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > changeset: 321:913b9e4d8c51 > user: ohair > date: Sun May 13 11:14:50 2012 -0700 > summary: 7150322: Stop using drop source bundles in jaxws > > which is pretty unhelpful. However, the diff between the 6 and 7 versions of > the > file is pretty close to your patch: > > $ diff -u > ../jaxws/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > --- > ../jaxws/drop_included/jaxws_src/src/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > 2013-09-10 18:09:25.743193221 +0100 > +++ > ../../jdk7/jaxws/src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java > 2012-05-14 05:03:15.000000000 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -22,6 +22,7 @@ > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > + > package com.sun.xml.internal.ws.transport.http.server; > > import com.sun.net.httpserver.HttpContext; > @@ -79,7 +80,8 @@ > state = servers.get(inetAddress); > if (state == null) { > logger.fine("Creating new HTTP Server at "+inetAddress); > - server = HttpServer.create(inetAddress, 5); > + // Creates server with default socket backlog > + server = HttpServer.create(inetAddress, 0); > server.setExecutor(Executors.newCachedThreadPool()); > String path = url.toURI().getPath(); > logger.fine("Creating HTTP Context at = "+path); > > I'm happy to file an OpenJDK 6 bug for this and apply that patch, unless > someone else has any objections. > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > I didn't see any objections, so done as: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/ff5dc052d805 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kubota.yuji at lab.ntt.co.jp Thu Dec 25 00:44:35 2014 From: kubota.yuji at lab.ntt.co.jp (KUBOTA Yuji) Date: Thu, 25 Dec 2014 09:44:35 +0900 Subject: The socket backlog of HttpServer is still low. In-Reply-To: <277118171.1022279.1419446711569.JavaMail.zimbra@redhat.com> References: <546EB98A.6050605@lab.ntt.co.jp> <5473214B.2060605@azulsystems.com> <548EAEFE.5060308@lab.ntt.co.jp> <1729969623.367439.1418649469193.JavaMail.zimbra@redhat.com> <277118171.1022279.1419446711569.JavaMail.zimbra@redhat.com> Message-ID: <549B5DF3.6020005@lab.ntt.co.jp> Hi Andrew and all, On 2014/12/25 3:45, Andrew Hughes wrote: > I didn't see any objections, so done as: > > http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/ff5dc052d805 Thank you for all your help! Happy Holidays! :) Yuji