RFR JDK-8225474: JDI connector accept fails "Address already in use" with concurrent listeners
Andrew Leonard
andrew_m_leonard at uk.ibm.com
Mon Jun 10 09:07:01 UTC 2019
Hi Alex,
Thanks for trying this out, it's possible this failure is an issue with my
testcase, as I repeat the 10 thread test loop 10 times and I have a 30
second timeout which potentially might overrun if a connection takes time
to terminate. I could avoid that simply by using different ports for each
run, equally it could also be an issue as pointed out by Alan.
Thanks
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com
From: Alex Menkov <alexey.menkov at oracle.com>
To: Andrew Leonard <andrew_m_leonard at uk.ibm.com>,
serviceability-dev at openjdk.java.net
Date: 07/06/2019 22:19
Subject: Re: RFR JDK-8225474: JDI connector accept fails "Address
already in use" with concurrent listeners
Hi Andrew,
The fix looks good in general.
And I can be the sponsor.
I've tested the fix and got 1 test failure (of 400 runs) on Win-x64 and
the log looks the same.
java.lang.RuntimeException: Failed to accept connector connection
at
JdwpConcurrentAttachTest.main(JdwpConcurrentAttachTest.java:74)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.net.BindException: Address already in use: bind
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:465)
at java.base/sun.nio.ch.Net.bind(Net.java:457)
at
java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643)
at
java.base/java.net.ServerSocket.bind(ServerSocket.java:359)
at
java.base/java.net.ServerSocket.bind(ServerSocket.java:313)
at
jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:300)
at
jdk.jdi/com.sun.tools.jdi.SocketTransportService.startListening(SocketTransportService.java:310)
at
jdk.jdi/com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:117)
at
jdk.jdi/com.sun.tools.jdi.SocketListeningConnector.startListening(SocketListeningConnector.java:86)
at
JdwpConcurrentAttachTest.attachTest(JdwpConcurrentAttachTest.java:111)
at
JdwpConcurrentAttachTest.run(JdwpConcurrentAttachTest.java:93)
So looks like the fix doesn't fix the issue completely.
--alex
On 06/07/2019 07:24, Andrew Leonard wrote:
> Hi,
> Please can I request a sponsor and review of this patch for JDK-8225474.
> A problem that we have seen intermittently with JDI connector stress
> tests for quite a while that is caused by an non-thread safe HashMap in
> the connector class. I've created a standalone testcase that reproduces
> it reliably.
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8225474_webrev.00&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oCeyoE4YSIdSTvnXT1XeIp6wDP4UdqGpI35isidNG1M&s=fjbdD-X1whCGO82knPWEkDwXbHh8oO1xnJnncogRPsQ&e=
>
> Thanks
> Andrew
>
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190610/3ea165b7/attachment.html>
More information about the serviceability-dev
mailing list