René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SecureRandom causes high lock contention in heavy-volume environments","articleBody":"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`.\r\n\r\nIn 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`.\r\n\r\nI 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.\r\n\r\nSome thoughts:\r\n- 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.\r\n- If dnsjava makes secure random generation pluggable, heavy users could provide their own implementation that perform better under high concurrency.\r\n- Another property can be added to disable the use of `SecureRandom`, which might be safe when dnsjava is used with a local recursive resolver.\r\n\r\n","author":{"url":"https://github.com/ivanr-rs","@type":"Person","name":"ivanr-rs"},"datePublished":"2025-01-08T12:31:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/368/dnsjava/issues/368"}