On 30/09/2019 21:55, mark sheppard wrote:
Hi Daniel,
looks like an interesting saga … will give that twirl on my dinky
laptop
wrt why MulticastSocket sets SO_REUSEADDR I reckon Chris or Alan
are the authority on that.
There may be several applications that need to bind to the same po
Hi Daniel,
looks like an interesting saga … will give that twirl on my dinky laptop
wrt why MulticastSocket sets SO_REUSEADDR I reckon Chris or Alan are the
authority on that.
Conjecture would be that typically multicast scenarios require multiple
processes receiving
on the same address
Thank you Sean for reviewing!
With kind regards,
Ivan
On 9/27/19 7:20 AM, Sean Mullan wrote:
Hi Ivan,
The fix looks good. Good catch.
--Sean
On 8/30/19 7:32 PM, Ivan Gerasimov wrote:
Hello!
In the two implementations of
PermissionCollection.implies(Permission), all the permissions are
Hi Mark,
On 30/09/2019 13:37, Daniel Fuchs wrote:
On 30/09/2019 12:56, mark sheppard wrote:
the first uses the InetSocketAddress allocated and then the second
uses the same address, without bind exception because of
the SO_REUSEADDR option being set, even if the close had not
completed at th
On 30/09/2019 15:27, Alan Bateman wrote:
On 30/09/2019 15:10, Patrick Concannon wrote:
Hi Alan,
A new issue has been created as requested, and can be found here:
https://bugs.openjdk.java.net/browse/JDK-8231570
In JDK-8231570, I think Chris is concerned that a custom SM will
observe, and m
On 30/09/2019 15:10, Patrick Concannon wrote:
Hi Alan,
A new issue has been created as requested, and can be found here:
https://bugs.openjdk.java.net/browse/JDK-8231570
In JDK-8231570, I think Chris is concerned that a custom SM will
observe, and may prevent, send/receive from binding where
Hi Alan,
A new issue has been created as requested, and can be found here:
https://bugs.openjdk.java.net/browse/JDK-8231570
Kind regards,
Patrick
On 27/09/2019 16:49, Alan Bateman wrote:
On 27/09/2019 16:07, Patrick Concannon wrote:
Hi Alan,
Thanks for the review.
On 24/09/2019 16:2
Hi Alan,
I have renamed loopbackAddress() into loopbackSocketAddress(), thanks
for the suggestion!
http://cr.openjdk.java.net/~dfuchs/webrev_8231506/webrev.01
I also made a small modification to store the local port
in a final field in UnreferencedMulticastSockets::Server constructor
(one of my
Hi Mark,
On 30/09/2019 12:56, mark sheppard wrote:
the first uses the InetSocketAddress allocated and then the second uses the
same address, without bind exception because of
the SO_REUSEADDR option being set, even if the close had not completed at that
time.
No. The second doesn't use the
Hi Daniel,
thanks for the reply ..
the client is on loopback with an ephemeral port
so in the following:
try (MulticastSocket s = new MulticastSocket(clientAddress)) {
// no-op; close immediately
s.getLocalPort(); // no-op
}
long fdCount0 = g
Hi Mark,
On 30/09/2019 08:58, mark sheppard wrote:
So does the second MulticastSocket need to use the same client unicast
address ?
The clientAddress is an InetSocketAddress with port 0. It is possible
that the second MulticastSocket will get the same port allocated to
it, because the first on
Hi Daniel,
a couple of observations and few points to consider in the
UnreferencedMulticastSockets
test.
similar to the DatagramSocket version but for this one MulticastSocket will
automatically set
the so_reuseaddr option. This has implications when the second MulticastSocket
is created.
Un
12 matches
Mail list logo
