volosied commented on code in PR #911:
URL: https://github.com/apache/myfaces/pull/911#discussion_r2286018867
##########
impl/src/main/java/org/apache/myfaces/util/token/SessionIdGenerator.java:
##########
@@ -18,35 +18,19 @@
*/
package org.apache.myfaces.util.token;
-import java.security.NoSuchAlgorithmException;
-import java.security.NoSuchProviderException;
import java.security.SecureRandom;
-import java.util.Queue;
-import java.util.concurrent.ConcurrentLinkedQueue;
-import java.util.logging.Level;
-import java.util.logging.Logger;
-import org.apache.myfaces.util.lang.ClassUtils;
-import org.apache.myfaces.util.lang.StringUtils;
-
/**
* NOTE: Class taken from tomcat 7 org.apache.catalina.util.SessionIdGenerator
* and used here as an alternative for server side state token encryption.
*
*/
public class SessionIdGenerator
-{
-
- private static Logger log =
Logger.getLogger(SessionIdGenerator.class.getName());
-
- /**
- * Queue of random number generator objects to be used when creating
session
- * identifiers. If the queue is empty when a random number generator is
- * required, a new random number generator object is created. This is
- * designed this way since random number generators use a sync to make them
- * thread-safe and the sync makes using a a single object slow(er).
+{
+ /*
+ * For performance, isolating SecureRandom between threads.
*/
- private Queue<SecureRandom> randoms = new ConcurrentLinkedQueue<>();
-
+ private static ThreadLocal<SecureRandom> randomLocal = new
ThreadLocal<>();
+
Review Comment:
I removed the queue as I don't think it's necessary anymore?
SecureRandom has been thread safe for years now (since Java 7). However,
it's probaly not best to reuse the secure random instance with multiple
threads, but, if we make it thread local, then I think it should be safe?
I shouldn't expect any performance hits, at least.
Please review.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
