The Wayback Machine - https://web.archive.org/web/20211018205126/https://github.com/scala-native/scala-native/issues/2310
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Caching bug in InetAddress.scala #2310

Open
LeeTibbert opened this issue May 21, 2021 · 1 comment
Open

Caching bug in InetAddress.scala #2310

LeeTibbert opened this issue May 21, 2021 · 1 comment
Labels
bug good first issue

Comments

@LeeTibbert
Copy link
Contributor

@LeeTibbert LeeTibbert commented May 21, 2021

Whilst chasing other issues, I noticed that the caching in InetAddress.scala is well intended
but questionable:

def getHostName(): String = {
    if (host == null) {
      val ipString = createIPStringFromByteArray(ipAddress)
      host = SocketHelpers
        .ipToHost(ipString, isValidIPv6Address(ipString))
	.getOrElse {
          ipString
        }
    }
    host
  }

Imagine using this in a long (weeks, months, years) duration server. The name associated
with the numeric address could change over that period. A trip to the bind server on each
call is more expensive, but significant work has been done over decades to make the
bind server cashing both correct & (relatively) low cost. IMO, the proper thing to do
here is to remove the caching ( if (host == null) { and closing bracket) and defer caching
to the bind server.

Now is this the most important of bugs? No. But a good first issue for someone.
@LeeTibbert
Copy link
Contributor Author

@LeeTibbert LeeTibbert commented May 22, 2021

I advise anyone picking up this Issue to read the Java 8 InetAddress specification carefully.

 By default, when a security manager is installed, in order to protect against DNS spoofing attacks, the result of positive host name resolutions are cached forever. When a security manager is not installed, the default behavior is to cache entries for a finite (implementation dependent) period of time. The result of unsuccessful host name resolution is cached for a very short period of time (10 seconds) to improve performance.

If the default behavior is not desired, then a Java security property can be set to a different Time-to-live (TTL) value for positive caching. Likewise, a system admin can configure a different negative caching TTL value when needed.

Skipping lightly over the security manager discussion (I believe that such is entirely unimplemented
in Scala Native javalib), I believe the fragment the default behavior is to cache entries for a finite (implementation dependent) period of time. justifies & grounds my concern in the base note. (probably , for implementation
espediency, just timeout == 0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug good first issue
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
@LeeTibbert