Do not JDK-6967684 backport to JDK6?
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: Do not JDK-6967684 backport to JDK6?
Thank you for response and CC to proper ml :) I hope to backport this patch if there is no specific reason to block. Yuji (2014/07/04 20:46), Ivan Krylov wrote: 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: Do not JDK-6967684 backport to JDK6?
(2014/07/17 1:20 JST), Omair Majid wrote: > Bug and patch look straight-forward and correct. No objections from me. Thank you for your help! and sorry for delayed reply. I do not have any role of OpenJDK projects. So, can someone please backport of JDK-6967684 to JDK6? Best regards, KUBOTA Yuji.
Re: Do not JDK-6967684 backport to JDK6?
(2014/07/25 23:46, JST), Omair Majid wrote: I have pushed it: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/2d334ea351f0 Many thanks for your time and help!! Cheers, Yuji KUBOTA.
Potential infinite waiting at JMXConnection#createConnection
Hi all,
I found an infinite waiting at TCPChannel#createConnection.
This method flushes the DataOutputStream without the socket timeout settings
when choose stream protocol [1].
If connection lost (the destination server do no return response)
during the flush,
this method has possibilities to take long time beyond the expectations
at java.net.SocketInputStream.socketRead0 as following stack trace.
stack trace :
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java)
at sun.security.ssl.InputRecord.readFully(InputRecord.java)
at sun.security.ssl.InputRecord.read(InputRecord.java)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
at java.io.DataOutputStream.flush(DataOutputStream.java)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
at
javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
When create connection, we cannot set the timeout by properties.
Therefore, JMX sets
the default value of SO_TIMEOUT, i.e., infinite. So I wrote a patch to
fix this infinite
waiting by using property-configured value:
sun.rmi.transport.tcp.responseTimeout.
Please review this patch. :)
Note: My OCA has been processed a few hour ago, so my name may take a
short time to
appear on the OCA signatories page.
Thanks,
KUBOTA Yuji
[1]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
--- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
+++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
@@ -222,20 +222,34 @@
// choose protocol (single op if not reusable socket)
if (!conn.isReusable()) {
out.writeByte(TransportConstants.SingleOpProtocol);
} else {
out.writeByte(TransportConstants.StreamProtocol);
+
+int usableSoTimeout = 0;
+try {
+/*
+ * If socket factory had set a zero timeout on its own,
+ * then set the property-configured value to prevent
+ * an infinite waiting.
+ */
+usableSoTimeout = sock.getSoTimeout();
+if (usableSoTimeout == 0) {
+ usableSoTimeout = responseTimeout;
+}
+sock.setSoTimeout(usableSoTimeout);
+} catch (Exception e) {
+// if we fail to set this, ignore and proceed anyway
+}
out.flush();
/*
* Set socket read timeout to configured value for JRMP
* connection handshake; this also serves to guard against
* non-JRMP servers that do not respond (see 4322806).
*/
-int originalSoTimeout = 0;
try {
-originalSoTimeout = sock.getSoTimeout();
sock.setSoTimeout(handshakeTimeout);
} catch (Exception e) {
// if we fail to set this, ignore and proceed anyway
}
@@ -279,18 +293,11 @@
* connection. NOTE: this timeout, if configured to a
* finite duration, places an upper bound on the time
* that a remote method call is permitted to execute.
*/
try {
-/*
- * If socket factory had set a non-zero timeout on its
- * own, then restore it instead of using the property-
- * configured value
Re: Potential infinite waiting at JMXConnection#createConnection
Hi all,
I want to contribute this issue.
If there are a problem about this patch or a better way for openjdk
community, please advise me.
Thanks for
2015-04-22 0:31 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I found an infinite waiting at TCPChannel#createConnection.
> This method flushes the DataOutputStream without the socket timeout settings
> when choose stream protocol [1].
>
> If connection lost (the destination server do no return response)
> during the flush,
> this method has possibilities to take long time beyond the expectations
> at java.net.SocketInputStream.socketRead0 as following stack trace.
>
> stack trace :
> at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at java.net.SocketInputStream.read(SocketInputStream.java)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java)
> at sun.security.ssl.InputRecord.read(InputRecord.java)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
> at java.io.DataOutputStream.flush(DataOutputStream.java)
> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
> at
> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
> at
> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
>
> When create connection, we cannot set the timeout by properties.
> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite.
> So I wrote a patch to fix this infinite waiting by using property-configured
> value:
> sun.rmi.transport.tcp.responseTimeout.
>
> Please review this patch. :)
>
> Note: My OCA has been processed a few hour ago, so my name may take a
> short time to
> appear on the OCA signatories page.
>
> Thanks,
> KUBOTA Yuji
>
> [1]:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
>
> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> @@ -222,20 +222,34 @@
> // choose protocol (single op if not reusable socket)
> if (!conn.isReusable()) {
> out.writeByte(TransportConstants.SingleOpProtocol);
> } else {
> out.writeByte(TransportConstants.StreamProtocol);
> +
> +int usableSoTimeout = 0;
> +try {
> +/*
> + * If socket factory had set a zero timeout on its
> own,
> + * then set the property-configured value to prevent
> + * an infinite waiting.
> + */
> +usableSoTimeout = sock.getSoTimeout();
> +if (usableSoTimeout == 0) {
> + usableSoTimeout = responseTimeout;
> +}
> +sock.setSoTimeout(usableSoTimeout);
> +} catch (Exception e) {
> +// if we fail to set this, ignore and proceed anyway
> +}
> out.flush();
>
> /*
> * Set socket read timeout to configured value for JRMP
> * connection handshake; this also serves to guard
> against
> * non-JRMP servers that do not respond (see 4322806).
> */
> -int originalSoTimeout = 0;
> try {
> -originalSoTimeout = sock.getSoTimeout();
> sock.setSoTimeout(handshakeTimeout);
> } catch (Exception e) {
> // if we fail to
Re: Potential infinite waiting at JMXConnection#createConnection
Hi all,
My apologies for the re-post and wrong link, the link [1] of the
initial post is not correctly.
The correct link is below.
[1]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227
The users cant specify the timeout by
sun.rmi.transport.tcp.responseTimeout, e.g. the second flush() of
TCPChannel#createConnection [2].
However, the first flush() [1] is not affected by
sun.rmi.transport.tcp.responseTimeout, and will be the (potential)
infinite waiting by bad luck.
[2]:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l296
Thanks,
Yuji
2015-05-05 1:19 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I want to contribute this issue.
> If there are a problem about this patch or a better way for openjdk
> community, please advise me.
>
> Thanks for
>
> 2015-04-22 0:31 GMT+09:00 KUBOTA Yuji :
>> Hi all,
>>
>> I found an infinite waiting at TCPChannel#createConnection.
>> This method flushes the DataOutputStream without the socket timeout settings
>> when choose stream protocol [1].
>>
>> If connection lost (the destination server do no return response)
>> during the flush,
>> this method has possibilities to take long time beyond the expectations
>> at java.net.SocketInputStream.socketRead0 as following stack trace.
>>
>> stack trace :
>> at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
>> at java.net.SocketInputStream.read(SocketInputStream.java)
>> at java.net.SocketInputStream.read(SocketInputStream.java)
>> at sun.security.ssl.InputRecord.readFully(InputRecord.java)
>> at sun.security.ssl.InputRecord.read(InputRecord.java)
>> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
>> at
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
>> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
>> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
>> at
>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
>> at java.io.DataOutputStream.flush(DataOutputStream.java)
>> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
>> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
>> at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
>> at
>> javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
>> at
>> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
>> at
>> javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
>>
>> When create connection, we cannot set the timeout by properties.
>> Therefore, JMX sets the default value of SO_TIMEOUT, i.e., infinite.
>> So I wrote a patch to fix this infinite waiting by using property-configured
>> value:
>> sun.rmi.transport.tcp.responseTimeout.
>>
>> Please review this patch. :)
>>
>> Note: My OCA has been processed a few hour ago, so my name may take a
>> short time to
>> appear on the OCA signatories page.
>>
>> Thanks,
>> KUBOTA Yuji
>>
>> [1]:
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
>>
>> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
>> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
>> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
>> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
>> @@ -222,20 +222,34 @@
>> // choose protocol (single op if not reusable socket)
>> if (!conn.isReusable()) {
>> out.writeByte(TransportConstants.SingleOpProtocol);
>> } else {
>> out.writeByte(TransportConstants.StreamProtocol);
>> +
>> +int usableSoTimeout = 0;
>> +try {
>> +/*
>> + * If socket factory had set a zero timeout on its
>> own,
>> + * then set the property-configured value to prevent
>> + * an infinite waiting.
>> + */
Unexpected BindException in Endpoint.publish
Hi all,
I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
community. This's second times from JavaOne14. :)
We find an unexpected exception in JAX-WS, so I write a patch to fix it.
We think that this issue may block the migration to JDK9 from JDK7.
If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
following test code, JDK9 (and JDK8) returns "java.net.BindException:
Address already in use.” as the below. But JDK7 does NOT return the
exception.
- Test code for reproduce
---
import javax.jws.*;
import javax.xml.ws.*;
public class WSTest{
@WebService
public static class Method1{
@WebMethod
public String getMethod1Value(){
return "from Method1";
}
}
@WebService
public static class Method2{
@WebMethod
public String getMethod2Value(){
return "from Method2";
}
}
public static void main(String[] args) throws Exception{
Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1";,
new Method1());
Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2";,
new Method2());
System.out.println("Sleep 3 secs...");
Thread.sleep(3000);
endPoint2.stop();
endPoint1.stop();
}
}
---
- StackTrace
---
Exception in thread "main"
com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
Error: java.net.BindException: Address already in use
at
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
at
com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
at
com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
at
com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
at wstest.WSTest.main(WSTest.java:27)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:432)
at sun.nio.ch.Net.bind(Net.java:424)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
at sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
at
sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
at
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
... 5 more
-
To publishes the Endpoint, JAX-WS checks whether the HttpContext has
been created by given address, then creates a HttpContext if do not
exist.
If we sets 0.0.0.0 as given address, JAX-WS checks by
ServerSocket#getLocalSocketAddress() (server local address), so
returns BindException when 0.0.0.0 has been blinded already.
Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think
about above situation. And JAX_WS-941 does not back port to JDK7.
So I write a patch which is based jdk9/dev/jaxws (changeset:
637:2d84c6f4cbba) to fix the BindException with JAX_WS-941.
Please review this patch :)
[1]: https://java.net/jira/browse/JAX_WS-941
- Patch
---
diff -r 2d84c6f4cbba
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
---
a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Thu Oct 22 08:47:47 2015 -0700
+++
b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Tue Oct 27 19:48:35 2015 +0900
@@ -38,6 +38,7 @@
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.logging.Logger;
+import java.util.Optional;
/**
* Manages all the WebService HTTP servers created by JAXWS runtime.
@@ -81,24 +82,38 @@
synchronized(servers) {
state = servers.get(inetAddress);
if (state == null) {
-logger.fine("Creating new HTTP Server at "+inetAddress);
-// 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);
-HttpContext context = server.createContext(path);
-server.start();
+final int finalPortNum = port;
+Optional stateOpt =
+ servers.values()
+
[PING] Re: Unexpected BindException in Endpoint.publish
Hi all,
Please review this issue and patch.
Thanks,
Yuji
2015-10-29 3:22 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
> community. This's second times from JavaOne14. :)
>
> We find an unexpected exception in JAX-WS, so I write a patch to fix it.
> We think that this issue may block the migration to JDK9 from JDK7.
>
> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
> following test code, JDK9 (and JDK8) returns "java.net.BindException:
> Address already in use.” as the below. But JDK7 does NOT return the
> exception.
>
> - Test code for reproduce
> ---
> import javax.jws.*;
> import javax.xml.ws.*;
>
> public class WSTest{
>
> @WebService
> public static class Method1{
> @WebMethod
> public String getMethod1Value(){
> return "from Method1";
> }
> }
>
> @WebService
> public static class Method2{
> @WebMethod
> public String getMethod2Value(){
> return "from Method2";
> }
> }
>
> public static void main(String[] args) throws Exception{
> Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1";,
> new
> Method1());
> Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2";,
> new
> Method2());
>
> System.out.println("Sleep 3 secs...");
>
> Thread.sleep(3000);
>
> endPoint2.stop();
> endPoint1.stop();
> }
>
> }
> ---
>
> - StackTrace
> ---
> Exception in thread "main"
> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
> Error: java.net.BindException: Address already in use
> at
> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
> at
> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
> at
> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
> at
> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
> at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
> at wstest.WSTest.main(WSTest.java:27)
> Caused by: java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:432)
> at sun.nio.ch.Net.bind(Net.java:424)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
> at sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
> at
> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
> at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
> at
> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
> ... 5 more
> -
>
> To publishes the Endpoint, JAX-WS checks whether the HttpContext has
> been created by given address, then creates a HttpContext if do not
> exist.
> If we sets 0.0.0.0 as given address, JAX-WS checks by
> ServerSocket#getLocalSocketAddress() (server local address), so
> returns BindException when 0.0.0.0 has been blinded already.
>
> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think
> about above situation. And JAX_WS-941 does not back port to JDK7.
>
> So I write a patch which is based jdk9/dev/jaxws (changeset:
> 637:2d84c6f4cbba) to fix the BindException with JAX_WS-941.
> Please review this patch :)
>
> [1]: https://java.net/jira/browse/JAX_WS-941
>
> - Patch
> ---
> diff -r 2d84c6f4cbba
> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
> ---
> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
> Thu Oct 22 08:47:47 2015 -0700
> +++
> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
> Tue Oct 27 19:48:35 2015 +0900
> @@ -38,6 +38,7 @@
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.logging.Logger;
> +import java.util.Optional;
>
> /**
> * Manages all the WebService HTTP servers created by JAXWS runtime.
> @@ -81,24 +82,38 @@
> synchronized(servers)
Re: [PING] Re: Unexpected BindException in Endpoint.publish
2015-12-01 17:53 GMT+09:00 Alan Bateman : > This is JAX-WS so any changes to this code will probably need to go get > pushed to the upstream project too. Best to send it to core-libs-dev (as the > EE/JAX-* areas don't have their own mailing list here). Miroslav Kos is on > that mailing list and is able to get changes pushed upstream. Hi Alan, I apologize for the inconvenience and thank you for your kindness. I will send it to best ml. Thanks, Yuji
Re: [DONG] Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection
Hi David,
Thank you for your advice and cc-ing!
I do not have any role yet, so I paste my patches as below.
diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
--- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
+++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
@@ -222,20 +222,34 @@
// choose protocol (single op if not reusable socket)
if (!conn.isReusable()) {
out.writeByte(TransportConstants.SingleOpProtocol);
} else {
out.writeByte(TransportConstants.StreamProtocol);
+
+int usableSoTimeout = 0;
+try {
+/*
+ * If socket factory had set a non-zero timeout on its
+ * own, then restore it instead of using the property-
+ * configured value.
+ */
+usableSoTimeout = sock.getSoTimeout();
+if (usableSoTimeout == 0) {
+ usableSoTimeout = responseTimeout;
+}
+sock.setSoTimeout(usableSoTimeout);
+} catch (Exception e) {
+// if we fail to set this, ignore and proceed anyway
+}
out.flush();
/*
* Set socket read timeout to configured value for JRMP
* connection handshake; this also serves to guard against
* non-JRMP servers that do not respond (see 4322806).
*/
-int originalSoTimeout = 0;
try {
-originalSoTimeout = sock.getSoTimeout();
sock.setSoTimeout(handshakeTimeout);
} catch (Exception e) {
// if we fail to set this, ignore and proceed anyway
}
@@ -279,18 +293,11 @@
* connection. NOTE: this timeout, if configured to a
* finite duration, places an upper bound on the time
* that a remote method call is permitted to execute.
*/
try {
-/*
- * If socket factory had set a non-zero timeout on its
- * own, then restore it instead of using the property-
- * configured value.
- */
-sock.setSoTimeout((originalSoTimeout != 0 ?
- originalSoTimeout :
- responseTimeout));
+sock.setSoTimeout(usableSoTimeout);
} catch (Exception e) {
// if we fail to set this, ignore and proceed anyway
}
out.flush();
Thanks,
Yuji
2016-02-09 13:11 GMT+09:00 David Holmes :
> Hi Yuji,
>
> Not sure who would look at this so cc'ing net-dev.
>
> Also note that contributions can only be accepted if presented via OpenJKDK
> infrastructure. Links to patches on http://icedtea.classpath.org are not
> acceptable. The patch needs to be included in the email (beware stripped
> attachments) if you can't get it hosted on cr.openjdk.java.net. Sorry.
>
> David
>
>
> On 9/02/2016 12:10 AM, KUBOTA Yuji wrote:
>>
>> Hi all,
>>
>> Could someone review this fix?
>>
>> Thanks,
>> Yuji
>>
>> 2016-02-04 2:27 GMT+09:00 KUBOTA Yuji :
>>>
>>> Hi all,
>>>
>>> Could someone please review and sponsor this fix ?
>>> I write the details of this issue again. Please review it.
>>>
>>> =Problem=
>>> Potential infinite waiting at TCPChannel#createConnection.
>>>
>>> This method flushes the DataOutputStream without the socket
>>> timeout settings when choose stream protocol [1]. If connection lost
>>> or the destination server do not return response during the flush,
>>> this method wait forever because the timeout settings is set the
>>> default value of SO_TIMEOUT, i.e., infinite.
>>>
>>> [1]:
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/7adef1c3afd5/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java#l227
>>>
>>> I think this issue is rarely, however serious.
>>>
>>> =Reproduce=
>>> I write a test program to reproduce. You can reproduce by the below.
>>>
>>> * hg clone
>>> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/
&
Re: [DONG] Re: [DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection
Hi all,
Could someone please review this patch?
Thanks,
Yuji
2016-02-09 15:50 GMT+09:00 KUBOTA Yuji :
> Hi David,
>
> Thank you for your advice and cc-ing!
>
> I do not have any role yet, so I paste my patches as below.
>
> diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
> @@ -222,20 +222,34 @@
> // choose protocol (single op if not reusable socket)
> if (!conn.isReusable()) {
> out.writeByte(TransportConstants.SingleOpProtocol);
> } else {
> out.writeByte(TransportConstants.StreamProtocol);
> +
> +int usableSoTimeout = 0;
> +try {
> +/*
> + * If socket factory had set a non-zero timeout on
> its
> + * own, then restore it instead of using the
> property-
> + * configured value.
> + */
> +usableSoTimeout = sock.getSoTimeout();
> +if (usableSoTimeout == 0) {
> + usableSoTimeout = responseTimeout;
> +}
> +sock.setSoTimeout(usableSoTimeout);
> +} catch (Exception e) {
> +// if we fail to set this, ignore and proceed anyway
> +}
> out.flush();
>
> /*
> * Set socket read timeout to configured value for JRMP
> * connection handshake; this also serves to guard
> against
> * non-JRMP servers that do not respond (see 4322806).
> */
> -int originalSoTimeout = 0;
> try {
> -originalSoTimeout = sock.getSoTimeout();
> sock.setSoTimeout(handshakeTimeout);
> } catch (Exception e) {
> // if we fail to set this, ignore and proceed anyway
> }
>
> @@ -279,18 +293,11 @@
> * connection. NOTE: this timeout, if configured to a
> * finite duration, places an upper bound on the time
> * that a remote method call is permitted to execute.
> */
> try {
> -/*
> - * If socket factory had set a non-zero timeout on
> its
> - * own, then restore it instead of using the
> property-
> - * configured value.
> - */
> -sock.setSoTimeout((originalSoTimeout != 0 ?
> - originalSoTimeout :
> - responseTimeout));
> +sock.setSoTimeout(usableSoTimeout);
> } catch (Exception e) {
> // if we fail to set this, ignore and proceed anyway
> }
>
> out.flush();
>
> Thanks,
> Yuji
>
> 2016-02-09 13:11 GMT+09:00 David Holmes :
>> Hi Yuji,
>>
>> Not sure who would look at this so cc'ing net-dev.
>>
>> Also note that contributions can only be accepted if presented via OpenJKDK
>> infrastructure. Links to patches on http://icedtea.classpath.org are not
>> acceptable. The patch needs to be included in the email (beware stripped
>> attachments) if you can't get it hosted on cr.openjdk.java.net. Sorry.
>>
>> David
>>
>>
>> On 9/02/2016 12:10 AM, KUBOTA Yuji wrote:
>>>
>>> Hi all,
>>>
>>> Could someone review this fix?
>>>
>>> Thanks,
>>> Yuji
>>>
>>> 2016-02-04 2:27 GMT+09:00 KUBOTA Yuji :
>>>>
>>>> Hi all,
>>>>
>>>> Could someone please review and sponsor this fix ?
>>>> I write the details of this issue again. Please review it.
>>>>
>>>> =Problem=
>>>> Potential infinite waiting at TCPChannel#createConnection.
>>>>
>>>> This method flushes the DataOutputStream without the socket
>>>> timeout settings when choose stream protocol [1]. If connection lost
>>>> or the destination server do not return response duri
httpserver does not close connections when RejectedExecutionException occurs
Hi all,
com.sun.net.httpserver in jdk9 does not catch
RejectedExecutionException and it does not close connections. We must
catch this exception to close a socket.
Please review the following patch and reproduce steps.
If you agree with that this is an issue of jdk9, I create a new issue
on JBS. (I'm author)
* patch
diff --git a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
--- a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
+++ b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
@@ -442,10 +442,13 @@
logger.log (Level.TRACE, "Dispatcher (4)", e1);
closeConnection(conn);
} catch (IOException e) {
logger.log (Level.TRACE, "Dispatcher (5)", e);
closeConnection(conn);
+} catch (RejectedExecutionException e) {
+logger.log (Level.TRACE, "Dispatcher (9)", e);
+closeConnection(conn);
}
}
}
_
static boolean debug = ServerConfig.debugEnabled ();
* steps to reproduce
1. java -Djava.util.logging.config.file=logging.properties SmallHttpServer
2. post tcp connections by curl or other ways
e.g.: while true; do curl -XPOST --noproxy 127.0.0.1
http://127.0.0.1:8080/; done
3. wait RejectedExecutionException occurs as below and then
SmallHttpServer stops by this issue.
Nov 05, 2016 12:01:48 PM sun.net.httpserver.ServerImpl$Dispatcher run
FINER: Dispatcher (7)
java.util.concurrent.RejectedExecutionException: Task
sun.net.httpserver.ServerImpl$Exchange@37b50d9e rejected from
java.util.concurrent.ThreadPoolExecutor@1b3178d4[Running, pool size =
1, active threads = 0, queued tasks = 0, completed tasks = 7168]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(java.base/ThreadPoolExecutor.java:2076)
at
java.util.concurrent.ThreadPoolExecutor.reject(java.base/ThreadPoolExecutor.java:842)
at
java.util.concurrent.ThreadPoolExecutor.execute(java.base/ThreadPoolExecutor.java:1388)
at
sun.net.httpserver.ServerImpl$Dispatcher.handle(jdk.httpserver/ServerImpl.java:440)
at
sun.net.httpserver.ServerImpl$Dispatcher.run(jdk.httpserver/ServerImpl.java:405)
at java.lang.Thread.run(java.base/Thread.java:844)
(SmallHttpServer is stopping by not closing socket)
*logging.properties
handlers = java.util.logging.ConsoleHandler
com.sun.net.httpserver.level = FINEST
java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
* SmallHttpServer.java
import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpServer;
import java.net.InetSocketAddress;
import java.util.Scanner;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class SmallHttpServer {
public static void main(String[] args) throws Exception {
int POOL_SIZE = 1;
String HOST = args.length < 1 ? "127.0.0.1" : args[0];
int PORT = args.length < 2 ? 8080 : Integer.valueOf(args[1]);
// Setup a minimum thread pool to rise
RejectExecutionException in httpserver
ThreadPoolExecutor miniHttpPoolExecutor
= new ThreadPoolExecutor(POOL_SIZE, POOL_SIZE, 0L,
TimeUnit.MICROSECONDS,
new LinkedBlockingQueue<>(1), (Runnable r) -> {
return new Thread(r);
});
HttpServer httpServer = HttpServer.create(new
InetSocketAddress(HOST, PORT), 0);
httpServer.setExecutor(miniHttpPoolExecutor);
HttpHandler res200handler = (HttpExchange exchange) -> {
exchange.sendResponseHeaders(200, 0);
exchange.close();
};
httpServer.createContext("/", res200handler);
httpServer.start();
// Wait stdin to exit
Scanner in = new Scanner(System.in);
while (in.hasNext()) {
System.out.println(in.nextLine());
}
httpServer.stop(0);
miniHttpPoolExecutor.shutdownNow();
}
}
Thanks,
Yuji
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Chris,
Thank you for your review and updating this issues on JBS.
I filed an issue:
https://bugs.openjdk.java.net/browse/JDK-8169358
I don't assign to me because I'm not a committer.
2016-11-08 0:28 GMT+09:00 Chris Hegarty :
>> * patch
>> diff --git
>> a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>> b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>> --- a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>> +++ b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>> @@ -442,10 +442,13 @@
>> logger.log (Level.TRACE, "Dispatcher (4)", e1);
>> closeConnection(conn);
>> } catch (IOException e) {
>> logger.log (Level.TRACE, "Dispatcher (5)", e);
>> closeConnection(conn);
>> +} catch (RejectedExecutionException e) {
>> +logger.log (Level.TRACE, "Dispatcher (9)", e);
>> +closeConnection(conn);
>> }
>> }
>> }
>> _
>> static boolean debug = ServerConfig.debugEnabled ();
>
>
> This looks ok. I wonder if some of these exceptions could be refactored
> into a catch clause with several exception types?
Yes, I agree to keep simple. I updated my patch as below.
http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
Could you review it again?
Thank you,
Yuji
>
> -Chris.
>
>
>
>> * steps to reproduce
>> 1. java -Djava.util.logging.config.file=logging.properties
>> SmallHttpServer
>> 2. post tcp connections by curl or other ways
>> e.g.: while true; do curl -XPOST --noproxy 127.0.0.1
>> http://127.0.0.1:8080/; done
>> 3. wait RejectedExecutionException occurs as below and then
>> SmallHttpServer stops by this issue.
>>
>> Nov 05, 2016 12:01:48 PM sun.net.httpserver.ServerImpl$Dispatcher run
>> FINER: Dispatcher (7)
>> java.util.concurrent.RejectedExecutionException: Task
>> sun.net.httpserver.ServerImpl$Exchange@37b50d9e rejected from
>> java.util.concurrent.ThreadPoolExecutor@1b3178d4[Running, pool size =
>> 1, active threads = 0, queued tasks = 0, completed tasks = 7168]
>> at
>> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(java.base/ThreadPoolExecutor.java:2076)
>> at
>> java.util.concurrent.ThreadPoolExecutor.reject(java.base/ThreadPoolExecutor.java:842)
>> at
>> java.util.concurrent.ThreadPoolExecutor.execute(java.base/ThreadPoolExecutor.java:1388)
>> at
>> sun.net.httpserver.ServerImpl$Dispatcher.handle(jdk.httpserver/ServerImpl.java:440)
>> at
>> sun.net.httpserver.ServerImpl$Dispatcher.run(jdk.httpserver/ServerImpl.java:405)
>> at java.lang.Thread.run(java.base/Thread.java:844)
>> (SmallHttpServer is stopping by not closing socket)
>>
>>
>> *logging.properties
>> handlers = java.util.logging.ConsoleHandler
>> com.sun.net.httpserver.level = FINEST
>> java.util.logging.ConsoleHandler.level = FINEST
>> java.util.logging.ConsoleHandler.formatter =
>> java.util.logging.SimpleFormatter
>>
>> * SmallHttpServer.java
>> import com.sun.net.httpserver.HttpExchange;
>> import com.sun.net.httpserver.HttpHandler;
>> import com.sun.net.httpserver.HttpServer;
>>
>> import java.net.InetSocketAddress;
>> import java.util.Scanner;
>> import java.util.concurrent.LinkedBlockingQueue;
>> import java.util.concurrent.ThreadPoolExecutor;
>> import java.util.concurrent.TimeUnit;
>>
>> public class SmallHttpServer {
>>
>> public static void main(String[] args) throws Exception {
>> int POOL_SIZE = 1;
>> String HOST = args.length < 1 ? "127.0.0.1" : args[0];
>> int PORT = args.length < 2 ? 8080 : Integer.valueOf(args[1]);
>>
>> // Setup a minimum thread pool to rise
>> RejectExecutionException in httpserver
>> ThreadPoolExecutor miniHttpPoolExecutor
>> = new ThreadPoolExecutor(POOL_SIZE, POOL_SIZE, 0L,
>> TimeUnit.MICROSECONDS,
>> new LinkedBlockingQueue<>(1), (Runnable r) -> {
>> return new Thread(r);
>> });
>> HttpServer httpServer = HttpServer.create(new
>> InetSocketAddress(HOST, PORT), 0);
>> httpServer.setExecutor(miniHttpPoolExecutor);
>>
>> HttpHandler res200handler = (HttpExchange exchange) -> {
>> exchange.sendResponseHeaders(200, 0);
>> exchange.close();
>> };
>> httpServer.createContext("/", res200handler);
>>
>> httpServer.start();
>> // Wait stdin to exit
>> Scanner in = new Scanner(System.in);
>> while (in.hasNext()) {
>> System.out.println(in.nextLine());
>> }
>> httpServer.stop(0);
>> miniHttpPoolExecutor.shutdownNow();
>> }
>> }
>>
>>
>> Thanks,
>> Yuji
>>
>
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Chris,
If I can add reproduce code as test, could you please teach me a hint to add it?
Thanks,
Yuji.
2016-11-08 18:53 GMT+09:00 KUBOTA Yuji :
> Hi Chris,
>
> Thank you for your review and updating this issues on JBS.
>
> I filed an issue:
> https://bugs.openjdk.java.net/browse/JDK-8169358
>
> I don't assign to me because I'm not a committer.
>
> 2016-11-08 0:28 GMT+09:00 Chris Hegarty :
>>> * patch
>>> diff --git
>>> a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>> b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>> --- a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>> +++ b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>> @@ -442,10 +442,13 @@
>>> logger.log (Level.TRACE, "Dispatcher (4)", e1);
>>> closeConnection(conn);
>>> } catch (IOException e) {
>>> logger.log (Level.TRACE, "Dispatcher (5)", e);
>>> closeConnection(conn);
>>> +} catch (RejectedExecutionException e) {
>>> +logger.log (Level.TRACE, "Dispatcher (9)", e);
>>> +closeConnection(conn);
>>> }
>>> }
>>> }
>>> _
>>> static boolean debug = ServerConfig.debugEnabled ();
>>
>>
>> This looks ok. I wonder if some of these exceptions could be refactored
>> into a catch clause with several exception types?
>
> Yes, I agree to keep simple. I updated my patch as below.
> http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
> Could you review it again?
>
> Thank you,
> Yuji
>>
>> -Chris.
>>
>>
>>
>>> * steps to reproduce
>>> 1. java -Djava.util.logging.config.file=logging.properties
>>> SmallHttpServer
>>> 2. post tcp connections by curl or other ways
>>> e.g.: while true; do curl -XPOST --noproxy 127.0.0.1
>>> http://127.0.0.1:8080/; done
>>> 3. wait RejectedExecutionException occurs as below and then
>>> SmallHttpServer stops by this issue.
>>>
>>> Nov 05, 2016 12:01:48 PM sun.net.httpserver.ServerImpl$Dispatcher run
>>> FINER: Dispatcher (7)
>>> java.util.concurrent.RejectedExecutionException: Task
>>> sun.net.httpserver.ServerImpl$Exchange@37b50d9e rejected from
>>> java.util.concurrent.ThreadPoolExecutor@1b3178d4[Running, pool size =
>>> 1, active threads = 0, queued tasks = 0, completed tasks = 7168]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(java.base/ThreadPoolExecutor.java:2076)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.reject(java.base/ThreadPoolExecutor.java:842)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.execute(java.base/ThreadPoolExecutor.java:1388)
>>> at
>>> sun.net.httpserver.ServerImpl$Dispatcher.handle(jdk.httpserver/ServerImpl.java:440)
>>> at
>>> sun.net.httpserver.ServerImpl$Dispatcher.run(jdk.httpserver/ServerImpl.java:405)
>>> at java.lang.Thread.run(java.base/Thread.java:844)
>>> (SmallHttpServer is stopping by not closing socket)
>>>
>>>
>>> *logging.properties
>>> handlers = java.util.logging.ConsoleHandler
>>> com.sun.net.httpserver.level = FINEST
>>> java.util.logging.ConsoleHandler.level = FINEST
>>> java.util.logging.ConsoleHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>>
>>> * SmallHttpServer.java
>>> import com.sun.net.httpserver.HttpExchange;
>>> import com.sun.net.httpserver.HttpHandler;
>>> import com.sun.net.httpserver.HttpServer;
>>>
>>> import java.net.InetSocketAddress;
>>> import java.util.Scanner;
>>> import java.util.concurrent.LinkedBlockingQueue;
>>> import java.util.concurrent.ThreadPoolExecutor;
>>> import java.util.concurrent.TimeUnit;
>>>
>>> public class SmallHttpServer {
>>>
>>> public static void main(String[] args) throws Exception {
>>> int POOL_SIZE = 1;
>>> String HOST = args.length < 1 ? "127.0.0.1" : args[0];
>>> int PORT = args.length < 2 ? 8080 : Integer.valueOf(args[1]);
>>>
>>> // Setup a minimum thread pool to rise
>>> RejectExecutionException in httpserver
>>> ThreadPoolExecutor miniHttpPoolExec
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Chris and Yasumasa,
Thank you for your comments!
I had faced connection leak on production by this handler. It seems
like a corner-case but it's a real risk to me.
I had focused REE on this issue, but it is a subclass of
RuntimeException, so I think that we should investigate
RuntimeException, too.
If Chris agrees with the covering RuntimeException by JDK-8169358, I
will investigate it and update my patch.
If we should investigate on another issue, I want to add a test case
to check fixing about REE like existing jtreg, and I will create a new
issue after an investigation about RuntimeException.
Any thoughts?
Thank you!
Yuji
2016-11-11 0:56 GMT+09:00 Chris Hegarty :
>
>> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote:
>>
>> Hi,
>>
>>> I think it best to just handle the specific case of REE, as it done in
>>> Yuji’s patch.
>>
>> Will it be a cause of connection leak if RuntimeException is occurred in
>> handler method?
>
> No, at least not from this point in the code.
>
>> I think we should catch RuntimeException at least.
>
> Possibly, but it seems like a corner-case of a corner-case.
>
>>>> I think you can use finally statement to close the connection in this case.
>>>
>>> I don’t believe that this is possible. The handling of the connection may be
>>> done in a separate thread, some time after execute() returns.
>>
>> So I said we need to check the implementation of HTTP connection and
>> dispatcher.
>
> To me, this goes beyond the scope of the issue describe in JIRA, but if
> you want to investigate that, then that’s fine.
>
> -Chris.
>
>>
>> Yasumasa
>>
>>
>> On 2016/11/10 23:00, Chris Hegarty wrote:
>>>
>>>> On 9 Nov 2016, at 12:38, Yasumasa Suenaga wrote:
>>>>
>>>> Hi Yuji,
>>>>
>>>>> http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/
>>>
>>> I think Yuji’s patch is good as is.
>>>
>>>> I think you can use finally statement to close the connection in this case.
>>>
>>> I don’t believe that this is possible. The handling of the connection may be
>>> done in a separate thread, some time after execute() returns. I think it
>>> best
>>> to just handle the specific case of REE, as it done in Yuji’s patch.
>>>
>>>> Your patch cannot close the connection when any other runtime exceptions
>>>> are occurred.
>>>>
>>>> However, it is concerned double close if custom handler which is
>>>> implemented by the user throws runtime exception after closing the
>>>> connection.
>>>> IMHO, you need to check the implementation of HTTP connection and
>>>> dispatcher.
>>>
>>> -Chris.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/11/08 18:53, KUBOTA Yuji wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thank you for your review and updating this issues on JBS.
>>>>>
>>>>> I filed an issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8169358
>>>>>
>>>>> I don't assign to me because I'm not a committer.
>>>>>
>>>>> 2016-11-08 0:28 GMT+09:00 Chris Hegarty :
>>>>>>> * patch
>>>>>>> diff --git
>>>>>>> a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>>>>>> b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>>>>>> ---
>>>>>>> a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>>>>>> +++
>>>>>>> b/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
>>>>>>> @@ -442,10 +442,13 @@
>>>>>>>logger.log (Level.TRACE, "Dispatcher (4)", e1);
>>>>>>>closeConnection(conn);
>>>>>>>} catch (IOException e) {
>>>>>>>logger.log (Level.TRACE, "Dispatcher (5)", e);
>>>>>>>closeConnection(conn);
>>>>>>> +} catch (RejectedExecutionException e) {
>>>>>>> +logger.log (Level.TRACE, "Dispatcher (9)", e);
>>>>>>> +closeConnection(conn);
>>>>>>>}
>>>>>>>}
>>>&g
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Chris and Yasumasa, Sorry to have remained this issue for a long time. I come back. I updated my patch for the following three reasons. http://cr.openjdk.java.net/~ykubota/8169358/webrev.02/ * applies to the latest jdk/jdk instead of jdk9/dev * adds test by modifying reproducer as like tests on test/jdk/com/sun/net/httpserver * prevents potential connection leak as Yasumasa said. For example, a user sets own implementation of the thread pool to HttpServer and then throws unexpected exceptions and errors. I think that we should save existing exception handler to keep compatibility and minimize the risk of connection leak by catching Throwable. I've tested test/jdk/com/sun/net/httpserver and passed. I'm not a committer, so I can not access March 5. Could you review and sponsor it? Thanks, Yuji 2016-11-11 12:11 GMT+09:00 KUBOTA Yuji : > Hi Chris and Yasumasa, > > Thank you for your comments! > > I had faced connection leak on production by this handler. It seems > like a corner-case but it's a real risk to me. > I had focused REE on this issue, but it is a subclass of > RuntimeException, so I think that we should investigate > RuntimeException, too. > > If Chris agrees with the covering RuntimeException by JDK-8169358, I > will investigate it and update my patch. > If we should investigate on another issue, I want to add a test case > to check fixing about REE like existing jtreg, and I will create a new > issue after an investigation about RuntimeException. > > Any thoughts? > > Thank you! > Yuji > > 2016-11-11 0:56 GMT+09:00 Chris Hegarty : >> >>> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote: >>> >>> Hi, >>> >>>> I think it best to just handle the specific case of REE, as it done in >>>> Yuji’s patch. >>> >>> Will it be a cause of connection leak if RuntimeException is occurred in >>> handler method? >> >> No, at least not from this point in the code. >> >>> I think we should catch RuntimeException at least. >> >> Possibly, but it seems like a corner-case of a corner-case. >> >>>>> I think you can use finally statement to close the connection in this >>>>> case. >>>> >>>> I don’t believe that this is possible. The handling of the connection may >>>> be >>>> done in a separate thread, some time after execute() returns. >>> >>> So I said we need to check the implementation of HTTP connection and >>> dispatcher. >> >> To me, this goes beyond the scope of the issue describe in JIRA, but if >> you want to investigate that, then that’s fine. >> >> -Chris. >> >>> >>> Yasumasa >>> >>> >>> On 2016/11/10 23:00, Chris Hegarty wrote: >>>> >>>>> On 9 Nov 2016, at 12:38, Yasumasa Suenaga wrote: >>>>> >>>>> Hi Yuji, >>>>> >>>>>> http://cr.openjdk.java.net/~ykubota/8169358/webrev.01/ >>>> >>>> I think Yuji’s patch is good as is. >>>> >>>>> I think you can use finally statement to close the connection in this >>>>> case. >>>> >>>> I don’t believe that this is possible. The handling of the connection may >>>> be >>>> done in a separate thread, some time after execute() returns. I think it >>>> best >>>> to just handle the specific case of REE, as it done in Yuji’s patch. >>>> >>>>> Your patch cannot close the connection when any other runtime exceptions >>>>> are occurred. >>>>> >>>>> However, it is concerned double close if custom handler which is >>>>> implemented by the user throws runtime exception after closing the >>>>> connection. >>>>> IMHO, you need to check the implementation of HTTP connection and >>>>> dispatcher. >>>> >>>> -Chris. >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/11/08 18:53, KUBOTA Yuji wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Thank you for your review and updating this issues on JBS. >>>>>> >>>>>> I filed an issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169358 >>>>>> >>>>>> I don't assign to me because I'm not a committer. >>>>>> >>>>>> 2016-11-08 0:28 GMT+
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Daniel, Thank you for your comment. Dispatcher is package-private class and handle method is called at only this file in the package (sun.net.httpserver), and all call sites look like to handle exception suitably. So we can remove `throws IOException` clause without modifying the call site logic as like webrev.03. http://cr.openjdk.java.net/~ykubota/8169358/webrev.03 However, I could not find whether can I change a signature of public method without specified steps. If we need to write CSR to remove `throws IOException` clause, we should remove the clause by other issue. And I want to commit webrev.02 at this issue. http://cr.openjdk.java.net/~ykubota/8169358/webrev.02 I'd like to get your thoughts on that. P.S. I'm an author, not a committer, so I cannot access Mach5. Thanks, Yuji 2018-02-17 1:11 GMT+09:00 Daniel Fuchs : > Hi, > > On the surface I'd say that this change looks reasonable. > However, handle is declared to throw IOException, and > with this change it is guaranteed to never throw even > RuntimeException. > > It seems that the code that calls handle() - at least in > this file, has some logic to handle IOException - or > other exception possibly thrown by Dispatcher::handle, > which as far as I can see is not doing much more than what > closeConnection does. So it looks as if calling > closeConnection in handle() instead of throwing could be OK. > > However it would be good to at least try to figure out > whether there are any other call sites for Dispatcher::handle, > validate that no longer throwing will not modify the call site > logic, and possibly investigate if the 'throws IOException' clause > can be removed from Dispatcher::handle (that is: look > whether Dispatcher is exposed and/or can be subclassed and > if there are any existing subclasses). > > best regards, > > -- daniel > > > On 16/02/2018 15:29, KUBOTA Yuji wrote: >> >> Hi Chris and Yasumasa, >> >> Sorry to have remained this issue for a long time. I come back. >> >> I updated my patch for the following three reasons. >> http://cr.openjdk.java.net/~ykubota/8169358/webrev.02/ >> >> * applies to the latest jdk/jdk instead of jdk9/dev >> * adds test by modifying reproducer as like tests on >> test/jdk/com/sun/net/httpserver >> * prevents potential connection leak as Yasumasa said. For example, a >> user sets own implementation of the thread pool to HttpServer and then >> throws unexpected exceptions and errors. I think that we should save >> existing exception handler to keep compatibility and minimize the risk >> of connection leak by catching Throwable. >> >> I've tested test/jdk/com/sun/net/httpserver and passed. >> I'm not a committer, so I can not access March 5. >> >> Could you review and sponsor it? >> >> Thanks, >> Yuji >> >> 2016-11-11 12:11 GMT+09:00 KUBOTA Yuji : >>> >>> Hi Chris and Yasumasa, >>> >>> Thank you for your comments! >>> >>> I had faced connection leak on production by this handler. It seems >>> like a corner-case but it's a real risk to me. >>> I had focused REE on this issue, but it is a subclass of >>> RuntimeException, so I think that we should investigate >>> RuntimeException, too. >>> >>> If Chris agrees with the covering RuntimeException by JDK-8169358, I >>> will investigate it and update my patch. >>> If we should investigate on another issue, I want to add a test case >>> to check fixing about REE like existing jtreg, and I will create a new >>> issue after an investigation about RuntimeException. >>> >>> Any thoughts? >>> >>> Thank you! >>> Yuji >>> >>> 2016-11-11 0:56 GMT+09:00 Chris Hegarty : >>>> >>>> >>>>> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote: >>>>> >>>>> Hi, >>>>> >>>>>> I think it best to just handle the specific case of REE, as it done in >>>>>> Yuji’s patch. >>>>> >>>>> >>>>> Will it be a cause of connection leak if RuntimeException is occurred >>>>> in handler method? >>>> >>>> >>>> No, at least not from this point in the code. >>>> >>>>> I think we should catch RuntimeException at least. >>>> >>>> >>>> Possibly, but it seems like a corner-case of a corner-case. >>>> >>>>>>> I think you can use finally statement to close the connection in this >>>>>>>
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi all, Could you please review my patch(s)? Thanks, Yuji 2018-02-20 14:21 GMT+09:00 KUBOTA Yuji : > Hi Daniel, > > Thank you for your comment. > > Dispatcher is package-private class and handle method is called at > only this file in the package (sun.net.httpserver), and all call sites > look like to handle exception suitably. So we can remove `throws > IOException` clause without modifying the call site logic as like > webrev.03. > http://cr.openjdk.java.net/~ykubota/8169358/webrev.03 > > However, I could not find whether can I change a signature of public > method without specified steps. If we need to write CSR to remove > `throws IOException` clause, we should remove the clause by other > issue. And I want to commit webrev.02 at this issue. > http://cr.openjdk.java.net/~ykubota/8169358/webrev.02 > > I'd like to get your thoughts on that. > > P.S. I'm an author, not a committer, so I cannot access Mach5. > > Thanks, > Yuji > > 2018-02-17 1:11 GMT+09:00 Daniel Fuchs : >> Hi, >> >> On the surface I'd say that this change looks reasonable. >> However, handle is declared to throw IOException, and >> with this change it is guaranteed to never throw even >> RuntimeException. >> >> It seems that the code that calls handle() - at least in >> this file, has some logic to handle IOException - or >> other exception possibly thrown by Dispatcher::handle, >> which as far as I can see is not doing much more than what >> closeConnection does. So it looks as if calling >> closeConnection in handle() instead of throwing could be OK. >> >> However it would be good to at least try to figure out >> whether there are any other call sites for Dispatcher::handle, >> validate that no longer throwing will not modify the call site >> logic, and possibly investigate if the 'throws IOException' clause >> can be removed from Dispatcher::handle (that is: look >> whether Dispatcher is exposed and/or can be subclassed and >> if there are any existing subclasses). >> >> best regards, >> >> -- daniel >> >> >> On 16/02/2018 15:29, KUBOTA Yuji wrote: >>> >>> Hi Chris and Yasumasa, >>> >>> Sorry to have remained this issue for a long time. I come back. >>> >>> I updated my patch for the following three reasons. >>> http://cr.openjdk.java.net/~ykubota/8169358/webrev.02/ >>> >>> * applies to the latest jdk/jdk instead of jdk9/dev >>> * adds test by modifying reproducer as like tests on >>> test/jdk/com/sun/net/httpserver >>> * prevents potential connection leak as Yasumasa said. For example, a >>> user sets own implementation of the thread pool to HttpServer and then >>> throws unexpected exceptions and errors. I think that we should save >>> existing exception handler to keep compatibility and minimize the risk >>> of connection leak by catching Throwable. >>> >>> I've tested test/jdk/com/sun/net/httpserver and passed. >>> I'm not a committer, so I can not access March 5. >>> >>> Could you review and sponsor it? >>> >>> Thanks, >>> Yuji >>> >>> 2016-11-11 12:11 GMT+09:00 KUBOTA Yuji : >>>> >>>> Hi Chris and Yasumasa, >>>> >>>> Thank you for your comments! >>>> >>>> I had faced connection leak on production by this handler. It seems >>>> like a corner-case but it's a real risk to me. >>>> I had focused REE on this issue, but it is a subclass of >>>> RuntimeException, so I think that we should investigate >>>> RuntimeException, too. >>>> >>>> If Chris agrees with the covering RuntimeException by JDK-8169358, I >>>> will investigate it and update my patch. >>>> If we should investigate on another issue, I want to add a test case >>>> to check fixing about REE like existing jtreg, and I will create a new >>>> issue after an investigation about RuntimeException. >>>> >>>> Any thoughts? >>>> >>>> Thank you! >>>> Yuji >>>> >>>> 2016-11-11 0:56 GMT+09:00 Chris Hegarty : >>>>> >>>>> >>>>>> On 10 Nov 2016, at 14:43, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>>> I think it best to just handle the specific case of REE, as it done in >>>>>>> Yuji’s patch. >>>>>> >>>>>> >>&
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Christoph, Thank you for your review and comment! 2018-03-06 20:38 GMT+09:00 Langer, Christoph : > I had a look and to me it seems safe to do like webrev.03 suggests. That is, > remove the throws clause. As Daniel pointed out, it seems that all callers of > the "handle" method would do merely the same. The only thing I'm not sure > about is the CancelledKeyException caught in line 413. In that case no > exception would be logged currently. With your change, it would now inside > "handle". Maybe you want to handle a CancelledKeyException explicitly in > "handle" now and suppress the log? SelectionKey::isReadable might throw CancelledKeyException in line 397, so the logging in line 413 still work except the exceptions from inside "handle". I want to handle unexpected exceptions and errors from "handle" to minimize the risk of connection leak. Separating logging also would help developers. > What tests did you run? I've tested test/jdk/com/sun/net/httpserver and passed. I can not access Mach5 because I'm not a committer. > BTW: you could remove line 396: ' boolean closed;' while you are touching > this file. It is not needed. Nice catch! I removed this unused variable. http://cr.openjdk.java.net/~ykubota/8169358/webrev.04/ Best regards Yuji > Best regards > Christoph > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of >> KUBOTA Yuji >> Sent: Donnerstag, 1. März 2018 12:41 >> To: OpenJDK Network Dev list >> Cc: Yasumasa Suenaga >> Subject: Re: httpserver does not close connections when >> RejectedExecutionException occurs >> >> Hi all, >> >> Could you please review my patch(s)? >> >> Thanks, >> Yuji >> >> 2018-02-20 14:21 GMT+09:00 KUBOTA Yuji : >> > Hi Daniel, >> > >> > Thank you for your comment. >> > >> > Dispatcher is package-private class and handle method is called at >> > only this file in the package (sun.net.httpserver), and all call sites >> > look like to handle exception suitably. So we can remove `throws >> > IOException` clause without modifying the call site logic as like >> > webrev.03. >> > http://cr.openjdk.java.net/~ykubota/8169358/webrev.03 >> > >> > However, I could not find whether can I change a signature of public >> > method without specified steps. If we need to write CSR to remove >> > `throws IOException` clause, we should remove the clause by other >> > issue. And I want to commit webrev.02 at this issue. >> > http://cr.openjdk.java.net/~ykubota/8169358/webrev.02 >> > >> > I'd like to get your thoughts on that. >> > >> > P.S. I'm an author, not a committer, so I cannot access Mach5. >> > >> > Thanks, >> > Yuji >> > >> > 2018-02-17 1:11 GMT+09:00 Daniel Fuchs : >> >> Hi, >> >> >> >> On the surface I'd say that this change looks reasonable. >> >> However, handle is declared to throw IOException, and >> >> with this change it is guaranteed to never throw even >> >> RuntimeException. >> >> >> >> It seems that the code that calls handle() - at least in >> >> this file, has some logic to handle IOException - or >> >> other exception possibly thrown by Dispatcher::handle, >> >> which as far as I can see is not doing much more than what >> >> closeConnection does. So it looks as if calling >> >> closeConnection in handle() instead of throwing could be OK. >> >> >> >> However it would be good to at least try to figure out >> >> whether there are any other call sites for Dispatcher::handle, >> >> validate that no longer throwing will not modify the call site >> >> logic, and possibly investigate if the 'throws IOException' clause >> >> can be removed from Dispatcher::handle (that is: look >> >> whether Dispatcher is exposed and/or can be subclassed and >> >> if there are any existing subclasses). >> >> >> >> best regards, >> >> >> >> -- daniel >> >> >> >> >> >> On 16/02/2018 15:29, KUBOTA Yuji wrote: >> >>> >> >>> Hi Chris and Yasumasa, >> >>> >> >>> Sorry to have remained this issue for a long time. I come back. >> >>> >> >>> I updated my patch for the following three reasons. >> >>> http://cr.openjdk.java.net/~ykubota/816935
Re: httpserver does not close connections when RejectedExecutionException occurs
Hi Daniel, Thank you for your sponsoring! 2018-03-08 0:56 GMT+09:00 Daniel Fuchs : > Could you prepare a final changeset with a properly formatted > comment [1], use jcheck [2] to verify that your changeset conforms > to the OpenJDK rules (no trailing whitespaces, no tabs etc...), > and upload it somewhere to http://cr.openjdk.java.net/~ykubota/8169358 ? My final changeset is below. (no jcheck error from webrev.04) http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked If Christoph could not check webrev.04, please use the following changeset. http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked-two-reviewers Best regards Yuji
Re: httpserver does not close connections when RejectedExecutionException occurs
2018-03-08 16:47 GMT+09:00 Langer, Christoph : > looks good. Thank you! Let's use the following changeset if there aren't any problems. http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked Best regards Yuji > > Best regards > Christoph > >> -Original Message- >> From: KUBOTA Yuji [mailto:kubota.y...@gmail.com] >> Sent: Donnerstag, 8. März 2018 03:57 >> To: Daniel Fuchs >> Cc: Langer, Christoph ; Yasumasa Suenaga >> ; OpenJDK Network Dev list > d...@openjdk.java.net> >> Subject: Re: httpserver does not close connections when >> RejectedExecutionException occurs >> >> Hi Daniel, >> >> Thank you for your sponsoring! >> >> 2018-03-08 0:56 GMT+09:00 Daniel Fuchs : >> > Could you prepare a final changeset with a properly formatted >> > comment [1], use jcheck [2] to verify that your changeset conforms >> > to the OpenJDK rules (no trailing whitespaces, no tabs etc...), >> > and upload it somewhere to http://cr.openjdk.java.net/~ykubota/8169358 >> ? >> >> My final changeset is below. (no jcheck error from webrev.04) >> http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked >> >> If Christoph could not check webrev.04, please use the following changeset. >> http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked- >> two-reviewers >> >> Best regards >> Yuji
Re: httpserver does not close connections when RejectedExecutionException occurs
Thank you, Daniel and everyone! I will keep how to make the suitable changeset when next contributions. Best regards, Yuji 2018-03-09 1:26 GMT+09:00 Daniel Fuchs : > Thank you Yuji! > > This has been pushed. > > For the record - since you are an author, you don't need > to list your address in the Contributed-by section as you > already appear as the author of the changeset: > > http://hg.openjdk.java.net/jdk/jdk/rev/5447851ff0f6 > ``` > author ykubota > ``` > > best regards, > > -- daniel > > > On 08/03/2018 09:28, KUBOTA Yuji wrote: >> >> Thank you! >> >> Let's use the following changeset if there aren't any problems. >> http://cr.openjdk.java.net/~ykubota/8169358/final_changeset_jckecked >> >> Best regards >> Yuji > >
