SecureRandom, nextFuncName, and thread contention

Showing 1-11 of 11 messages
SecureRandom, nextFuncName, and thread contention Antonio Salazar Cardozo 10/10/12 5:25 PM
Hello all,
I've been profiling our application today looking for contention between threads and such and noticed that our last remaining bastion of thread contention seemed to be nextFuncName. nextFuncName uses StringHelpers.randomString, which eventually uses a SecureRandom instance. To deal with thread safety issues, this SecureRandom instance's access is wrapped in a synchronized block.

From what I could find out there (e.g., http://stackoverflow.com/questions/1461568/is-securerandom-thread-safe ), SecureRandom is already thread safe. That said, it is thread safe by using locks as well, so I doubt it would attend to our problem of threads locked waiting for other threads generating func names. The aforementioned Stack Overflow thread mentions ThreadLocalRandom to deal with thread lock contention issues, but that's Java 7 only, so that doesn't seem like something that could roll into Lift proper. Could we do our own thing in Lift whereby we would use a thread-local SecureRandom instance in StringHelpers instead of a global one, thus avoiding lock contention on this rather frequently used corner of the framework?
Thanks,
Antonio
Re: [Lift] SecureRandom, nextFuncName, and thread contention David Pollak 10/10/12 8:35 PM
How about a function that you can set that does the random number generation and you can set it to ThreadLocalRandom for you app?

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 



--
Telegram, Simply Beautiful CMS https://telegr.am
Lift, the simply functional web framework http://liftweb.net


Re: [Lift] SecureRandom, nextFuncName, and thread contention Antonio Salazar Cardozo 10/10/12 9:01 PM
I don't mind that at all. I suppose if the relevant contention were a broad enough problem to warrant having a thread-local solution at the framework level, I wouldn't be the first to bring it up :)
Thanks,
Antonio
Re: [Lift] SecureRandom, nextFuncName, and thread contention maarten 10/10/12 9:32 PM
Maybe swap behavior based on the Java version, much like we do with web containers? So you always get the best experience possible.

--Maarten
Re: [Lift] SecureRandom, nextFuncName, and thread contention David Pollak 10/11/12 8:08 AM
Automagic sounds like a good solution.
Re: [Lift] SecureRandom, nextFuncName, and thread contention Antonio Salazar Cardozo 10/11/12 8:47 AM
Hm… So would we use reflection to do that?
Thanks,
Antonio
Re: [Lift] SecureRandom, nextFuncName, and thread contention David Pollak 10/11/12 8:57 AM


On Thu, Oct 11, 2012 at 8:47 AM, Antonio Salazar Cardozo <savedf...@gmail.com> wrote:
Hm… So would we use reflection to do that?

Yeah... look for thread local random, use it if it's there, otherwise do a locked single random instance
Re: [Lift] SecureRandom, nextFuncName, and thread contention Antonio Salazar Cardozo 10/11/12 11:25 AM
A'ight. I'm on it like a fly on flypaper. Assuming that's very on it. :p
Thanks,
Antonio
Re: [Lift] SecureRandom, nextFuncName, and thread contention Antonio Salazar Cardozo 10/11/12 1:38 PM
Pull request at https://github.com/lift/framework/pull/1332 should take care of this.
Thanks,
Antonio
Re: [Lift] SecureRandom, nextFuncName, and thread contention David Pollak 10/11/12 3:31 PM
Done.

Thanks!
This message has been hidden because it was flagged for abuse.