I usually don't post this kind of questions, but this one is driving me crazy. I am using SeleniumWebDriver to filling a form and submitting it. I did this from my computer and it works perfectly, but when I upload the app to OpenShift I get a StackOverflowError when I submit the form. Here's the stacktrace:
[0m[31m04:29:06,529 ERROR [stderr] (Thread-110) Exception in thread "Thread-110" java.lang.StackOverflowError
[0m[31m04:29:06,542 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1311)
[0m[31m04:29:06,547 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1281)
[0m[31m04:29:06,547 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,548 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,548 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
[0m[31m04:29:06,564 ERROR [stderr] (Thread-110) at net.sourceforge.htmlunit.corejs.javascript.regexp.NativeRegExp.emitREBytecode(NativeRegExp.java:1286)
(he keeps going for a while but all the lines are the same...)
As you can see from the stacktrace, I am using HtmlUnit WebDriver. I googled this but I didn't find anybody with my exact problem, although it seems that HtmlUnit often gives StackOverflow errors...
Can anyone tell me if this is a bug or if am I missing something? Any help is really appreciated, thanks!
EDIT
Here's my code:
HtmlUnitDriver driver = new HtmlUnitDriver(BrowserVersion.CHROME);
driver.setJavascriptEnabled(true);
driver.get(myUrl);
//Finds the fields of the login form and fills it. Also removes the Remember me checkbox.
WebElement email = driver.findElement(By.id("email"));
email.clear();
email.sendKeys(username);
WebElement rememberMe = driver.findElement(By.name("persistent"));
if(rememberMe.isSelected())rememberMe.click();
WebElement pass = driver.findElement(By.id("pass"));
pass.clear();
pass.sendKeys(pass);
//HERE IS WHERE THE ERROR OCCURS:
pass.submit();
Instead of submit I've also tried to get the input manually from the button and click it like this:
WebElement button = driver.findElement(By.id("u_0_2"));
button.click();
but the problem is exactly the same...
Small gears have 512MB RAM and 1GB disk space each, so running such "resource intensive" applications might not be always possible and you might consider an upgrade to medium or large gear.
Also, trying to increase the stack size might be an option, see: How to increase the Java stack size?
You can check the Openshift Marketplace for monitoring cartridges.
Related
Im having trouble using Thingsboard platform (IoT) when simulating 7.5K devices sending data to the platform. I have the following error in the logs as soon as I start sending data (over MQTT):
2020-08-01 01:17:06,946 [ForkJoinPool-12-worker-0] ERROR c.g.c.u.concurrent.AggregateFuture - Got more than one input Future failure. Logging failures after the first
java.lang.IllegalStateException: Deque full
at java.util.concurrent.LinkedBlockingDeque.addLast(LinkedBlockingDeque.java:335)
at java.util.concurrent.LinkedBlockingDeque.add(LinkedBlockingDeque.java:633)
at org.thingsboard.server.dao.util.AbstractBufferedRateExecutor.submit(AbstractBufferedRateExecutor.java:109)
at org.thingsboard.server.dao.nosql.CassandraAbstractDao.executeAsync(CassandraAbstractDao.java:93)
at org.thingsboard.server.dao.nosql.CassandraAbstractDao.executeAsyncWrite(CassandraAbstractDao.java:76)
at org.thingsboard.server.dao.timeseries.CassandraBaseTimeseriesDao.savePartition(CassandraBaseTimeseriesDao.java:434)
at org.thingsboard.server.dao.timeseries.BaseTimeseriesService.saveAndRegisterFutures(BaseTimeseriesService.java:153)
at org.thingsboard.server.dao.timeseries.BaseTimeseriesService.save(BaseTimeseriesService.java:144)
at org.thingsboard.server.service.telemetry.DefaultTelemetrySubscriptionService.saveAndNotify(DefaultTelemetrySubscriptionService.java:124)
at org.thingsboard.rule.engine.telemetry.TbMsgTimeseriesNode.onMsg(TbMsgTimeseriesNode.java:89)
at org.thingsboard.server.actors.ruleChain.RuleNodeActorMessageProcessor.onRuleChainToRuleNodeMsg(RuleNodeActorMessageProcessor.java:107)
at org.thingsboard.server.actors.ruleChain.RuleNodeActor.onRuleChainToRuleNodeMsg(RuleNodeActor.java:97)
at org.thingsboard.server.actors.ruleChain.RuleNodeActor.doProcess(RuleNodeActor.java:60)
at org.thingsboard.server.actors.service.ContextAwareActor.process(ContextAwareActor.java:45)
at org.thingsboard.server.actors.TbActorMailbox.processMailbox(TbActorMailbox.java:121)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
I have try to google and see the reason behind it, but i havent found anything.
While simulating with 5K devices, this error came like 3 times each day (over a 4 day period), but it stopped showing that error eventually. However, when increasing the number of devices, the error is constant. Im using Kafka as the broker, but I dont see any Kafka related error. I just want to know why the error appears, is it related to memory, or any other limit?
Thanks in advance
Francisco P
I've got a spring boot rest service with embedded tomcat deployed on an Azure App Service and I am experiencing intermittent outages, every few weeks.
Every time there is an outage the logs contain the following entries:
Message: java.util.zip.ZipException: ZIP_Read: error reading zip file ZIP_Read: error reading zip file
Exception type: java.util.zip.ZipException
Failed method: java.util.zip.ZipFile.access$1400
With the following call stack.
java.lang.IllegalStateException:
at org.apache.catalina.webresources.JarWarResourceSet.getArchiveEntries (JarWarResourceSet.java133)
at org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource (AbstractArchiveResourceSet.java256)
at org.apache.catalina.webresources.StandardRoot.getResourceInternal (StandardRoot.java281)
at org.apache.catalina.webresources.CachedResource.validateResource (CachedResource.java97)
at org.apache.catalina.webresources.Cache.getResource (Cache.java69)
at org.apache.catalina.webresources.StandardRoot.getResource (StandardRoot.java216)
at org.apache.catalina.webresources.StandardRoot.getResource (StandardRoot.java206)
at org.apache.catalina.mapper.Mapper.internalMapWrapper (Mapper.java1027)
at org.apache.catalina.mapper.Mapper.internalMap (Mapper.java842)
at org.apache.catalina.mapper.Mapper.map (Mapper.java698)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest (CoyoteAdapter.java679)
at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java336)
at org.apache.coyote.http11.Http11Processor.service (Http11Processor.java803)
at org.apache.coyote.AbstractProcessorLight.process (AbstractProcessorLight.java66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process (AbstractProtocol.java868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun (NioEndpoint.java1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run (SocketProcessorBase.java49)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run (TaskThread.java61)
at java.lang.Thread.run (Thread.java748)
Inner exception java.util.zip.ZipException handled at org.apache.catalina.webresources.JarWarResourceSet.getArchiveEntries:
at java.util.zip.ZipFile.access$1400 (ZipFile.java60)
at java.util.zip.ZipFile$ZipFileInputStream.read (ZipFile.java734)
at java.io.FilterInputStream.read (FilterInputStream.java133)
at java.io.PushbackInputStream.read (PushbackInputStream.java186)
at java.util.zip.ZipInputStream.readFully (ZipInputStream.java403)
at java.util.zip.ZipInputStream.readLOC (ZipInputStream.java278)
at java.util.zip.ZipInputStream.getNextEntry (ZipInputStream.java122)
at java.util.jar.JarInputStream.<init> (JarInputStream.java83)
at java.util.jar.JarInputStream.<init> (JarInputStream.java62)
at org.apache.catalina.webresources.TomcatJarInputStream.<init> (TomcatJarInputStream.java37)
at org.apache.catalina.webresources.JarWarResourceSet.getArchiveEntries (JarWarResourceSet.java108)
at org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource (AbstractArchiveResourceSet.java256)
at org.apache.catalina.webresources.StandardRoot.getResourceInternal (StandardRoot.java281)
at org.apache.catalina.webresources.CachedResource.validateResource (CachedResource.java97)
at org.apache.catalina.webresources.Cache.getResource (Cache.java69)
at org.apache.catalina.webresources.StandardRoot.getResource (StandardRoot.java216)
at org.apache.catalina.webresources.StandardRoot.getResource (StandardRoot.java206)
at org.apache.catalina.mapper.Mapper.internalMapWrapper (Mapper.java1027)
at org.apache.catalina.mapper.Mapper.internalMap (Mapper.java842)
at org.apache.catalina.mapper.Mapper.map (Mapper.java698)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest (CoyoteAdapter.java679)
at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java336)
at org.apache.coyote.http11.Http11Processor.service (Http11Processor.java803)
at org.apache.coyote.AbstractProcessorLight.process (AbstractProcessorLight.java66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process (AbstractProtocol.java868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun (NioEndpoint.java1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run (SocketProcessorBase.java49)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run (TaskThread.java61)
at java.lang.Thread.run (Thread.java748)
As soon as this occurs, all calls to the rest service returns a 500 and the log gets another entry like above. This continues until I manually reboot the app service.
I'm struggling to figure out what is the issue. Googling the exception only returns results for issues with opening zip files. The app does not do any zipping/unzipping in itself and the call stack seems to indicate that it's tomcat things(that could be caused by something I've done on Azure, in SpringBoot, the JVM or something else entirely).
CPU or memory usage appear to be fine preceding the outages so that doesn't seem to be a factor.
This issue is not preceded by any deployments or platform changes.
I'm stumped regarding what to do next, if anyone can point me in the right direction to investigate, it'll be much appreciated.
I sporadically encounter the following exception when loading a specific page:
java.lang.NoClassDefFoundError: Could not initialize class com.app.item.search.SearchResultPanel
at com.app.item.search.SearchResultPage.initialize(SearchResultPage.java:86)
at com.app.core.layout.BasePage.onInitialize(BasePage.java:147)
at org.apache.wicket.Component.fireInitialize(Component.java:864)
at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:955)
at org.apache.wicket.Page.isPageStateless(Page.java:464)
at org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getPageInfo(AbstractBookmarkableMapper.java:447 )
at org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:391)
at org.apache.wicket.request.mapper.mount.UnmountedMapperAdapter.mapHandler(UnmountedMapperAdapter.java:61)
at org.apache.wicket.request.mapper.mount.MountMapper.mapHandler(MountMapper.java:145)
at org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:215)
at org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:429)
at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:271)
at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
--- CUT ---
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
The problem solves itself by restarting tomcat (maybe 2, 3,4 or 5 times) and it only happens when I deploy to the development/integration environment. On my development VM it never happened. And it affects only a couple of pages/panel (always them).
The SearchResultPanel is a simple class which extends the wicket Panel class.
On the catalina.out I see that the search results are loaded from Lucene but when it came to display the page I receive the above exception and a 404 page from wicket/tomcat.
The constructor of SearchResultPanel:
public SearchResultPanel(String id, final SearchResult resultList)
The line generating the exception (SearchResultPage:86):
SearchResultPanel resultPanel = new SearchResultPanel("searchResults",
results);
The SearchResultPanel is found in the WEB-INF folder of the app:
# locate SearchResultPanel
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$1.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$2.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$3.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$4.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$5.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$6.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$7.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$8.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$ItemFragment$1.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$ItemFragment$2.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$ItemFragment$3.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$ItemFragment.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel$SortImageModel.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel.class
/var/lib/tomcat7/webapps/app/WEB-INF/classes/com/app/item/search/SearchResultPanel.html
Using:
Wicket: 6.14.0
Apache Tomcat/7.0.26
Can you please advise me further how to debug this class-loading problem?
Thank you very much!
I am using jep for evaluating expressions but getting following exception
15:01:00,819 ERROR [stderr] (http--0.0.0.0-8443-3) com.singularsys.jep.ParseException: Trial version limitation: Number of parse calls exceeded
15:01:00,819 ERROR [stderr] (http--0.0.0.0-8443-3) at com.singularsys.jep.Jep.parse(Unknown Source)
15:01:00,819 ERROR [stderr] (http--0.0.0.0-8443-3) at com.singularsys.jep.Jep.parse(Unknown Source)
from above it is clear that the number of parse calls are exceeding than the allowed limit.
For now i have 28 expressions.
Does any one have idea of what is the maximum number of parse calls does jep allows in trial version.
Any help or pointers would be much appreciated.
From the Homepage of Jep:
The trial releases parse up to 50 expressions, after which an exception is thrown.
If my code throws an exception, sometimes - not everytime - the jsf presents a blank page. I´m using facelets for layout.
A similar error were reported at this Sun forumn´s post, but without answers.
Anyone else with the same problem, or have a solution?
;)
Due to some requests. Here follow more datails:
web.xml
<error-page>
<exception-type>com.company.ApplicationResourceException</exception-type>
<location>/error.faces</location>
</error-page>
And the stack related to jsf is printed after the real exception:
####<Sep 23, 2008 5:42:55 PM GMT-03:00> <Error> <HTTP> <comp141> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1222202575662> <BEA-101107> <[weblogic.servlet.internal.WebAppServletContext#6d46b9 - appName: 'ControlPanelEAR', name: 'ControlPanelWeb', context-path: '/Web'] Problem occurred while serving the error page.
javax.servlet.ServletException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:525)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:261)
at weblogic.servlet.internal.ForwardAction.run(ForwardAction.java:22)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.ErrorManager.handleException(ErrorManager.java:144)
at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:2201)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2053)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
javax.faces.application.ViewExpiredException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
I´m using the jsf version Mojarra 1.2_09, richfaces 3.2.1.GA and facelets 1.1.13.
Hope some help :(
I think this largely depends on your JSF implementation. I've heard that some will render blank screens.
The one we were using would throw error 500's with a stack trace. Other times out buttons wouldn't work without any error for the user. This was all during our development phase.
But the best advice I can give you is to catch the exceptions and log them in an error log so you have the stack trace for debugging later. For messages that we couldn't do anything about like a backend failing we would just add a fatal message to the FacesContext that gets displayed on the screen and log the stack trace.
I fixed a similar problem in my error.jsp page today. This won't be exactly the same as yours, but it might point someone in the right direction if they're having a similar problem. My problem seemed to be coming from two different sources.
First, the message exception property wasn't being set in some of the servlets that were throwing exceptions caught by the error page. The servlets were catching and rethrowing exceptions using the ServletException(Throwable rootCause) constructor.
Second, in the error page itself, the original author had used scriptlet code to parse the message using String.split(message, ";"); Since the message was null this failed. I was getting a NullPointerException in my error log, along with the message "Problem occurred while serving the error page."
These two things combined to give me a blank page at the URL of the servlet that was throwing the original exception. I fixed my problem by providing my own error message when I rethrow exceptions in my servlets using the ServletException(String message, Throwable rootCause) constructor, so the error message will no longer be null. I also rewrote the error.jsp page using EL instead of scriptlet code, but that wasn't strictly necessary.
For a blank page on JSF 2, place a breakpoint in ExceptionHandlerWrapper.handle or a class overriding this method. In my case it was due to custom code which was a too restrictive and the error was not logged.