SEC-1615: Very slow startup times #1856

Closed
spring-issuemaster opened this Issue Nov 6, 2010 · 2 comments

1 participant

@spring-issuemaster

Oliver Siegmar (Migrated from SEC-1615) said:

Since Spring Security 3 I notice, that the startup time of my web applications vary greatly on each startup. One of my simple applications sometimes starts in 3 secs, sometimes it takes up to 40 seconds (same non-busy system). I enabled debug logging and noticed the following:

Slow startup (> 30 secs):

2010-11-06 14:46:10,394 INFO org.springframework.security.config.SecurityNamespaceHandler: Spring Security 'config' module version is 3.0.4.RELEASE
2010-11-06 14:46:40,235 INFO org.springframework.security.config.http.HttpSecurityBeanDefinitionParser: Checking sorted filter chain: [REMOVED VERY LARGE CONTENT]

(there are ~ 30 secs between these to log entries)

Fast startup (~ 3 secs):

2010-11-06 15:03:19,737 INFO org.springframework.security.config.SecurityNamespaceHandler: Spring Security 'config' module version is 3.0.4.RELEASE
2010-11-06 15:03:19,840 INFO org.springframework.security.config.http.HttpSecurityBeanDefinitionParser: Checking sorted filter chain: [REMOVED VERY LARGE CONTENT]

(there are ~ 0.1 secs between these to log entries)

Of course this is from the same application without any changes - simply stopped and restarted tomcat.

I did a thread dump to see what is going on while waiting:

"main" prio=10 tid=0x00000000414b1000 nid=0x2850 runnable [0x00007f42e08d1000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:199)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
- locked <0x00007f42db893378> (a java.io.BufferedInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
- locked <0x00007f42db893040> (a java.io.BufferedInputStream)
at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
- locked <0x00007f42db892888> (a sun.security.provider.SecureRandom)
at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
- locked <0x00007f42db892e78> (a java.security.SecureRandom)
at java.security.SecureRandom.next(SecureRandom.java:455)
at java.util.Random.nextLong(Random.java:284)
at org.springframework.security.config.http.AuthenticationConfigBuilder.createAnonymousFilter(AuthenticationConfigBuilder.java:391)
at org.springframework.security.config.http.HttpSecurityBeanDefinitionParser.parse(HttpSecurityBeanDefinitionParser.java:106)
at org.springframework.security.config.SecurityNamespaceHandler.parse(SecurityNamespaceHandler.java:86)

[...]

As you can see the problem seems to be an IO-wait caused by java.util.random / java.security.SecureRandom - but why doesn't this happen with Spring Security 2.x ?

I guess this is related to SEC-1386 (but I'm not in a virtual machine).

Is there any workaround available? Can this be improved in Spring Security? Even if it cannot, it should be documented as a known problem.

@spring-issuemaster

Luke Taylor said:

This is a problem with using SecureRandom on your system rather than something specific to Spring Security. As described in the other issue, you cans try setting securerandom.source. You will also find other similar discussions and potential solutions if you search the web since SecureRandom is used in many different situations. In this case, it is only being used to create the token associated with the anonymous filter, so you can disable anonymous authentication if you don't need it.

@spring-issuemaster

Luke Taylor said:

As a workaround, I've made changes to create the SecureRandom on demand, so if you set a key manually using (and do the same in the element if using it) then this will prevent any delay caused by seeding the SecureRandom.

@spring-issuemaster spring-issuemaster added this to the 3.1.0.M2 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment