[jira] [Commented] (FELIX-5816) Switch to java.util.Random for startup performance

["Karl Pauls (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424025#comment-16424025 ] 

Karl Pauls commented on FELIX-5816:
-----------------------------------

I did some testing and while I don't see any slowness when creating a SecureRandom on my system it is the case that getting the bytes is pretty slow. I think we should make this configurable.

> Switch to java.util.Random for startup performance
> --------------------------------------------------
>
>                 Key: FELIX-5816
>                 URL: https://issues.apache.org/jira/browse/FELIX-5816
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: framework-5.6.10
>            Reporter: Bradley D Wood
>            Priority: Major
>             Fix For: framework-6.0.0
>
>
> Mailing list thread:
> [https://www.mail-archive.com/users@felix.apache.org/msg18083.html]
> When starting Felix up and on my Windows machines I'm seeing a significant slowdown in startup time due to accessing my Windows network adapter in order to read the Mac address as part of SecureRandom which is used to generate a UUID for each Felix instance.By significant slowdown, I'm talking about 1.5 seconds, which may go unnoticed in a server startup, but is a week in CLI-startup years. :) Java libs that want to access my network adapter's Mac address are a common nemesis of my startup times, mostly due to Windows sucking from what I can tell. This line here is where things start to go south:
> [https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L675]
> And the stack traces usually look similar to this right here:
> {code:java}
> java.lang.Thread.State: RUNNABLE
>   at java.net.NetworkInterface.getMacAddr0(Native Method)
>   at java.net.NetworkInterface.getHardwareAddress(NetworkInterface.java:460)
>   at 
> sun.security.provider.SeedGenerator.addNetworkAdapterInfo(SeedGenerator.java:238)
>   at sun.security.provider.SeedGenerator.access$000(SeedGenerator.java:80)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:183)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:168)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> sun.security.provider.SeedGenerator.getSystemEntropy(SeedGenerator.java:168)
>   at 
> sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:201)
>   at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221)
>   - locked <0x00000007415f5f40> (a sun.security.provider.SecureRandom)
>   at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
>   at org.apache.felix.framework.util.Util.randomUUID(Util.java:795)
>   at org.apache.felix.framework.Felix.init(Felix.java:675)
>   at org.apache.felix.framework.Felix.init(Felix.java:626)
>   at org.apache.felix.framework.Felix.start(Felix.java:964)
>   ... unrelated bootstrapping code...
> {code}
> As was suggested on the mailing list, switch to java.util.random.
> As a workaround on my machine, I was able to implement this code from Stackoverflow which avoids SecureRandom entirely.
> {code}
> Optional.ofNullable( Security.getProvider( "SunMSCAPI" ) ).ifPresent( p->{
>     Security.removeProvider( p.getName() );
>     Security.insertProviderAt( p, 1 );
> } );
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)