Michael McMahon | 23 Apr 17:56 2014
Picon

RFR: 8041397: Lint regression in java.net.SocketOption

Could I get the following small change reviewed please?

It fixes a number of recently introduced lint warnings

http://cr.openjdk.java.net/~michaelm/8041397/webrev.1/

Thanks
Michael.

hefeng cui | 23 Apr 11:01 2014
Picon

RFR JDK-8041563: ProblemList.txt updates

Hi,

Please review the my code changes for JDK-8041563

Here is the webrev link : http://cr.openjdk.java.net/~ewang/michael/JDK-8041563/webrev.00/

Thanks,
Michael Cui
Claes Redestad | 21 Apr 21:11 2014
Picon

Re: RFR [9] 8040837: Avoid provoking NFEs when initializing InetAddrCachePolicy

Hi again,

please review the latest revision, which fixes a small discrepancy where Security.getProperty was used
instead of System.getProperty (implicitly called by Integer.getInteger in the original code):

http://cr.openjdk.java.net/~mduigou/JDK-8040837/1/webrev/

/Claes

On 2014-04-18 22:52, Mike Duigou wrote:
> Updated webrev from Claes:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8040837/1/webrev/
>
> On Apr 18 2014, at 11:02 , claes.redestad
<claes.redestad@...> wrote:
>
>> Looks like you're right, unfortunately. Seems I confused System.getProperty and
Security.getProperty, and of course they differ subtly. I'll fix it as soon as I can, but I'm out for a few hours..
>>
>> /Claes
>>
>>
>> -------- Originalmeddelande --------
>> Från: Bernd Eckenfels
>> Datum:18-04-2014 19:06 (GMT+01:00)
>> Till: Michael McMahon
>> Kopia: Mike Duigou , claes.redestad@...
>> Rubrik: Re: RFR [9] 8040837: Avoid provoking NFEs when initializing InetAddrCachePolicy
>>
>> Hello,
>>
>> I think the updated revision also uses Security.getProperty for the
>> fallbacks, I think this is wrong, they are read from the System
>> properties. (can be read with Integer.getProperty which uses internally
>> decode).
>>
>> (and sorry for the big discussion on such a small patch :)
>>
>> Gruss
>> Bernd
>>
>> Am Fri, 18 Apr 2014 17:57:04 +0100 schrieb Michael McMahon
>> <michael.x.mcmahon@...>:
>>
>>> Thanks Mike (and adding Claes back in)
>>>
>>> Is there a reason to use both Integer.decode() and Integer.valueOf()?
>>>
>>> Michael
>>>
>>> On 18/04/14 17:44, Mike Duigou wrote:
>>>> Claes tidied things up to produce a workable patch:
>>>>
>>>>> Here is the updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8040837/0/webrev/
>>>>>
>>>>> I will push it to jdk9/dev/jdk on Friday before COB for Claes
>>>>> unless I hear objections.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mike
>>>> On Apr 18 2014, at 09:27 , Michael McMahon
>>>> <michael.x.mcmahon@...> wrote:
>>>>
>>>>> I think it would be an improvement to combine these doPrivileged()
>>>>> blocks as suggested, though your patch needs work Bernd. For
>>>>> instance, the multi-catch doesn't work. Also the
>>>>> PrivilegedAction<> type is wrong.
>>>>>
>>>>> If someone wants to update it, then we can use that. Otherwise,
>>>>> we'll go with the original suggested change.
>>>>>
>>>>> Thanks
>>>>> Michael
>>>>>
>>>>> On 17/04/14 21:28, Bernd Eckenfels wrote:
>>>>>> Am Thu, 17 Apr 2014 21:50:23 +0200
>>>>>> schrieb Bernd Eckenfels <bernd-2014@...>:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would propose to use Integer.valueOf(tmp) instead, but looking
>>>>>>> at the context I think it is even better to skip this and the
>>>>>>> following null check with Integer.parseInt().
>>>>>> This is even shorter and it reduces the privileged actions
>>>>>> invocations:
>>>>>>
>>>>>>          Integer tmp = java.security.AccessController.doPrivileged
>>>>>> ( new PrivilegedAction<String>() {
>>>>>>              public String run() {
>>>>>>                  try {
>>>>>>                      String tmpString =
>>>>>> Security.getProperty(cachePolicyProp); if (tmpString != null)
>>>>>> return Integer.valueOf(tmpString); } catch (NumberFormatException
>>>>>> | IllegalArgumentException ignored) { }
>>>>>>
>>>>>>                  try {
>>>>>>                      return
>>>>>> Integer.getInteger(cachePolicyPropFallback); } catch
>>>>>> (NumberFormatException | IllegalArgumentException ignored) { }
>>>>>>
>>>>>>                  return null;
>>>>>>              }
>>>>>>          });
>>>>>>
>>>>>>           if (tmp != null) {
>>>>>>               cachePolicy = tmp.intValue();
>>>>>>               if (cachePolicy < 0) {
>>>>>>                   cachePolicy = FOREVER;
>>>>>>               }
>>>>>>               propertySet = true;
>>>>>>           } else {
>>>>>>               /* No properties defined for positive caching. If
>>>>>> there is no
>>>>>>                * security manager then use the default positive
>>>>>> cache value. */ if (System.getSecurityManager() == null) {
>>>>>>                   cachePolicy = DEFAULT_POSITIVE;
>>>>>>               }
>>>>>>           }
>>>>>>
>>>>>> NB: this will

