We have an app running on App Engine and using Spring framework. Recently we have added some new features that are based on AOP. We decided to use @AspectJ style hence we added <aop:aspectj-autoproxy>
into our XML based configuration and implemented respective aspects. Everything is working OK on development server, however, when deployed to the cloud environment we get java.lang.StackOverflowError
every time the app is being initialized.
The bean that cannot be created and causes the error is configuration class annotated with @Configuration
annotation. It seems that basically any configuration bean can cause the error.
Below you can see the corresponding stack trace.
org.springframework.web.context.ContextLoader initWebApplicationContext: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'objectifyConfig' defined in URL [jar:file:/base/data/home/apps/{app-id}/8.372375422460842231/WEB-INF/lib/{app-name}-1.0-SNAPSHOT.jar!/{path-to-class}/ObjectifyConfig.class]: Initialization of bean failed; nested exception is java.lang.StackOverflowError
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:219)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:194)
at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:446)
at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:435)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:442)
at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:186)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:306)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:298)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:439)
at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.StackOverflowError
at java.util.concurrent.ConcurrentSkipListSet.contains(ConcurrentSkipListSet.java:214)
at sun.misc.URLClassPath$LoaderSearchCursor.nextLoader(URLClassPath.java:598)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:365)
at sun.misc.URLClassPath.findResource(URLClassPath.java:213)
at java.net.URLClassLoader$2.run(URLClassLoader.java:551)
at java.net.URLClassLoader$2.run(URLClassLoader.java:549)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:548)
at com.google.apphosting.runtime.security.UserClassLoader.findResource(UserClassLoader.java:723)
at java.lang.ClassLoader.getResource(ClassLoader.java:1142)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:757)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:751)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.security.UserClassLoader.findResource(UserClassLoader.java:751)
at java.lang.ClassLoader.getResource(ClassLoader.java:1142)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:757)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:751)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.security.UserClassLoader.findResource(UserClassLoader.java:751)
at java.lang.ClassLoader.getResource(ClassLoader.java:1142)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:757)
at com.google.apphosting.runtime.security.UserClassLoader$3.run(UserClassLoader.java:751)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.security.UserClassLoader.findResource(UserClassLoader.java:751)
at java.lang.ClassLoader.getResource(ClassLoader.java:1142)
...
Update: I put the issue into the App Engine issue tracker along with the sample app that demonstrates the problem. Please follow the link to see details.
Spring AOP is a proxy-based framework, so there is the creation of proxies at the time of application startup. Also, there are a few more method invocations per aspect, which affects the performance negatively.
Increase Thread Stack Size (-Xss) Increasing the stack size can be useful, for example, when the program involves calling a large number of methods or using lots of local variables. This will set the thread's stack size to 4 mb which should prevent the JVM from throwing a java. lang. StackOverflowError .
A stack overflow is a type of buffer overflow error that occurs when a computer program tries to use more memory space in the call stack than has been allocated to that stack.
A StackOverflowError is a runtime error in Java. It is thrown when the amount of call stack memory allocated by the JVM is exceeded. A common case of a StackOverflowError being thrown, is when the call stack exceeds due to excessive deep or infinite recursion.
It seems that the issue has been fixed in App Engine version 1.9.7. See more details here.
A stack overflow usually indicates an infinite loop. With aspectj you could have this in the following case:
Class Logger {
@Autowired
ConfigService conf;
//... used for logging intercepted methods
}
Class ConfigServiceImpl implements ConfigService {
//... this is used to retrieve config
}
If you now use aspectj expressions that says: I want to log my configServiceImpl then you will also have infinite loop when using the configService:
I cannot explain why it is working on your local setup and not on app engine. Or why it is only when you are using @Configuration but I think you should look in the direction of a "circular dependency" like this.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With