Skip to content

SecureRandom causes high lock contention in heavy-volume environments #368

@ivanr-rs

Description

@ivanr-rs

We're using dnsjava in a high-volume environment. We've observed high lock contention related to the secure random number generation. Ultimately, the issue is that the JDK's NativePRNG has a synchronized block on the hot path in implNextBytes.

In dnsjava, SecureRandom is used for header IDs and in NioUdpClient. The latter can be disabled [when it's safe] with dnsjava.udp.ephemeral.use_ephemeral_port.

I wanted to document this problem but, because it probably doesn't affect a lot of people, I am not sure what should be done, if anything. We're using a fork that works around this and a couple of other problems.

Some thoughts:

  • In the ideal world, Java would perhaps provide ThreadLocalSecureRandom that caches randomness at thread level to reduce pressure on NativePRNG. This would resolve the contention except in a highly-inefficient and unlikely scenario with short-lived threads.
  • If dnsjava makes secure random generation pluggable, heavy users could provide their own implementation that perform better under high concurrency.
  • Another property can be added to disable the use of SecureRandom, which might be safe when dnsjava is used with a local recursive resolver.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions