Bug 1036624 - SecureRandomGenerator instance per container requires too much entropy
Summary: SecureRandomGenerator instance per container requires too much entropy
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Performance, Portal
Version: 6.1.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: DR02
: 6.1.1
Assignee: mposolda
QA Contact: Tomas Kyjovsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-02 11:24 UTC by Dominik Pospisil
Modified: 2019-01-01 03:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The SecureRandom service is a portal service used for generating random numbers for security purposes. The service requires a seed for each instance of the service. It was discovered that because a separate SecureRandom service was required for each portal instance, installations containing many portal instances may have been experiencing slower boot times as a result of individual seed creation for each SecureRandom bootstrap. The fix implements SecureRandom as a shared service between all portal instances, which results in an improved startup time for installations containing many portal instances.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker GTNPORTAL-3342 0 Major Resolved SecureRandomGenerator instance per container requires too much entropy 2017-04-01 08:20:15 UTC

Description Dominik Pospisil 2013-12-02 11:24:08 UTC 
Currently every portal container instance uses it's own instance of SecureRandomGenerator for generating password salts. This requires too much entropy if many containers are used (50).

In QA lab environment, registering new generator freezes portal boot for roughly 20-30s (1 min 40s max).
Comment 1 Dominik Pospisil 2013-12-02 11:25:19 UTC 
Link to the CI build showing boot freezes:

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EPP/view/EPP/view/6.1/view/Performance/view/Preparation/job/epp6_portal_perf_db_prepare_manyContainers/18/console
Comment 3 JBoss JIRA Server 2013-12-09 23:08:45 UTC 
Marek Posolda <mposolda> made a comment on jira GTNPORTAL-3342

The fix is adding SecureRandomService to be configured at RootContainer level, so it's shared between all portal containers and initialized only once per JVM.
Comment 4 Dominik Pospisil 2014-01-31 14:22:05 UTC 
It does not seem to be fixed in 6.1.1.ER1.

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EPP/view/EPP/view/6.1/view/Performance/view/Preparation/job/epp6_portal_perf_db_prepare_manyContainers/21/console
Comment 5 Dominik Pospisil 2014-01-31 15:04:07 UTC 
After discussion with Marek, closing as verified. Reseed only happen once during portal startup. Remaining delay caused by other tasks.
Comment 7 Peter Palaga 2014-02-11 07:46:00 UTC 
Hi Jared, just a small note on the last version of the relnote: The term "portal" is terribly ambiguous in general and also in how we use it ourselves. It can mean (1) the product, (2) an installation of the product and (3) a Portal Container as described in https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Portal/6.1/html/Development_Guide/chap-Portal_Containers.html . When speaking about "portal instance" in the relnote, it is perhaps not clear at the first sight if we mean (2) or (3). Therefore, I'd propose to replace "portal instance" with "portal container instance".
Note You need to log in before you can comment on or make changes to this bug.