Claes Redestad | 19 Apr 00:38 2014
Picon

RFR [9] 8040747 : Improve performance of IP address parsing

Hi,

  could I get a review of the following patch to improve IP address 
parsing performance?

http://cr.openjdk.java.net/~mduigou/JDK-8040747/0/webrev/ 
<http://cr.openjdk.java.net/%7Emduigou/JDK-8040747/0/webrev/>
https://bugs.openjdk.java.net/browse/JDK-8040747

  A set of simple JMH benchmarks was created to test all supported and 
some invalid formats. Results show a speed up of ~5-9x for the normal 
cases (9x for simple cases like 0.0.0.0, 5x for longer addresses like 
255.255.255.255), similar boosts for all invalid and rare cases while 
profiling show that the TLAB allocation rates drop significantly using 
the proposed algorithm.

  Note: naturally maintaining compatibility with the standard and 
non-standard formats intently supported by the previous implementation 
(where both 127.0.0.1 and 40000000 would be considered valid IPv4 
addresses), but I've omitted support for the use of explicit signs 
(+127.+0.-0.+1 would work with the old parser) due to reliance on 
Integer.parseInt to parse the octets; a few checks could be added to 
keep supporting these unintended format variants at a small cost.

  /Claes

Li Li | 18 Apr 03:23 2014
Picon

socketRead0 time out problem

hi all
    sorry to post a not-dev problem here. because I can't find any
active forum(few people use oracle's Networking now).

    I am using http client 4.3. I use PoolingHttpClientConnectionManager
with many threads.
but I found one thread hangs on socketRead0(other thread is correct)

netstat -anotp|grep 5872
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 192.168.11.181:35251        192.168.11.169:61616
     ESTABLISHED 5872/java           off (0.00/0/0)
tcp        0      0 192.168.11.181:35252        192.168.11.169:61616
     ESTABLISHED 5872/java           off (0.00/0/0)
tcp        0      0 49.4.132.244:56035          221.204.231.139:80
     ESTABLISHED 5872/java           off (0.00/0/0)
tcp        0      0 192.168.11.181:41935        192.168.11.151:2181
     ESTABLISHED 5872/java           off (0.00/0/0)

java stack:
"Thread-51" prio=10 tid=0x00007f7dfc20d800 nid=0x1846 runnable
[0x00007f7d5c5c4000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:152)
        at java.net.SocketInputStream.read(SocketInputStream.java:122)
        at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136)
        at org.apache.http.impl.io.SessionInputBufferImpl.read(SessionInputBufferImpl.java:195)
        at org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:178)
        at org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:200)
        at org.apache.http.impl.io.ContentLengthInputStream.close(ContentLengthInputStream.java:103)
        at org.apache.http.impl.execchain.ResponseEntityWrapper.streamClosed(ResponseEntityWrapper.java:120)
        at org.apache.http.conn.EofSensorInputStream.checkClose(EofSensorInputStream.java:227)
        at org.apache.http.conn.EofSensorInputStream.close(EofSensorInputStream.java:174)
        at org.apache.http.util.EntityUtils.consume(EntityUtils.java:88)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:222)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:160)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:136)
        at com.founder.httpclientfetcher.HttpClientFetcher.httpGet(HttpClientFetcher.java:464)

    I have asked this question in httpclient mailing list and get this answer:
Assuming that this.getReadTimeout() returns a positive value, the read
operation can still block indefinitely if the server keeps on sending
packets often enough to prevent the operation from exceeding the socket
timeout value.
    And I also goolged a stackover question:
http://stackoverflow.com/questions/15874834/httpclient-hangs-on-socketread0-with-successfully-executed-method

I have all the timeouts setup just fine but I found out we have on url
that does http chunking but sends no results(works fine in chrome, but
in http client it hangs forever even with the timeout set). Luckily I
own the server and just return some garbage and it no longer hangs.
This seems like a very unique bug in that http client does not handle
some kind of empty chunking case well(though I could be way off)....I
just know it hangs every time on that same url with empty data and
that url is http chunking csv download back to our http client.

is this reason causing my thread hang?
any solution for this?

