/~xiaofeya/8169115/webrev.02/
>
> Thanks,
> Felix
> On 2016/12/6 19:16, Dmitry Samersoff wrote:
>> Felix,
>>
>> 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for
>> this test. Could we use different one (e.g. icann.org)
>>
>> 2.
following patch. It generally coverts codes from
> shell to plain java.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8169115
>
> Webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/
>
> Thanks,
>
> Felix
>
--
Dmitry Sa
>>>>>>>>JNU_ThrowOutOfMemoryError(env, "NET_Timeout
>>>>>>>> native heap allocation failed");
>>>>>>>>} else {
>>>>>>>> JNU_ThrowByNameWithMessageAnd
onsistent with the existing code.
>
> Thanks,
>
> Vyom
>
>
> On Friday 02 September 2016 01:38 AM, Dmitry Samersoff wrote:
>> Vyom,
>>
>> Did you consider to use select() to calculate timeout instead of
>> gettimeofday ?
>>
>> gettimeo
.openjdk.java.net/browse/JDK-8075484
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
>>>> <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
>>>>
>>>> This is
rates an RST? Also, is there any way to detect a FIN
> in the JVM and react on it?
>
>
>
> Thanks in advance and best regards
>
> Christoph
>
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Chris,
Looks good for me. Only minor nits (no need to re-review).
1040 missed space before {
1158 please, add comment and {} around continue.
1938 I'm not sure that check for IFF_POINTOPOINT is necessary (but
don't mid to leave it). Do you know the case when both flags are set?
-Dmitry
On 20
workInterface.c
>>>
>>> As a follow up to JDK-8156521, and when comparing against the
>>> version of this file in jdk8u-dev a few minor issues were noticed.
>>>
>>> There is a free of a memory structure that was missed somehow
>>> in the 9 versi
ke sure
> nothing broke.
>
>
>
> Thanks in advance
>
> Christoph
>
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
TTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/ResolvingHost.java
>
> [2]:
> https://e61b615da46327c9050d624b0a3783ba21c6b125.googledrive.com/host/0B5Kp-cB1sXJrfnZ4NHZ0S1V3UTJZcDFra3RwUFZjQXY5WVZzUkwtTTd0Z1IyR1JmbDZPSVk/resolvconf-reinit/
>
--
Dmitry Samersoff
Oracle Java development team, Saint P
s Hegarty wrote:
> On 18 Dec 2014, at 12:22, Dmitry Samersoff
> wrote:
>
>> Chris,
>>
>> In a windows world it's rather common to rely on socket inheritance
>> e.g. set socket to stdin(stdout) of child process and do CreateProcess.
>
> OK, but there ca
ia = NET_SockaddrToInetAddress(env, (struct sockaddr *)&sa, &port);
> isa = (*env)->NewObject(env, isa_class, isa_ctorID, ia, port);
> (*env)->SetObjectArrayElement(env, isaa, 0, isa);
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
> {"192.168.1.2", "192.168.1.2"},
> -{"hello.foo.bar", null},
> +{"invalidhost.invalid", null},
> {"1024.1.2.3", null},
> {"128.14.66000", null }
>
>
> regards
&
h 32 bytes of data:
> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128
> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128
> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128
> Reply from 127.0.53.53: bytes=32 time<1ms TTL=128
>
> this highlights a DNS configuration issue
cal ipv6 address. As such, it can happen that during the test the
> interface is disabled, and the test will fail with the report Socket
> receive timeout.
>
> This fix removes the Teredo interface from the testing scenario, so that
> a more stable interface
> will be used.
>
if the given address is not 4 byte aligned.
>
> http://cr.openjdk.java.net/~chegar/8034181/webev.00/webrev/
>
> -Chris
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8034181
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to c
23/02/14 08:55, Chris Hegarty wrote:
>>>>> On 22 Feb 2014, at 17:23, Dmitry Samersoff
>>>>> wrote:
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> Didn't look to windows part. Unix part looks good for
t it is disabled by default. It is now finally
> being removed.
>
> This bug tracks changing the native in src/share/native/java/net and
> src/solaris/native/java/net so that the system calls are used directly rather
> than going through the JVM_* functions.
>
> http://cr.openj
Changeset: 392acefef659
Author:dsamersoff
Date: 2013-10-19 20:59 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/392acefef659
8024071: In ManagementAgent.start it should be possible to set the jdp.name
parameter.
Summary: Pass one more property from Agent to JdpController
Rev
Changeset: 88436832cfd0
Author:dsamersoff
Date: 2013-10-19 00:05 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88436832cfd0
8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields
Summary: Add some extra fileds to jdp packet
Reviewed-by: allwin, sla,
ava.net/~bpb/8010371/webrev.4-amendment/
>>>>
>>> I've restored the bug fields and I assume you'll create a new bug for the
>>> follow-up. Sorry this was missed in the original review (probably because
>>> it went through so many iterations).
>
is that winsock_errors dates from early
>> versions of Windows whether there wasn't a means to translate Windows
>> Sockets errors. We should look at eliminating it (not for JDK 8 of
>> course, it's too late) so that all errors are handle translated
>> consistently.
ror is only returned by WSAGetLastError?
>
> However I think we have a problem with using gai_strerror here as the
> MSDN documentation says that it is not thread safe. This means we may
> have to look for a WSA equivalent or maybe drop the Windows part of the
> fix (using a mutex
Rob,
Existing code uses if (JVM_GetHostName(myhostname, NI_MAXHOST)) so I
withdraw my last comments. Please, don't change it!!!
-Dmitry
On 2013-10-07 20:30, Rob McKenna wrote:
> Thanks Dmitry! I'll correct that nipick pre-push.
>
> -Rob
>
> On 07/10/13 16:4
y makes sense to
> leave it in there. Actually, can you tell me why you'd rather not
> include ipv6 loopbacks at all?
>
> New webrev at:
>
> http://cr.openjdk.java.net/~robm/7180557/webrev.04/
>
> -Rob
>
> On 21/09/13 12:20, Dmitry Samersoff wrote:
>>
Changeset: 5d6dc0cba08f
Author:dsamersoff
Date: 2013-10-03 16:54 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d6dc0cba08f
8009213: sun/management/jdp/JdpTest.sh fails with exit code 1
Summary: There's no guarantee that the java process has executed far enough to
be found
> -Chris.
>
> On 10/03/2013 10:44 AM, Dmitry Samersoff wrote:
>> Chris,
>>
>> On my opinion, it's better to just return meaningful exception to
>> customer and let them deal with network issue (as current webrev does).
>>
>> Typical network failure
level until we get result
or timeout, but it requires much more work and probably out of scope of
this CR.
-Dmitry
On 2013-10-03 13:11, Chris Hegarty wrote:
> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote:
>> Chris,
>>
>> I'm not sure immediate native retry ma
t;> javadoc?
>
> I don't think it is necessary for this to be documented. It is more
> informational.
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
>> https://bugs.openjdk.java.net/browse/JDK-8010371
>>
>> Webrev
>> http://cr.openjdk.java.net/~bpb/8010371
>>
>>
> So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and
> errno set to EAGAIN? I also wonder if the EAGAIN means the underlying
> syscall ha
ack when the JDK
>> ServerSocket is running through accept request (from our client socket).
>> I don't think it's an issue for this case.
>>
>> line 611 :
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c
&g
t;> prefer the hosts file (which it should do on Linux and OSX). And so
>>> the platform specific lookupIfLocalhost() can be put after the
>>> getaddrinfo() (again).
>>>
>>> I actually think the bug "exists" on all platforms. If getaddrinfo()
>>&
; bug report : https://bugs.openjdk.java.net/browse/JDK-8024952
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/
>
> Regards,
> Sean.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
> a canonical answer on whether this is the way to go so I figured trial
> by fire might get the discussion going.
>
> http://cr.openjdk.java.net/~robm/7180557/webrev.01/
>
> -Rob
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to
ight get the discussion going.
>
> http://cr.openjdk.java.net/~robm/7180557/webrev.01/
>
> -Rob
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
d wrote:
>>> Hi
>>> based on feedback for initial fix, an amended webrev has been created.
>>> So, please oblige and review the fix below to address the issue in
>>> JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate
>>> hardware address
>&g
dex can be zero, which
> implies that the
> IPv4 or IPv6 interface is not available. This may be at odds with the
> setting of a default index to 0 in the Java NetworkInterface abstraction,
> where a defaultIndex of zero is used.
>
> JPRTs have been run and show no side effects.
t;>>>
>>>>>> Here are the questions:
>>>>>> 1. whether "example..com" is an valid IDN?
>>>>>> As dot is used as label separators, there are three labels,
>>>>>> "example", "", &qu
on throws
> a StringIndexOutOfBoundsException.
>
>However, what empty domain name ("") really means? I would prefer to
> return "." for "." instead.
>
>We need to address the issue in IDN.
As dot is a label separator and root (empty) la
ASCII(IDN.java:118)
>
> Case 2:
> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>
> Thanks,
> Xuelei
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Changeset: fce446b29577
Author:dsamersoff
Date: 2013-08-06 14:04 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce446b29577
8011038: sourceObj validation during desereliazation of RelationNotification
should be relaxed
Summary: sourceObj could be set to null by setSource()
er if we should air on the
>> side of caution and maybe give this function a unique name, say
>> initInetAddrs ( or something similar ).
>>
>> -Chris.
>>
>>
>>>
>>> This low-risk fix will hopefully be going into 7u40.
>>>
>>>
>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020498
>>> Webrev: http://cr.openjdk.java.net/~khazra/8020498/webrev.00/
>>>
>>> Thanks,
>>> Kurchi
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
dler will store/retrieve the HttpOnly cookies]
> if (cookieHandler == null || value.length() == 0)
> return value;
>
>
> So return value is not changed. BTW. I agree with your comments.
>
> -Chris.
>
>
> On 06/27/2013 06:13
>
>>>
>>> On 6/26/2013 10:54 AM, John Zavgren wrote:
>>>> Please consider the following changes to the Java cookie code.
>>>>
>>>> http://cr.openjdk.java.net/~jzavgren/8015799/webrev.02/
>>>> <http://cr.openjdk.java.net/%7Ejzavg
Changeset: df1b35c7901d
Author:dsamersoff
Date: 2013-06-05 18:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df1b35c7901d
8015604: JDP packets containing ideographic characters are broken
Summary: Code uses string length rather than byte array length and non ascii
entry b
fix:
>>>> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
>>>
>>> Sorry John, I don't see what the problem is that you are trying to
>>> solve? Can you please explain why the original code has problems?
>>>
>>> Also, note that there are other places in the same function that do
>>> the very same check.
>>>
>>> -Chris.
>>>
>>>>
>>>> Thanks!
>>>> John
>>>>
>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Changeset: 7d7bfce34a79
Author:dsamersoff
Date: 2013-05-28 18:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7bfce34a79
8014420: Default JDP address does not match the one assigned by IANA
Summary: JDP protocol defaults changed to IANA assigned values
Reviewed-by: dholme
e limited doPrivileged feature is integrated, I will
> change the doPrivileged() call to limit the privilege elevation to a single
> SocketPermission (as shown in the code comments).
>
> The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/
>
> Thanks
> Mic
Alan,
Not sure what is real usecase for this requirements for ipv4.
For ipv6 it should be done by sendmsg() and msg_control.
-Dmitry
On 2013-05-06 11:28, Alan Bateman wrote:
> On 05/05/2013 12:19, Dmitry Samersoff wrote:
>> Alan,
>>
>> SO_BINDTODEVICE shouldn't be u
n't API support, it is something that can be done at the
> application level. So if InetAddress.getAllByName return several
> addresses then it is possible to initiate connections to several
> addresses using a thread pool. Another approach might be to use several
> SocketChannel con
o you to make a decision.
-Dmitry
>
> - Michael
>
> On 01/05/13 12:38, Dmitry Samersoff wrote:
>> Michael,
>>
>> Sorry for not being clean enough.
>>
>> On my opinion an ability to check header value as well as a header name
>> is quite useful future for
character.
>
> Michael
>
> On 01/05/13 12:11, Dmitry Samersoff wrote:
>> Michael,
>>
>> I'm just asking about replacing : (colon) to another character to be
>> able to write something like:
>>
>> permission
>> java.net.HttpURLPermissio
2013-05-01 15:04, Michael McMahon wrote:
> On 01/05/13 11:09, Dmitry Samersoff wrote:
>> Michael,
>>
>>> "GET,POST:Header1,Header2"
>> Colon is a delimiter between http header and it's value.
>>
>> With this syntax we might have problems in a future
ly
>>>>> submitted.
>>>>>
>>>>> This is for JEP 184: HTTP URL Permissions
>>>>>
>>>>> The idea here is to define a higher level http permission class
>>>>> which "knows about" URLs, HTTP request methods and headers.
>>>>> So, it is no longer necessary to grant blanket permission for any kind
>>>>> of TCP connection to a host/port. Instead a HttpURLPermission
>>>>> restricts
>>>>> access to only the Http protocol itself. Restrictions can also be
>>>>> imposed
>>>>> based on URL paths, specific request methods and request headers.
>>>>>
>>>>> The API change can be seen at the URL below:
>>>>>
>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/
>>>>>
>>>>> In addition to defining a new permission class, HttpURLConnection
>>>>> is modified to make use of it and the documentation change
>>>>> describing this
>>>>> can be seen at the link below:
>>>>>
>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html
>>>>>
>>>>> All comments welcome.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Michael.
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
v.03/
> <http://cr.openjdk.java.net/%7Ejzavgren/8012108/webrev.03/>
>
> Thanks!
> John
>
> On 04/20/2013 10:36 AM, Kurchi Subhra Hazra wrote:
>> On Apr 20, 2013, at 4:40 AM, Dmitry Samersoff
>> wrote:
>>
>>> Kurchi,
>>>
>>> if *neta
errors
> occur, we make the assignment:
> *netaddrPP = start at line 429 and return immediately (without
> considering start->next).
>
> If you see any errors in my thinking, please let me know.
> Thanks!
> John
>
>
> On 04/20/2013 07:40 AM, Dmitry Samersoff wrote:
>&
20, 2013, at 3:16 AM, Dmitry Samersoff
> wrote:
>
>> John,
>>
>> 102, 145 else is redundant.
>>
>> 438 - we will crash here if start is null
>
>
> Maybe it is good to have an additional check for start != null, but from what
>
ADAPTER_ADDRESSES *) realloc (adapterInfo, len);
>>
>> -Dmitry
>>
>> On 2013-04-19 00:56, John Zavgren wrote:
>>> Greetings:
>>>
>>> I fixed a case in the windows native code where calloc() was being used
>>> without checking it's retu
> without checking it's returned value.
>
> http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
>
> Thanks!
> John Zavgren
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
jdk.java.net/~chegar/8012244/webrev.00/webrev/
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
gt;> Ah, I see what you mean. Can do.
>>
>> -Rob
>>
>> On 07/03/13 23:13, Dmitry Samersoff wrote:
>>> Rob,
>>>
>>> Sorry for not being clean enough. We have repeated pattern:
>>>
>>> if (logger.isLoggable(PlatformLogger.FINEST)) {
>
rote:
> Hi Dmitry,
>
> I'm not 100% sure what you mean by duplication, the exceptions and their
> messages are distinct. I think it would be best to keep it that way.
>
> -Rob
>
> On 07/03/13 22:00, Dmitry Samersoff wrote:
>> Rob,
>>
>> Is it po
:18, Rob McKenna wrote:
> Hi folks,
>
> This is a slight alteration of the fix contributed by Stuart Douglas.
> This fix deals with a SocketException caused by getSoTimeout() on a
> closed connection.
>
> http://cr.openjdk.java.net/~robm/8009650/webrev.01/
>
>
e here.
>
> -Dmitry
>
> On 2013-03-04 20:12, John Zavgren wrote:
>> Greetings:
>>
>> I posted a webrev image for a modification that eliminates a file descriptor
>> leak.
>>
>> http://cr.openjdk.java.net/~jzavgren/8008804/webrev.01/
>>
>&g
John,
closesocket call should be here.
-Dmitry
On 2013-03-04 20:12, John Zavgren wrote:
> Greetings:
>
> I posted a webrev image for a modification that eliminates a file descriptor
> leak.
>
> http://cr.openjdk.java.net/~jzavgren/8008804/webrev.01/
>
> Thanks
Changeset: 8181be9a3538
Author:dsamersoff
Date: 2013-02-13 21:06 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8181be9a3538
8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris
Summary: fixed couple of more Solaris shell incompatibilities
Reviewed-by: chegar
Changeset: f7fb173ac833
Author:dsamersoff
Date: 2013-02-12 16:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833
8007786: JDK-8002048 testcase doesn't work on Solaris
Summary: test built in into Solaris shell doesn't have -e operator
Reviewed-by: sla, sspitsyn
!
Changeset: 1df991184045
Author:dsamersoff
Date: 2013-02-11 18:44 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1df991184045
8007536: Incorrect copyright header in JDP files
Summary: Copyright header in JDP files missed the "classpath exception" rule.
Reviewed-by: mikael
! s
Changeset: 0e7d5dd84fdf
Author:dsamersoff
Date: 2013-02-06 16:53 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e7d5dd84fdf
8007277: JDK-8002048 testcase fails to compile
Summary: sun.* classes is not included to ct.sym file and symbol file have to
be ignored
Reviewed-by: a
Changeset: 962d6612cace
Author:dsamersoff
Date: 2013-02-03 21:39 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/962d6612cace
8002048: Protocol to discovery of manageable Java processes on a network
Summary: Introduce a protocol to discover manageble Java instances across a
n
s
> issue is concerned changes will only be make to the Linux version of
> closefd.
>
> Webrev
> ---
>
> http://cr.openjdk.java.net/~chegar/8006395/webrev.00/webrev/
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
ket/socketTransport.c:371:33:
>>>>> warning: pointer targets in passing argument 3 of 'dbgsysAccept'
>>>>> differ
>>>>> in signedness [-Wpointer-sign]
>>>>> ../../../../src/share/transport/socket/sysSocket.h:41:5: note:
>>&
On 12/19/2012 03:42 PM, Alan Bateman wrote:
>>>>>
>>>>> John - this is the debugger socket transport so cc'ing the
>>>>> serviceability-dev list as that is where this code is maintained.
>>>>>
>>>>> On 19/12/2012 15:36, John Zavgren wrote:
>>>>>> Greetings:
>>>>>> Please consider the following change to the two files:
>>>>>> src/share/transport/socket/sysSocket.h
>>>>>> src/solaris/transport/socket/socket_md.c
>>>>>> that eliminate compiler warnings that stem from the fact that the
>>>>>> variables that the native code passes to various system calls were not
>>>>>> declared correctly. They were declared as integers, but they must be
>>>>>> "unsigned" integers because they are used to define buffer lengths.
>>>>>> Were one to supply a negative value as an argument, it would be cast
>>>>>> into an unsigned "Martian" value and there'd be (hopefully) a system
>>>>>> call error.
>>>>>>
>>>>>> Thanks!
>>>>>> John Zavgren
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/
>>>>>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Changeset: c1a55ee9618e
Author:dsamersoff
Date: 2012-12-20 20:12 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1a55ee9618e
8005309: Missed tests for 6783290,6937053,7009998
Summary: Missed tests for 6783290,6937053,7009998
Reviewed-by: sjiang, emcmanus
Contributed-by: jaros
t;>> serviceability-dev list as that is where this code is maintained.
>>>>
>>>> On 19/12/2012 15:36, John Zavgren wrote:
>>>>> Greetings:
>>>>> Please consider the following change to the two files:
>>>>> src/share/transport/s
Changeset: 3f014bc09297
Author:dsamersoff
Date: 2012-12-20 17:24 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f014bc09297
7009998: JMX synchronization during connection restart is faulty
Summary: add a return statement after the re-connecting has finished and the
state is
Changeset: e43f90d5af11
Author:dsamersoff
Date: 2012-12-20 16:56 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e43f90d5af11
6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure
Summary: the catch block in the fetchNotifs() method is extended to expe
Changeset: b600d490dc57
Author:dsamersoff
Date: 2012-12-20 16:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d490dc57
6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject
Summary: call readObject in all cases
Reviewed-by: emcmanus
Contributed-by:
t stem from the fact that the variables
>>> that the native code passes to various system calls were not declared
>>> correctly. They were declared as integers, but they must be "unsigned"
>>> integers because they are used to define buffer lengths. Were one to su
declared as integers, but they must be "unsigned"
>> integers because they are used to define buffer lengths. Were one to supply
>> a negative value as an argument, it would be cast into an unsigned "Martian"
>> value and there'd be (hopefully) a system cal
to define buffer lengths. Were one to supply a
> negative value as an argument, it would be cast into an unsigned "Martian"
> value and there'd be (hopefully) a system call error.
>
> Thanks!
> John Zavgren
>
> http://cr.openjdk.java.net/~mullan/webrevs/jz
On 2012-12-12 22:29, Chris Hegarty wrote:
> On 12/12/2012 18:15, Dmitry Samersoff wrote:
>> Chris,
>>
>> According to rfc2606 TLD .invalid is reserved for cases like this one,
>
> Yes, I came across this, but there is nothing to stop an internal DNS
> server f
The Server in this
> case doesn't ever receive the destination address or host name. It is
> simply replying to the initial/opening SOCKS handshake.
>
> The updated host name is still brittle ( if a .t TLD is ever registered!
> ). I don't have a better alternative.
>
> -Ch
an simply be removed.
>
> http://cr.openjdk.java.net/~chegar/8004675/webrev.00/webrev/
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
20.7u-dev/webrev.1/
I see a comment // MMM 7200720 ??
at ll: 202 of NTLMAuthentication.java
- Does it make sense to change it to something more verbose?
Otherwise looks good for me.
> http://cr.openjdk.java.net/~michaelm/8003948.7u-dev/webrev.1/
Looks good for me.
-Dmitry
--
Dmitry
web servers and proxies.
>
> Thanks
> Michael
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
t;. What
> about that?
>
> Best regards,
> Frank
>
> On 12/10/2012 3:43 PM, Dmitry Samersoff wrote:
>> Frank,
>>
>> Looks good for me.
>>
>> May be "Can't get WIDE string" should be changed to something more
>> verbose.
>>
?
>>
>> Best regards,
>> Frank
>>
>> On 11/14/2012 12:12 AM, Chris Hegarty wrote:
>>> On 11/11/2012 07:03 PM, Dmitry Samersoff wrote:
>>>> Frank,
>>>>
>>>> Changes look good for me.
>>>
>>> I admit that I a
>>
>> -Alan
>
> just checked the new build on Linux and it's fine.
> There are a couple of other fixes that will follow this one
> related to this problem. But, I'd like to go ahead and push this one first
> if possible
>
> - Michael
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
inSocketImpl.getIn/OutputStream where isClosedOrPending()
> grabs the fdLock to check if the socket is closed, or not, and the
> construction of the in/output stream, where another thread may
> asynchronously close the socket.
>
> http://cr.openjdk.java.net/~chegar/8003833/webrev.00/
right file name but the wrong content. 'sorry about that.)
>
> http://cr.openjdk.java.net/~mullan/webrevs/8003991/webrev.00/
>
> Thanks!
> John Zavgren
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
9:16:28 PM GMT -05:00 US/Canada Eastern
> Subject: Re: getportbyname in Java?
>
> I don't think so...
>
> Thanks,
> - Kurchi
>
> On 13.11.2012 16:40, Weijun Wang wrote:
>> Is there a Java API I can translate "http" to 80?
>>
>> Thanks
>> Max
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
rmation in the original UTF-16 encoding.
> END QUOTE
>
> The link below may be helpful to the second param of
> WideCharToMultiByte.
> http://blogs.msdn.com/b/oldnewthing/archive/2012/05/04/10300670.aspx
>
> You comments are appreciated.
> Best regards,
> Frank
>
--
Dmitry Samersoff
Saint Petersburg, Russia, http://devnull.samersoff.net
* There will come soft rains ...
8, Chris Hegarty wrote:
>>>>> Trivial test issue where the test will fail if run on a machine
>>>>> that has
>>>>> a process listening on port 8080 ( test expects this port to refuse
>>>>> the
>>>>> connection ). The s
On 2012-11-06 15:41, Chris Hegarty wrote:
> On 11/06/2012 11:30 AM, Dmitry Samersoff wrote:
>> Chris,
>>
>> If you need definitely refusing port the best option is use port 0
>> reserved by IANA for this purpose.
>
> Do you have a link specifying this? I don&#x
h.
>
> http://cr.openjdk.java.net/~chegar/8002297/webrev.00/webrev/
>
> -Chris
--
Dmitry Samersoff
Java development team, SPB04
* There will come soft rains ...
The webrev image is in the following location:
>>>
>>> http://cr.openjdk.java.net/~chegar/8000203/webrev.01/
>>>
>>> Thanks!
>>> John Zavgren
>>> john.zavg...@oracle.com
>
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
age is in the following location:
>
> http://cr.openjdk.java.net/~chegar/8000203/webrev.01/
>
> Thanks!
> John Zavgren
> john.zavg...@oracle.com
>
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
gt; structure. This change eliminates
> a false positive from our static code analyzer: parfait. This modification
> doesn't change any of the externally-visible behavior in the procedure.
>
> I look forward to your comments and suggestions.
>
> Thanks!
> John Zavgren
>
Changeset: b2d8a99a049e
Author:dsamersoff
Date: 2012-10-17 18:34 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2d8a99a049e
6809322: javax.management.timer.Timer does not fire all notifications
Summary: Some notifications get dropped due to ConcurrentModificationException
t
1 - 100 of 118 matches
Mail list logo
