(original) (raw)

Hi Michael,

I have submitted a sun bug 7188315\. I do not know about CCC request, if needed, please conduct me to request it.

Thanks a lot!

On 07/31/2012 05:32 PM, Michael McMahon wrote:

Deven

Is there a bugid for this? We need to submit a CCC request also to make the spec change.

Thanks
Michael

On 31/07/12 08:14, Deven You wrote:

Hi Michael,

Thanks for your review, I have updated the patch\[1\] according to your comments.

\[1\] http://cr.openjdk.java.net/\~youdwei/ojdk-527/webrev.03/

Thanks a lot!
On 07/25/2012 11:19 PM, Michael McMahon wrote:

On 24/07/12 07:17, Deven You wrote:

Hi Alan and Michael,

I add a java doc\[1\] for the new networkaddress.cache.localhost.ttl property. Please take a look when you have time.

The change looks fine to me. There is a typo in the apidoc in InetAddress.
"as as" should be "as an". Might as well correct the same mistake in the previous
paragraph also.

Since this is a spec change, it will need a CCC request. Is there a bug id for this issue?

Again, I don't know how to set cachePolicyPropFallback/negativeCachePolicyPropFallback. Any suggestion please tell me.

These are system properties. So, they are normally set on the command line with java -Dsun.net.inetaddr.ttl=X ....

\- Michael.

\[1\] http://cr.openjdk.java.net/\~youdwei/ojdk-527/webrev.01/
Thanks a lot!

On 07/12/2012 02:59 PM, Deven You wrote:

Hi Alan and Michael,

Thanks very much for your kind suggestions.

I agree that local host shouldn't follow the default caching mechanism because the IP may change frequently. And I also think making the cache time configurable is a better solution.

I am willing to make these changes including adding the local host caching mechanism into the java doc.

I have gone through the related code for InetAddress.java and InetAddressCachePolicy.java. And I think we could add a new security property networkaddress.cache.localhost.ttl to achieve the goal.

As far as I know, to add networkaddress.cache.localhost.ttl I need change jdk/src/share/lib/security/java.security\*(include java.security, java.security-solaris, java.security-macosx and java.security-windows). Please correct me if I have any misunderstanding.

Here I have one question need your help:
��� the static block in InetAddressCachePolicy.java will first try to get cachePolicyProp/negativeCachePolicyProp from System properties. If one of the cache values is null then the value of cachePolicyPropFallback/negativeCachePolicyProp would be got from System properties.
�� I don't know where we declare these fallback properties so I have no idea where I can do the same thing for networkaddress.cache.localhost.ttl.

Please take a look.

Thanks a lot!


On 07/11/2012 06:55 PM, Michael McMahon wrote:

On 11/07/12 08:00, Alan Bateman wrote:

On 05/07/2012 07:10, Deven You wrote:

Hi All,

I noticed that InetAddress.getLocalHost() uses cache to improve the performance. However the default implementation is caching local host within 5 seconds.

From the spec, networkaddress.cache.ttl should be used to control the cache behaviour and I think it is a better solution.

For example, if the networkaddress.cache.ttl is set to -1 which means always cache the local host then we can avoid unnecessary operations on getAddressesFromNameService to improve the performance.

I have made a patch for this solution, so anyone would like to take a look?

\[1\] http://cr.openjdk.java.net/\~littlee/OJDK-527/webrev.00/
Thanks a lot!

--   
Best Regards,

Deven

I'm not sure about this one as I suspect it will
cause problems in DHCP or any environments where the
host addresses changes, say moving to a different
wireless network or waking up a machine after
hibernation.



-Alan

That's true. We updated the spec for the caching
behavior a while back, and probably should have
included this exception

for the local host. I agree that we shouldn't change
the behavior. Perhaps, the 5 seconds could be
configurable itself,

but I think it should be kept separate from the main
caching behavior.



- Michael.

--
Best Regards,

Deven

--
Best Regards,

Deven

--
Best Regards,

Deven

--
Best Regards,

Deven

--
Best Regards,

Deven