SecureRandom, nextFuncName, and thread contention

[Antonio Salazar Cardozo]

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

[David Pollak]

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

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Antonio Salazar Cardozo]

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

[Maarten Koopmans]

Maybe swap behavior based on the Java version, much like we do with web containers? So you always get the best experience possible.

--Maarten

[David Pollak]

Automagic sounds like a good solution.

[Antonio Salazar Cardozo]

Hm… So would we use reflection to do that?

Thanks,

Antonio

[David Pollak]

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

[Antonio Salazar Cardozo]

A'ight. I'm on it like a fly on flypaper. Assuming that's very on it. :p

Thanks,

Antonio

[Antonio Salazar Cardozo]

Pull request at https://github.com/lift/framework/pull/1332 should take care of this.

Thanks,

Antonio

[David Pollak]

Done.

Thanks!

[Naftoli Gugenheim]

If a thread-local makes more sense performance-wise, then why not use a thread-local on any Java version? Does ThreadLocalRandom do anything we can't do ourselves?