Hi sometimes i encoutner this error after restarsting sun application server 8.2 domain anyone have any idea what could be the reason?
javax.servlet.ServletException at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:255) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:860) at
sun.reflect.GeneratedMethodAccessor156.invoke(Unknown
Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:585) at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249) at
java.security.AccessController.doPrivileged(Native
Method) at
javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282) at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257) at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161) at
java.security.AccessController.doPrivileged(Native
Method) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723) at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:484) at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:417) at
org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:80) at
org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:95) at
java.security.AccessController.doPrivileged(Native
Method) at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:313) at
org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:448) at
org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:339) at
org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:282) at
org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:184) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:552) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551) at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933) at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189) at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604) at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475) at
com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371) at
com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264) at
com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281) at
com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)-----
Root Cause
-----java.lang.StackOverflowError at java.security.AccessController.doPrivileged(Native
Method) at
com.sun.security.auth.PolicyFile.getPermissions(PolicyFile.java:818) at
javax.security.auth.SubjectDomainCombiner$3.run(SubjectDomainCombiner.java:357) at
java.security.AccessController.doPrivileged(Native
Method) at
javax.security.auth.SubjectDomainCombiner.combineJavaxPolicy(SubjectDomainCombiner.java:353) at
javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:191) at
java.security.AccessControlContext.goCombiner(AccessControlContext.java:390) at
java.security.AccessControlContext.optimize(AccessControlContext.java:304) at
java.security.AccessController.checkPermission(AccessController.java:426) at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at
java.security.Security.getProperty(Security.java:724) at
com.sun.security.auth.PolicyFile.initPolicyFile(PolicyFile.java:356) at
com.sun.security.auth.PolicyFile.init(PolicyFile.java:269) at
com.sun.security.auth.PolicyFile.getPermissions(PolicyFile.java:869) at
com.sun.security.auth.PolicyPermissions.init(PolicyFile.java:1416) at
com.sun.security.auth.PolicyPermissions.elements(PolicyFile.java:1429) at
javax.security.auth.SubjectDomainCombiner.combineJavaxPolicy(SubjectDomainCombiner.java:366) at
javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:191)
… ad inifinitum
Infinite recursion.
This is evident by your long, repeating backtrace. The fact that you receive a stack overflow error also supports this.
My guess is something with your security policy is triggering an infinitely recursive operation. Though there does not appear to be any application code involved, so it's hard to say for sure. Is the repeating section always bounded between calls to SubjectDomainCombiner?
One thing you can do you confirm it's truly an infinitely recursive problem is to increase the stack size. You should see the looping section expand to fill the remainder of the space when it does crash. Otherwise, you're just running low on stack... it does happen, especially when you've already got 30 or 40 frames on the stack from the application server framework itself.
The default stack size is 256k.
You can increase it by applying the JVM argument, for example -Xss2M to get 2MB of stack.
Do this just to confirm the problem, not as a permanent solution.
Related
I'm using RestAssured.get(url).statusCode() to see if a url is working and respond successfully(Code 200) or not. In case of some urls(like url1) it properly works but for some urls(such as url2) it will cause the following error:
String url1="http://www.bbsys.com/playersdemo.exe"
String url2="http://www.ezhomeinspectionsoftware.com/filestorage/EZ-Setup.exe"
both of these urls result in downloading files. But the second one downloads a bigger file. So, probably that's why it cause out of memory exception. I need to know how can I handle cases like this. I need to get response from a large number of different urls. Do you recommend using another library or I'm using this library in a wrong way?
java.lang.OutOfMemoryError: Java heap space
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3236)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
at io.restassured.internal.util.IOUtils.toByteArray(IOUtils.java:31)
at io.restassured.internal.http.GZIPEncoding$GZIPDecompressingEntity.getContent(GZIPEncoding.java:69)
at org.apache.http.conn.BasicManagedEntity.getContent(BasicManagedEntity.java:85)
at io.restassured.internal.http.HTTPBuilder.parseResponse(HTTPBuilder.java:545)
at io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.super$2$parseResponse(RequestSpecificationImpl.groovy)
at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1215)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.parseResponse(RequestSpecificationImpl.groovy:2137)
at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:59)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:174)
at io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.doRequest(RequestSpecificationImpl.groovy:2073)
at io.restassured.internal.http.HTTPBuilder.doRequest(HTTPBuilder.java:494)
at io.restassured.internal.http.HTTPBuilder.request(HTTPBuilder.java:451)
at io.restassured.internal.http.HTTPBuilder$request$2.call(Unknown Source)
at io.restassured.internal.RequestSpecificationImpl.sendHttpRequest(RequestSpecificationImpl.groovy:1450)
at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
Do you actually want to download the files or do you only want to check if the url is alive?
If not take, a look at the head method (https://static.javadoc.io/io.rest-assured/rest-assured/3.0.7/io/restassured/RestAssured.html#head-java.lang.String-java.util.Map-), to send a head request without triggering the download.
Otherwise your only option is to provide sufficient memory, as #Roberto suggested.
We have below code in our project and although it works fine but randomly we get class def not found error at runtime. Our App servers are restarted on each Sunday so sometimes we get this error on any random server instance.
Server restart fix the problem but any clue as why the class loading breaks in between.
I got somewhat similar error in this question and seems the issue is fixed in jdk 9 Transforming lambdas in Java 8
But before I conclude can someone explain it is the same kind of error and why it happens occasionally.
public boolean isAttachmentExpired(final Document_Attachment da) {
return this.bcDocumentScreen.getValidator().getAttachmentsValidator().isAttachmentExpired(da);
}
public boolean isAttachmentWarningShown() {
return CollectionUtils.isNotEmpty(getAttachments()) && getAttachments().stream().anyMatch(this::isAttachmentExpired);
}
public boolean isAttachmentExpired(final Document_Attachment da) {
final Date today = DateHelper.today();
return DateHelper.diffInYears(today, da.getUploaded()) >= 1;
}
Error:-
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor1913.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.persistence.ManagedEntityInterceptor.aroundInvoke(ManagedEntityInterceptor.java:48)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114)
at com.XXX.BcdAttachmentsSection_$$_javassist_seam_91.isAttachmentWarningShown(BcdAttachmentsSection_$$_javassist_seam_91.java)
at sun.reflect.GeneratedMethodAccessor1912.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at org.jboss.el.parser.AstPropertySuffix.getValue(AstPropertySuffix.java:53)
at org.jboss.el.parser.AstValue.getValue(AstValue.java:67)
at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
... 122 more
Caused by: java.lang.NoClassDefFoundError: com/XXX/docsections/BcdAttachmentsSection$$Lambda$75
at com.XXX.BcdAttachmentsSection$$Lambda$75/1736532374.get$Lambda(Unknown Source)
at com.XXXX.isAttachmentWarningShown(BcdAttachmentsSection.java:51)
... 150 more
It’s quite possible that the bug, you have linked does apply, if Instrumentation is involved. Consider this bug, JDK-8027681, “Lambda serialization fails once reflection proxy generation kicks in”, that affected all Reflection operations that are performed more than 16 times (this is a configurable threshold), as the underlying implementation will optimize subsequent calls by generating an accessor class, consisting of bytecode that HotSpot can inline. This bytecode failed to access the anonymous classes generated for lambda expressions in early version of Java 8.
While this bug has been fixed, the described behavior of generating classes after a certain number of invocations still exists, so if an agent attempts to instrument these generated classes, it would fail due to the still existing Instrumentation bug and the dependency to the number of invocations is likely the reason why this only occurs occasionally.
While this bug in the Instrumentation/JVM should be fixed (and will be fixed in the next release), it would also help not trying to instrument these classes. Normally, there should be no reason to instrument these internal helper classes.
everyone,when i use kettle to do loop,the error occured,the kettle's memory is 8G ，I used hundreds of cycles，Kettle to cycle 1500 times, when the cycle time to about 700 times the error occourd.how can i solve it
ERROR (version 5.0.1-stable, build 1 from 2013-11-15_16-08-58 by buildguy) : java.lang.StackOverflowError
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:772)
at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1057)
at sun.misc.URLClassPath$FileLoader.findResource(URLClassPath.java:1024)
at sun.misc.URLClassPath.findResource(URLClassPath.java:172)
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 java.lang.ClassLoader.getResource(ClassLoader.java:1138)
at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227)
at org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.findJarServiceProvider(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown Source)
at org.pentaho.di.core.xml.XMLHandler.loadXMLFile(XMLHandler.java:553)
at org.pentaho.di.core.xml.XMLHandler.loadXMLFile(XMLHandler.java:515)
at org.pentaho.di.core.xml.XMLHandler.loadXMLFile(XMLHandler.java:501)
at org.pentaho.di.trans.TransMeta.<init>(TransMeta.java:2797)
at org.pentaho.di.trans.TransMeta.<init>(TransMeta.java:2774)
at org.pentaho.di.trans.TransMeta.<init>(TransMeta.java:2759)
at org.pentaho.di.job.entries.trans.JobEntryTrans.getTransMeta(JobEntryTrans.java:1166)
at org.pentaho.di.job.entries.trans.JobEntryTrans.execute(JobEntryTrans.java:634)
at org.pentaho.di.job.Job.execute(Job.java:678)
at org.pentaho.di.job.Job.execute(Job.java:815)
at org.pentaho.di.job.Job.execute(Job.java:815)
at org.pentaho.di.job.Job.execute(Job.java:815)
I'm no expert in Kettle. However, a StackOverflowError is NOT caused by running out of memory, so the fact that you have an 8Gb heap is not directly relevant. What is relevant is the size of the thread stack. That is controlled by the java command's -Xss command-line option.
I also don't know what you mean by "cycles" in the context of Kettle ... and Google isn't helping me. However, I guess it is something to do with Jobs that cause other Jobs to run. And since you hit the limit at ~700 and need to get to ~1500, you probably need to triple the current thread stack size ... whatever that may be.
I have an application which manipulates the rows of a google spreadsheet. Occasionally, when I call ListEntry.update(), I receive the following stack trace:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: com.google.gdata.util.PreconditionFailedException: Precondition Failed
Mismatch: etags = ["E10QemAgYit7ImA-CEFaShYM"], version = [2ag9hk74om621l]
at com.google.gdata.client.http.HttpGDataRequest.handleErrorResponse(HttpGDataRequest.java:614)
at com.google.gdata.client.http.GoogleGDataRequest.handleErrorResponse(GoogleGDataRequest.java:564)
at com.google.gdata.client.http.HttpGDataRequest.checkResponse(HttpGDataRequest.java:560)
at com.google.gdata.client.http.HttpGDataRequest.execute(HttpGDataRequest.java:538)
at com.google.gdata.client.http.GoogleGDataRequest.execute(GoogleGDataRequest.java:536)
at com.google.gdata.client.Service.update(Service.java:1563)
at com.google.gdata.client.Service.update(Service.java:1530)
at com.google.gdata.client.GoogleService.update(GoogleService.java:597)
at com.google.gdata.data.BaseEntry.update(BaseEntry.java:639)
at feedProcessor.ProcessClientFeed.UpdateRow(ProcessClientFeed.java:466)
at feedProcessor.ProcessClientFeed.updateGoogleSpreadsheet(ProcessClientFeed.java:404)
at feedProcessor.ProcessClientFeed.processFeed(ProcessClientFeed.java:318)
at feedProcessor.ProcessClientFeed.main(ProcessClientFeed.java:61)
... 5 more
Here is the relevant documentation:
https://developers.google.com/gdata/javadoc/com/google/gdata/data/spreadsheet/ListEntry
https://developers.google.com/gdata/javadoc/com/google/gdata/data/BaseEntry#update()
According to these docs, the update() function is not even capable of throwing a PreconditionFailedException, so the docs are essentially useless here. Testing the issue has shown that this exception is thrown when you try to call the update() function on the same row more than once in a session. Exactly what defines a 'session' is still unclear, but if you loop through all your rows more than once, and call update() on each row in each iteration, you will get this error. The only resolution I am aware of is to write your software such that each row (ListEntry) has update() called only once.
The problem is caused by Google Spreadsheet API Resource Versioning mecanism.
To be able to edit the entry no matter what - just use:
entry.setEtag("*")
before update.
And yes, this is not multi-user friendly. Refetch the feed if you need multi-user support.
When I try to lease tasks from a pull queue in my application, I get the error below. This didn't happen previously with my code, so something has changed. I suspect that it's a threading issue - these calls are made in a separate thread (created using ThreadManager.createThreadForCurrentRequest) - has that recently been disallowed?
uk.org.jaggard.myapp.BlahBlahBlahRunnable run: Exception leasing tasks. Already tried 0 times.
com.google.apphosting.api.ApiProxy$CancelledException: The API call taskqueue.QueryAndOwnTasks() was explicitly cancelled.
at com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:218)
at com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:68)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:182)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:180)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:68)
at com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:323)
at com.googlecode.objectify.cache.TriggerFutureHook.makeSyncCall(TriggerFutureHook.java:154)
at com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:105)
at com.google.appengine.api.taskqueue.QueueApiHelper.makeSyncCall(QueueApiHelper.java:44)
at com.google.appengine.api.taskqueue.QueueImpl.leaseTasksInternal(QueueImpl.java:709)
at com.google.appengine.api.taskqueue.QueueImpl.leaseTasks(QueueImpl.java:731)
at uk.org.jaggard.myapp.BlahBlahBlahRunnable.run(BlahBlahBlahRunnable.java:53)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$1$1.run(ApiProxyImpl.java:997)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$1.run(ApiProxyImpl.java:994)
at java.lang.Thread.run(Thread.java:679)
at com.google.apphosting.runtime.ApiProxyImpl$CurrentRequestThreadFactory$2$1.run(ApiProxyImpl.java:1031)
I suspect the warnings in your application's logs will contain
"Thread was interrupted, throwing CancelledException."
Java's InterruptedException is discussed in
http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html
and the book "Java Concurrency in Practice".