Claes Redestad | 17 Apr 17:56 2014
Picon

RFR [9] 8040837: Avoid provoking NFEs when initializing InetAddrCachePolicy

Hi,

  could I get a review of the following small patch to address 8040837:

  http://cr.openjdk.java.net/~lagergren/8040837/
  https://bugs.openjdk.java.net/browse/JDK-8040837

  A simple JMH microbenchmark shows this actually might have a small 
benefit to startup:

      <at> GenerateMicroBenchmark
     public int loadInetAddressCachePolicy() throws 
ClassNotFoundException, NoSuchMethodException, 
InvocationTargetException, IllegalAccessException {
         return 
(Integer)Class.forName("sun.net.InetAddressCachePolicy").getMethod("get").invoke(null);
     }

  java -jar microbenchmarks -bm ss -f 100

  before: 0.662 +- 0.086 ms
  after:  0.616 +- 0.084 ms

/Claes

Chris Hegarty | 14 Apr 17:30 2014
Picon

RFR [9] 8040038 : Test java/net/URLPermission/nstest/lookup.sh fails with ClassNotFoundException

It looks like the change for JDK-8027221 missed an  <at> build on the 
dependent library type, Util.

This is just another sighting of the dreaded  <at> library with -conc issue.

diff --git a/test/java/net/URLPermission/nstest/lookup.sh 
b/test/java/net/URLPermission/nstest/lookup.sh
--- a/test/java/net/URLPermission/nstest/lookup.sh
+++ b/test/java/net/URLPermission/nstest/lookup.sh
 <at>  <at>  -26,6 +26,7  <at>  <at> 
  #  <at> library /lib/testlibrary
  #  <at> compile -XDignore.symbol.file=true SimpleNameService.java
  #            LookupTest.java SimpleNameServiceDescriptor.java
+#  <at> build jdk.testlibrary.Utils
  #  <at> run shell/timeout=50 lookup.sh
  #

-Chris.

Michael McMahon | 10 Apr 19:13 2014
Picon

[8u-dev] RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

Hi,

This is the webrev for the 8u20 version of the fix that was reviewed 
yesterday for 9.

JDK
===
http://cr.openjdk.java.net/~michaelm/8036979.8u20/jdk/01/webrev/

Top repo
=====
http://cr.openjdk.java.net/~michaelm/8036979.8u20/top/01/webrev/

The good news is that the change is almost the same as the JDK 9 version
with the following differences:

1) The java.net public API changes are gone. The new public methods for 9
      in SocketImpl and DatagramSocketImpl are package private here.

2) A new package private class java.net.SocketsUtil acts as a bridge between
     the public API in jdk.net.Sockets and the implementation in java.net

3) jdk.net.Sockets uses reflection to access the methods of 
java.net.SocketsUtil

4) The test of the public java.net API is gone and the other test augmented
     with some additional tests for the standard socket options

Thanks,
Michael

Chris Hegarty | 8 Apr 21:03 2014
Picon

RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

java.net.URLConnection.getContent() incorrectly specifies the default location of content handler
classes as sun.net.www.content. ( this location is implementation specific ) 

  "If no content handler factory has yet been set up, or if the factory's createContentHandler method 
    returns null, then the application loads the class named: 
         sun.net.www.content.&lt;contentType> " 

This should be changed to something like: 
    <system default package>.<contentType>, similar to what is done in URL [1] 

Trivial specDiff:
  http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report.html

-Chris.

[1] http://docs.oracle.com/javase/8/docs/api/java/net/URL.html#URL-java.lang.String-java.lang.String-int-java.lang.String-

Michael McMahon | 8 Apr 19:49 2014
Picon

RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

Could I get the following reviewed please?

In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, which implements a platform specific
socket option SO_FLOW_SLA (in jdk.net)

There are changes to two repos:

http://cr.openjdk.java.net/~michaelm/8036979/jdk/01/

and

http://cr.openjdk.java.net/~michaelm/8036979/top/01/webrev/

Thanks
Michael

Chris Hegarty | 7 Apr 16:27 2014
Picon

RFR [9] 8039362: Read content-types.properties as a resource

Following JDK-8004963: "URLConnection, downgrade normative reference to 
${java.home}/lib/content-types.properties", this bug [1] moves 
content-types.properties out of the image lib directory and into 
resources.jar ( to be loaded as a resources file ). This approach is 
acceptable, since the file is not expected to be user editable.

Webrev:
   http://cr.openjdk.java.net/~chegar/8039362/00/webrev/

MimeTable.save(String) can be simply removed since it is never called, 
and editing the default table is not supported.

The motive for this bug is the modular JDK where we need the flexibility 
to put anything that is module-private into a module-private location. 
In this case it would appear that the above files are not a supported 
interface and so should move to a location that should be read as 
resources.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8039362


Gmane