On Mon, 7 Feb 2022 09:14:51 GMT, Daniel Jeliński wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeliński has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Initialize return value in all cases
On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote:
> I added socket connection check same as IPv6_supported().
> Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4
> uninstall`), and set property `-Djava.net.preferIPv4Stack=true`,
>
On Wed, 12 Jan 2022 13:36:19 GMT, Jaikiran Pai wrote:
>> as I indicated below, we have tracked and investigated this issue and it is
>> not purely a macosx-aarch64 issue. It may also be a test env issue. As such
>> using the OS filtering in the test, which is designed to primarily exclued
>>
On Fri, 17 Dec 2021 14:52:53 GMT, Jaikiran Pai wrote:
> Can I please get a review for this test only change which proposes to enable
> debug logs from the test that failed intermittently? This change addresses
> https://bugs.openjdk.java.net/browse/JDK-8278961.
>
> The change passes the (test
On Wed, 12 Jan 2022 08:09:59 GMT, Daniel Jelinski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jelinski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove unused / incorrect exit code
On Mon, 10 Jan 2022 07:37:24 GMT, Daniel Jelinski wrote:
>> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 256:
>>
>>> 254:
>>> 255: ret = enumInterfaces(env, netifPP);
>>> 256: if (ret == -1) {
>>
>> this change is questionable: enumInterfaces returns -2 to allows
On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jelinski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address problems reported by
On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jelinski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address problems reported by
On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jelinski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address problems reported by
On Sat, 8 Jan 2022 09:11:05 GMT, Daniel Jelinski wrote:
>> Clean up of various issues related to error handling and memory management
>
> Daniel Jelinski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address problems reported by
On Mon, 20 Dec 2021 08:51:17 GMT, Daniel Jeliński wrote:
>> Here too I didn't want to change the current behaviour/code of the test.
>> It's not just this catch block but even the one a few lines above which
>> catches `InterruptedIOException`. Neither the `send()` nor the `receive()`
>> APIs
On Fri, 17 Dec 2021 14:52:53 GMT, Jaikiran Pai wrote:
> Can I please get a review for this test only change which proposes to enable
> debug logs from the test that failed intermittently? This change addresses
> https://bugs.openjdk.java.net/browse/JDK-8278961.
>
> The change passes the (test
On Fri, 3 Dec 2021 20:26:46 GMT, Ivan Šipka wrote:
>> Adding test group for IPv6 exclusive testing.
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added comment for adding the ipv6_only testgroup
Marked as reviewed by
sed-modifier-order.sh
> src/java.net.http`.
>
> best regards,
>
> -- daniel
> _Mailing list message from [Daniel Fuchs](mailto:daniel.fu...@oracle.com) on
> [net-dev](mailto:net-...@mail.openjdk.java.net):_
>
> Hi Mark,
>
> On 03/11/2021 14:30, Mark Sheppard wrote:
&
On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a trivial cleanup change that updates classes in the
> `java.net.http` module to use the "blessed modifier order".
>
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
>
On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo wrote:
>> It's tough when a natural language clashes with a programming language. I
>> appreciate that this particular clash might cause discomfort to native
>> English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for
>> adjective
On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API
On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API
On Mon, 14 Jun 2021 15:28:01 GMT, Mark Sheppard wrote:
> JDK-8265369 [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed
> with "SocketException: Cannot allocate memory"
>
> The test java/net/MulticastSocket/Promiscuous.java has been observed to fail
e has been applied as a conditional compilation.
> Additionally this change result in the Promiscuous.java test being removed
> from the
> ProblemList.txt.
>
> Please oblige and review the changes for a fix of the issue JDK-8265369
Mark Sheppard has updated the pull request increment
On Thu, 17 Jun 2021 12:39:17 GMT, Michael McMahon wrote:
>> src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c line 2112:
>>
>>> 2110: res = setsockopt(fd, IPPROTO_IPV6, (join ? ADD_MEMBERSHIP :
>>> DRP_MEMBERSHIP),
>>> 2111:(char *) , sizeof (mname6));
On Thu, 17 Jun 2021 11:07:23 GMT, Chris Hegarty wrote:
>> Mark Sheppard has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8265369 [macos-aarch64] java/net/MulticastSocket/Promiscuous.java
>> failed
e has been applied as a conditional compilation.
> Additionally this change result in the Promiscuous.java test being removed
> from the
> ProblemList.txt.
>
> Please oblige and review the changes for a fix of the issue JDK-8265369
Mark Sheppard has updated the pull request increment
On Tue, 15 Jun 2021 08:58:45 GMT, Chris Hegarty wrote:
>> JDK-8265369 [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed
>> with "SocketException: Cannot allocate memory"
>>
>> The test java/net/MulticastSocket/Promiscuous.java has been observed to fail
>> on a regular basis on
… failed with "SocketException: Cannot allocate memory
The test java/net/MulticastSocket/Promiscuous.java has been observed to fail on
a regular basis on macosx-aarch.
This is typically under heavy test load on a test machine. Analysis of the
problem have
shown that the setsockopt for joining a
On Wed, 26 May 2021 03:54:14 GMT, Jie Fu wrote:
> Hi all,
>
> java/net/SctpSanity.java fails on some of our test machines due to Protocol
> not supported.
> The reason is that the test fails to detect all the cases when a machine
> doesn't support SCTP.
>
> The fix just follows what are done
On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard wrote:
> The test java/net/Socket/UdpSocket.java has been seen to fail with a
> BindException, in the testMaxSockets test, on a regular basis on
> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
> Sock
On Mon, 24 May 2021 14:34:54 GMT, Mark Sheppard wrote:
>> Mark Sheppard has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8265362 java/net/Socket/UdpSocket.java fails with
>> "java.net.BindExcept
On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard wrote:
>> The test java/net/Socket/UdpSocket.java has been seen to fail with a
>> BindException, in the testMaxSockets test, on a regular basis on
>> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
&
On Sat, 22 May 2021 10:54:06 GMT, Mark Sheppard wrote:
>> BTW: Is one retry enough? There is at least one other replace where we've
>> had to retry to workaround a macOS bug and one retry was enough there too.
>
> I have submitted a significant number of MACH5 job runs wit
emed an OS issues, and in order to increase test stability, it
> has been found that for the BindException condition a retry of the Socket
> creation mitigates the issues and tests the max creation property.
Mark Sheppard has updated the pull request incrementally with one additional
commit s
On Sat, 22 May 2021 06:46:18 GMT, Alan Bateman wrote:
>> Thanks, and if you want to keep it consistent with the existing code then
>> you could rename "Socket newUdpSocket" and "biEx", or just change it to
>> "return new Socket(...)".
>
> BTW: Is one retry enough? There is at least one other
The test java/net/Socket/UdpSocket.java has been seen to fail with a
BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64
platform. testMaxSockets tests the maximum number of UDP Sockets that may be
created as defined by a system property sun.net.maxDatagramSockets. It
On Wed, 19 May 2021 05:56:07 GMT, Alan Bateman wrote:
>> The test java/net/Socket/UdpSocket.java has been seen to fail with a
>> BindException, in the testMaxSockets test, on a regular basis on
>> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
>> Sockets that may be
On Tue, 9 Mar 2021 20:26:19 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/NetMulticastSocket.java line 219:
>>
>>> 217: if (addr == null)
>>> 218: addr = new InetSocketAddress(0);
>>> 219: if (!(addr instanceof InetSocketAddress epoint))
>>
>> in
On Tue, 9 Mar 2021 19:56:25 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.net`
>> and `java.nio` packages to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the
On Fri, 22 Jan 2021 14:41:44 GMT, Daniel Fuchs wrote:
>> Patrick Concannon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8259628: Removed buffer check
>
> You could still do some checking if you wanted.
> If you know that you have
On Wed, 20 Jan 2021 12:53:34 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could someone please review my fix for JDK-8259628:
>> '`jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java` fails
>> intermittently' ?
>>
>> `AsynchronousSocketChannelNAPITest` is failing intermittently on
On Mon, 9 Nov 2020 18:38:33 GMT, Mark Sheppard wrote:
>> I wonder if the spec should be a little more specific than just "seeded"
>> which I think is fine for the first sentence. But maybe say something like
>> "fields are copied from the given HttpRequest&
On Mon, 9 Nov 2020 10:28:08 GMT, Michael McMahon wrote:
>>> /csr
>>
>> Link to CSR: https://bugs.openjdk.java.net/browse/JDK-8255993
>
> I wonder if the spec should be a little more specific than just "seeded"
> which I think is fine for the first sentence. But maybe say something like
>
On Tue, 27 Oct 2020 12:12:47 GMT, Michael McMahon wrote:
>> A small improvement to avoid extra string copy.
>>
>> [Tests]
>> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
>> No new failure found.
>
> LGTM
In the original the copy would appear to be a way of enforcing
, mark sheppard < macanao...@hotmail.com > wrote:
Hi Alex,
I think there is some other work planned in this area,
so it may be best to place this item on hold for a bit.
There should be an update on this shortly.
regards
Mark
From: Alex Kashchenko < akash...@redhat.com >
Hi Alex,
I think there is some other work planned in this area,
so it may be best to place this item on hold for a bit.
There should be an update on this shortly.
regards
Mark
From: Alex Kashchenko
Sent: Monday 15 June 2020 10:35
To: mark sheppard ; OpenJDK
Hi Daniel, Patrick,
I wonder is there an opportunity here to refine the constructor
descriptions a
little, also
The wording associated with wildcard addressing includes
* an IP address chosen by the kernel.
which is not actually correct, and maybe it should be omitted from
the various
Hi Patrick et al.
a trivial point and a javadoc question
trivial item in SendCheck test, there's a comment referring to pkt3 & 4 and
invalid port -1.
This is no longer the case -- afaik it's now "can't send port 0 " in a
SocketException ?
I note that there are some java doc changes and
Hi Patrick,
if I understand the change correctly, you wish to eliminate the
IllegalArgumentException and return an InetSocketAddress
based on the current set values for address and port. Because you have changed
the default value of the port to 0, the getSocketAddress
will now return a
Hi Chris,
possible wording for your last paragraph:
To retrieve a string representation of the hostname, or in the
absence of a hostname, the string form of the address, use {@link
#getHostString()}, rather than parsing the toString string representation.
or
It is advised to use
of "resource leak".
But, in this case, with the proposed change the JarFile can be retrieved and
closed.
regards
Mark
From: net-dev on behalf of mark sheppard
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon ; Alex Kashchenko
Cc: Mark Sheppard
Hi Michael et al.,
just looking at the webrev ... the change in URLClassPath seems reasonable.
The change in JarURLConnection has implications and would change the semantics
of
the getJarFile method.
using the example accompanying this JBS item to demonstrate an issue caused by
the caching
DatagramSocket incorrectly caches the first set
of socket options
On 1 Apr 2020, at 15:12, mark sheppard < macanao...@hotmail.com > wrote:
Hi Chris,
just looking at the supportedOptions method in the two classes
DatagramSocket and MulticastSocket, if I haven't misrea
Hi Chris,
just looking at the supportedOptions method in the two classes
DatagramSocket and MulticastSocket, if I haven't misread them, are
they not the same?
As such MulticastSocket could inherit that method from DatagramSocket ?
(without the necessity to override)
regards
Mark
st.recreateServerSocket: returning socket ==
/XXX.XXX.0.211:58754 obtained at first attempt with no sleep
client received data packet Greetings from the server
msheppard@MSHEPPARD-PC /cygdrive/c/Users/Mark
Sheppard/eclipse-workspace/AgentTester-FLIG-4026
$ java PortUnreachab
Hello,
I may have added this to fix some other issue.
it would seem reasonable that stop() would reap (join) the dispatcher thread
that was launched in start()
What is not expected, based on the design of the Dispatcher, that a stop()
will be invoked from within its executing thread
(run
!
Would it be instantaneously available after its release by the kernel, or
subject to TTL lifetime?
best regards
Mark
From: Daniel Fuchs
Sent: Tuesday 8 October 2019 14:40
To: Alan Bateman ; mark sheppard
; nio-dev
Cc: OpenJDK Network Dev list
Subject: Re: RFR
port ?
Q: is localAddress.getPort() == 0 indicative that the DatagramChannel is
unbound ?
best regards
Mark
From: Daniel Fuchs
Sent: Tuesday 8 October 2019 09:16
To: mark sheppard ; Alan Bateman
; nio-dev
Cc: OpenJDK Network Dev list
Subject: Re: RFR: 8231260: (dc) DatagramChannel
Hi Daniel,
wrt impl note ... would some explanation on the esoteric reason for a now
possible BindException be
useful, also? namely that on some platforms the socket is unbound during the
disconnect and requires a re-bind, which for
ephemeral ports allocated may result in a BindException.
multicast support available
on Windows.
Although, Michael McM did say Solaris exhibits restrictive behaviour also,
inhibiting the binding to a multicast address.
regards
Mark
From: Daniel Fuchs
Sent: Monday 30 September 2019 16:47
To: mark sheppard ; OpenJDK
To: mark sheppard ; OpenJDK Network Dev list
Subject: Re: (teststabilization) RFR: 8231506: Fix some instabilities in a few
networking tests
Hi Mark,
On 30/09/2019 08:58, mark sheppard wrote:
> So does the second MulticastSocket need to use the same client unicast
> address ?
T
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.
Hi Alan, Daniel
a couple of observations on the assertion for test failure that you may wish to
consider.
If there is a BindException for the DatagramSocket instantiations
then this would suggest that there is an operating system issue.
The sockets are being bound to an ephemeral port,
Hi Daniel,
thanks for the reply
regards
Mark
From: Daniel Fuchs
Sent: Monday 12 August 2019 10:44
To: mark sheppard ; OpenJDK Network Dev list
Subject: Re: [teststabilization] RFR 8229348:
java/net/DatagramSocket/UnreferencedDatagramSockets.java fails
Hi Michael, Chris,
a brief note on the possibility of stray packets.
For the test to receive data from external sources it would be necessary that
the senders are
using the same port ( as well as the mcast address) as your test (which is an
ephemeral port).
So the source of such stray
Hi Daniel,
thanks for the reply and clarifications
apologies for the distraction
regards
Mark
From: Daniel Fuchs
Sent: Thursday 16 May 2019 09:19
To: mark sheppard; Chris Hegarty; OpenJDK Network Dev list
Subject: Re: RFR: 8223716: sun/net/www/http
Hi Daniel,
a little feedback on the test and some observations.
was curious about this test, mainly that debug wasn't synchronized
and expected to see interleaved output from clients and servers.
So ran the test … had look at the output, which wasn't interleaved
and totals all seemed to matched
Hi Arthur,
yes all good thanks
regards
Mark
From: Arthur Eubanks
Sent: Wednesday 15 May 2019 02:06
To: mark sheppard
Cc: Chris Hegarty; OpenJDK Network Dev list
Subject: Re: [ipv6] RFR: 8223737: HostsFileNameService doesn't handle IPv6
literal addresses
Hi Arthur, Chris,
just a note in passing, as you are well set on the changes, which is all
good -- needs must, as they say.
The current implementation is an emulation of the gethostbyname and
gethostbyaddr lookup on /etc/hosts.
The reverse lookup issue is also solved by adding an
Hi Arthur et al.
with these changes and the increased separation of IPv4 and IPv6 in the
call flows, does
it make sense to preclude the retrieval of IPv6 interfaces, if there is an
error in the IPv4 processing in the
enumInterfaces function ? Or that an error retrieving IPv6 interfaces
Hi Daniel,
interesting set of changes -
But could it be the case that, for some tests, you might change the operational
semantics of a test, when
this applying this change. For example, in the case of GetLocalAddress.
The original is to use a wild card for the server, and a directed
an observation on IPv4_supported and IPV6_supported for your consideration
both, IPv4_support and IPv6_support use socket creation in the appropriate AF
domain as a
a verification of support, but the v6 version also checks that there is a set of
address binding or ipv6 address configuration
a couple of points and observations
* What is the platform's semantics when both java.net.preferIPv4Stack and
java.net.preferIPv6Address are set simultaneously.
* Should the EAFNOSUPPORT check be more pervasive within the native code?
* IPv4 and IPv6 available doesn't mean that the stacks have
Exception at line 695 in NetworkInterface.c. I am not sure
if it is safe to call "(*env)->ReleaseStringUTFChars" even if there is
pending JNI Exception.
Thanks,
Vyom
On Tuesday 12 September 2017 10:50 PM, Mark Sheppard wrote:
Hi,
please oblige and review the follows changes:
htt
; which should be removed.
Best regards
Christoph
-Original Message-
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
Felix Yang
Sent: Mittwoch, 6. September 2017 10:06
To: net-dev@openjdk.java.net; Mark Sheppard
<mark.shepp...@oracle.com>
Subject: RFR 808587
Hi
it's worth noting that there is diagnostic output for each of the
test scenarios, and that for a failure scenario
the details of the network interface associated with the failure is
displayed.
a typical failure scenario for this test is where a host has multiple
network interfaces
a minor observation:
perhaps a slight modification to the test to allow adaptation to jdk8
(the genesis of the reported problem)
replacing the NetworkInterface.networkInterfaces() with static method
which encapsulates the Stream
creation
public static Stream
Hi Sean,
main change looks fine - it sorts the reported problem.
ran your test against jdk8 152 and a recent jdk9 builds to verify that
your test failure occurs.
The failure is seen, together with an additional (intermittent) exception:
java.net.SocketException: No such device
If we look at the failure scenario then it seen that
with multiple network interfaces having IPv6 and IPv4 configurations,
where the IPv6 part is not fully configured and is not UP, but is
RUNNING
wrt the change in MulticastSocket, is there not a deeper issue here?
that is, in the
thanks Chris
wrt NetworkConfiguration, yes I considered using it, but distilled the
change to
the small change shown
regards
Mark
On 05/05/2017 09:30, Chris Hegarty wrote:
On 4 May 2017, at 21:56, Mark Sheppard <mark.shepp...@oracle.com> wrote:
Hi,
please oblige and review the fol
On May 4, 2017, at 1:56 PM, Mark Sheppard <mark.shepp...@oracle.com> wrote:
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/7155591/webrev/
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-7155591
this identifies that th
Hi,
please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/7155591/webrev/
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-7155591
this identifies that the awdl interface causes issues for the
SetOutgoingIf multicast socket test, and
the
thanks Chris
On 02/05/2017 14:53, Chris Hegarty wrote:
Mark,
The change looks ok to me.
-Chris.
On 02/05/17 14:51, Mark Sheppard wrote:
Hi
please oblige and review the minor change, to javadoc of
HttpURLConnection, below
which addresses the punctuation correction requested
in
https
Chris, Martin,
thanks for the feedback I'll remove the initialization from the
constructor
regards
Mark
On 07/03/2017 15:17, Chris Hegarty wrote:
Mark,
On 6 Mar 2017, at 23:21, Mark Sheppard <mark.shepp...@oracle.com> wrote:
tha's true from the Java side. I didn't exhaus
not have both the never-null property and the check for null.
I would probably just leave bindings null in the constructor and check
for null whenever reading bindings.
On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard
<mark.shepp...@oracle.com <mailto:mark.shepp...@oracle.com>> wro
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/
for the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8175325
the scenario is that a MulticastSocket, bound to a wildcard address,
which has yet to have its NetworkInterface
set, will
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html
to address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8164815
It was found during testing that, when a system
Hi Rob,
changes look reasonable ...
perhaps align the two additions below the existing ERROR_XXX set, all
neat and tidy :-)
regards
Mark
On 27/09/2016 00:09, Rob McKenna wrote:
Hi folks,
Looking for a review of this simple addition to Inet4AddressImpl.c on Windows.
As per the bug
aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx
-Rob
On 21/09/16 06:32, Seán Coffey wrote:
spotted an interesting blog on the MSDN timeout issue here :
https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/
Regards,
Sean.
On 21/09/16 1
the IcmpSendEcho series of calls come with some idiosyncrasies in that
there is a minimum timeout that they can handle
think it is about 1000msecs. isReachable can specify a finer grained
timeout hence the need for timeout check
regards
Mark
On 21/09/2016 17:18, Vyom Tewari wrote:
Hi Rob,
Hi Rob,
this looks good ...
do you think there is any need to replicate these changes in
Inet6AddressImpl.c ? (or leave it alone and don't trouble trouble
until trouble troubles you :-)
regards
Mark
regards
Mark
On 21/09/2016 16:16, Rob McKenna wrote:
Hi folks,
I'd like to fix a
-in from new code, by creating
an unbound MS, setting the option, then binding.
-Chris.
On 14/09/16 14:47, Chris Hegarty wrote:
Mark,
On 14/09/16 14:22, Mark Sheppard wrote:
Hi Chris,
I don't fully understand your objections to the approach taken.
Is there a compatibility issue
the question of why have a convenience method, such as
setReuseAddress() in the first place, when it can be handled
adequately via the setOption
regards
Mark
On 14/09/2016 13:34, Chris Hegarty wrote:
Mark,
On 14/09/16 13:23, Mark Sheppard wrote:
Hi Chris,
so are you accepting
Hi Chris,
so are you accepting that it is correct to add the overridden
methods in MulticastSocket and that these need
appropriate javadoc ?
or are you advocating pushing the handing of the SO_REUSEPORT into the
base DatagramSocket class ?
It is not clear how your code changes fit in
tion pointer, to run if
the poll/select returns before the timeout? Just an idea.
-Chris.
Thanks,
Vyom
On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
On 05/09/16 15:37, Mark Sheppard wrote:
if the desire is to avoid making double calls on gettimeofday in the
NET_ReadWithTimeout'
mments.
Thanks,
Vyom
On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote:
On 05/09/16 15:37, Mark Sheppard wrote:
if the desire is to avoid making double calls on gettimeofday in the
NET_ReadWithTimeout's while loop for its main call flow,
Yes, the desire is to make no more
gt;).
I
incorporated the review comments.
Thanks,
Vyom
On Tuesday 30 August 2016 04:11 PM, Mark Sheppard wrote:
Hi
perhaps there is an opportunity to do some refactoring here (...
for me a "goto " carries a code smell! )
along the lines
if (timeout) {
nread = NET_Rea
builds and regression tests appear to be OK with the proposed changes.
regards
Mark
On 02/09/2016 12:41, Mark Sheppard wrote:
have had a look through the changes twice, and they look fine ... i'll
apply the patch and run a regression build to confirm
the moving of int flags on 919
have had a look through the changes twice, and they look fine ... i'll
apply the patch and run a regression build to confirm
the moving of int flags on 919 to a conditional block, I expect to
cause a strict compile error in my solaris env, so need to check that
regards
Mark
On 02/09/2016
Hi
perhaps there is an opportunity to do some refactoring here (... for
me a "goto " carries a code smell! )
along the lines
if (timeout) {
nread = NET_ReadWithTimeout(...);
} else {
nread = NET_Read(...);
}
the NET_ReadWithTimeout (...) function will contain a restructuring
Hi Christoph,
thanks for the response ... yes, you do check the
getLastErrorString return ... sorry about that!
regards
Mark
On 27/06/2016 14:28, Langer, Christoph wrote:
Hi Mark,
thanks for looking at this. Please see my comments inline.
wrt
Hi,
wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it
doesn't allow for malloc to fail and hence
str1 could be null and a problematic input to jio_snprintf which could
result in a de-referencing of zero.
in the call flow would it not be more appropriate to manipulate
Hi Chris,
this looks good ... so the server now listens on wildcard and the
client uses IPv6 loopback as the destination address.
The use of NO_PROXY, is good. I wouldn't have thought of that, and in
the past, Tests have experienced firewall issues on
linux and macos perviously without
1 - 100 of 178 matches
Mail list logo
