[
https://issues.jboss.org/browse/WFCORE-490?page=com.atlassian.jira.plugin...
]
James Livingston edited comment on WFCORE-490 at 1/13/15 11:45 PM:
-------------------------------------------------------------------
The second one (line 401) is per boot of the server, but the first (line 337) is per
request in internalExecute(). It could occur more than once per request if the attempt at
putting it in the activeOperations map fails due to there already being an operation with
the same id.
With JDK 7+, java.util.Random instances are guaranteed to be thread safe (albeit
potentially slower under contention), so a single random instance could be shared between
threads as long as the operation ID didn't have to be a secure random number. Any loss
of performance from concurrent access would be outweighed by the fact it no longer has to
gather entropy from the OS to initialise the SecureRandom object.
was (Author: jameslivingston):
The second one (line 401) is per boot of the server, but the first (line 337) is per
request in internalExecute(). It could occur more than once per request if the attempt at
putting it in the activeOperations map fails due to there already being an operation with
the same id.
ModelControllerImpl uses SecureRandom per request
-------------------------------------------------
Key: WFCORE-490
URL:
https://issues.jboss.org/browse/WFCORE-490
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 1.0.0.Alpha15
Reporter: James Livingston
Assignee: Brian Stansberry
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
and
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
create a new SecureRandom which is used to seed a normal Random, and that is thrown away
after one use. That causes it to use entropy from the OS pool, which if done at a
sufficiently high rate on servers can cause stalls.
I can't think of any reason why the operation ID would need to be a secure random
number rather than a normal one, so unless there is one it may be better to use a normal
Random and not drain the entropy pool.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)