felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <e...@zusammenkunft.net>
Subject Re: Felix startup performance on Windows due to secure random and network card MAC access
Date Fri, 23 Mar 2018 03:35:38 GMT
You can also seed the SecureRandom yourself (with current time and hostname and similar) but
I think that’s a very specific driver/Hardware problem)

From: Karl Pauls <karlpauls@gmail.com>
Sent: Friday, March 23, 2018 12:07:24 AM
To: users@felix.apache.org
Subject: Re: Felix startup performance on Windows due to secure random and network card MAC

I think we could probably just switch to using java.util.Random
instead of SecureRandom. Could you open a jira issue for this?



On Thu, Mar 22, 2018 at 11:45 PM, Brad Wood <bdw429s@gmail.com> wrote:
> Hi all, first time poster here.  I'm working on a CLI project called
> CommandBox ( https://www.ortussolutions.com/products/commandbox ) which is
> based on a JSR-223 implementation of the JVM language Lucee Server (
> http://lucee.org/ ).  Lucee uses Apache Felix internally when it starts 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:
> 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...
> Based on the comments and a quick review of the code, I'm guessing the
> generation of a UUID of some sort is unavoidable.  What are the
> chances of switching to some other, much faster library for UUID
> generation that doesn't need to drop down the rabbit hole of asking my
> Windows networking stack for a Mac address?  This will make a huge
> difference in my CLI startup times for sure.
> Perhaps a library like this could be used:
> https://github.com/jchambers/fast-uuid
> Thanks!
> ~Brad
> *Developer Advocate*
> *Ortus Solutions, Corp *
> E-mail: brad@coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com

Karl Pauls

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message