DNS Caching in Play WS API

[Yiftah Frechter]

Hi,

We are working with WS api to perform HTTP request to different web services in our internal cloud.

The usage is straight forward:

WS.url(uri).execute("GET")

The problem we are having is that in the case IP changing in this cloud (usually due to failover or servers reboot) the DNS records in Play Framework are not updated.

We assume it's probably due to caching in Netty DNS resolver.

Assuming this assumption is correct. Few questions:

1. Is there a reason netty dns resolver do not comply with DNS TTL?

2. How do you access netty code to set maxttl (http://netty.io/4.1/api/io/netty/resolver/dns/DefaultDnsCache.html) from within play framework (java or scala)?

Thanks,

Yiftah

[Christian Schmitt]

This is a "problem" of java. Not Netty, currently Play/async-http-client uses Netty 4.0 which uses the java ttl.
In Java you need to configure it via properties, see: http://docs.oracle.com/javase/6/docs/technotes/guides/net/properties.html#nct

You could actually have a Startup Eagerly Binded Guice Singleton that sets these Properties (also inject WS into it so that no Call will be made before the guice singleton up and ready) or set them via -D

[Will Sargent]

There is a bug open for this:

https://github.com/playframework/playframework/issues/1997

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/d6bf90c6-4b5f-4512-9376-55672705ed69%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

Also here:

https://github.com/AsyncHttpClient/async-http-client/issues/937

[Yiftah Frechter]

Hi,
Thank you for the prompt response.
We are already setting "networkaddress.cache.ttl" via -D but with no apparent effect.
It seems Play Framework/Netty related as with other java applications we maintain ,setting this option resolved the DNS issue.
It strike me extremely odd that a DNS client will not respect TTLs ...

Y

[Igmar Palsenberg]

Op zondag 24 april 2016 09:56:24 UTC+2 schreef Yiftah Frechter:

You're sure the configured solver isn't caching it ?

Igmar

[Igmar Palsenberg]

 

You're sure the configured solver isn't caching it ?

resolver that is.

Igmar

[Mariot Chauvin]

Hi Yiftah,

We had exactly this problem in the past as the WS library used, Ning (AsyncHttpClient), was keeping the connection opened so this was not the DNS that was cached, it was just that the connection remains open, preventing the DNS to be resolved again!

We fixed it by exposing the options of Ning allowing to have shorter connection, see the merged PR 

We have released a plugin for the 2.3.x branch to workaround the issue. 

Hope this help,

Mariot

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/7fbb15f5-e637-4dbb-b4e3-b1f7df61864c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.  Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

 

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered in England Number 908396

[Yiftah Frechter]

Hi,

We eventually found out the the VJM option we were using(“networkaddress.cache.ttl") was not allowed with -D as it is security option and thus JVM was caching the record forever.

There is an alternative JVM option that worked for us:

-Dsun.net.inetaddr.ttl=0

So this is now resolved.

Thanks everyone for the help.

-- 
Yiftah 

You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/biinMjbWo2w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAGHe3PnrT4LLtYNO5d3a1ZiMiS20XBJ68G4dYcrfhwuTicR1ag%40mail.gmail.com.

[Christian Schmitt]

You should still set networkaddress.cache.ttl via security options inside your code inside a Eager binded Singleton: Security.setProperty("networkaddress.cache.ttl" , "0"); if you switch to openjdk 9 when it comes out,  sun.net.inetaddr could make unnecessary problems