As part of an application, we have a JSP page (parent page) in which we are calling another JSP page (child page), where all the parameters of the child page has been assigned to the form of the parent page and then trying to submit the page.
At the time of submission, we are getting the following error on the frontend...
(I) Front end error
=====================
Error 500--Internal Server Error
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
And on the backend we get the following error...
(II) Application server Error log
<Error> <HTTP> <BEA-101019> <[ServletContext(id=29607640,name=test,c
ontext-path=/Test)] Servlet failed with IOException
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at weblogic.servlet.internal.PostInputStream.read(PostInputStream.java:170)
at weblogic.servlet.internal.ServletInputStreamImpl$1.read(ServletInputStreamImpl.java:115)
at weblogic.servlet.internal.ServletInputStreamImpl.read(ServletInputStreamImpl.java:180)
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1339
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
**--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Cannot parse POST parameters of request: '/Test/test1.jsp
' - with nested exception:
[java.net.SocketTimeoutException: Read timed out]**
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1364
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
Could you please offer a suggestion as to the cause of the problem.
You are getting a SocketTimeoutException, so there is probably something wrong with your POST. For example, you might not be sending through enough bytes of data, or you might not be closing off the connection once you're finished with it - basically its sitting there waiting for more information until it eventually times out.
Could you please post some of your JSP code, especially where you're creating and running your POST, so that we can provide some better feedback.
Related
I recently tried to switch my subscriptions in GCP Pub/Sub to the "exactly-once" delivery strategy. However, I started seeing the following warnings ~10 times every 30 minutes in my application logs:
com.google.api.gax.rpc.InvalidArgumentException: io.grpc.StatusRuntimeException: INVALID_ARGUMENT: Some acknowledgement ids in the request were invalid. This could be because the acknowledgement ids have expired or the acknowledgement ids were malformed.
at com.google.api.gax.rpc.ApiExceptionFactory.createException(ApiExceptionFactory.java:92)
at com.google.api.gax.grpc.GrpcApiExceptionFactory.create(GrpcApiExceptionFactory.java:98)
at com.google.api.gax.grpc.GrpcApiExceptionFactory.create(GrpcApiExceptionFactory.java:66)
at com.google.api.gax.grpc.GrpcExceptionCallable$ExceptionTransformingFuture.onFailure(GrpcExceptionCallable.java:97)
at com.google.api.core.ApiFutures$1.onFailure(ApiFutures.java:67)
at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1041)
at com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1215)
at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:983)
at com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:771)
at io.grpc.stub.ClientCalls$GrpcFuture.setException(ClientCalls.java:574)
at io.grpc.stub.ClientCalls$UnaryStreamToFuture.onClose(ClientCalls.java:544)
at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
at com.google.api.gax.grpc.ChannelPool$ReleasingClientCall$1.onClose(ChannelPool.java:535)
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:563)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:70)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:744)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:723)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: io.grpc.StatusRuntimeException: INVALID_ARGUMENT: Some acknowledgement ids in the request were invalid. This could be because the acknowledgement ids have expired or the acknowledgement ids were malformed.
at io.grpc.Status.asRuntimeException(Status.java:535)
... 17 more
They're immediately followed by the following INFO log messages in the same thread:
Permanent error invalid ack id message, will not resend
I didn't see any problems caused by these warnings, but it's a bit hard to tell because my application is processing a decent number of messages (~1000/hour). I initially thought that these warnings were just short-term "aftershocks" from switching to the "exactly-once" strategy. However, I waited for about 2 hours and they kept occurring with the same frequency, showing no sign of disappearing. I then disabled the "exactly-once" strategy and they went away immediately after. Can anyone tell me whether these warnings are dangerous, what side effects I can expect, and most importantly how I can get rid of them?
I'm using version 3.4.0 of spring-cloud-gcp-dependencies and spring-cloud-gcp-starter-pubsub. I'm also using Spring Cloud Stream to process the incoming messages and I rely on it to automatically acknowledge the messages.
I have the following configuration set in my application.yaml file:
spring:
cloud:
gcp:
pubsub:
subscriber:
executor-threads: 15
max-ack-extension-period: 23400 # 6 hours and 30 minutes
acknowledgement-deadline: 600 # Maximum value
For context: The messages in my application represent jobs for execution, and they could take quite a while to finish - hence the 6h30m maximum acknowledgement extension period.
I also saw the following StackOverflow question:
How to handle errors during message acknowledgement using google pubsub java library?
From what I understand, the consequence of these warnings is that the messages will be redelivered to my application, but this is exactly what I want to avoid.
Thanks for the question, Alexander.
The errors you are seeing happen when the modifyAckDeadline or Acknowledgement request to the service fail because the acknowledgement id is already expired. In such cases, the service considers the expired acknowledgement id as invalid, since a newer delivery might already be in-flight. This is as-per the guarantees for exactly once delivery. There could be a few reasons for it:
The request was delayed due to network delays and by the time it arrived at the server, the acknowledgement id lease is already expired.
The tasks issuing the modifyAckDeadline or Acknowledgement request is overwhelmed (high CPU/memory/network usage), leading to delay in issuing those requests.
I suggest setting min-duration-per-ack-extension to a high number to reduce issues mentioned above. This will help mitigate the cases where the acknowledgement id lease expired. The highest value you can set for this field is 600 seconds.
Additionally, as mentioned in the other stack overflow question, you should consider checking the response of your acknowledgement operations. This can be used to guide your application if it can expect a redelivery. Sample.
I am getting java.io.IOException: Broken pipe issue in Higher environment where the code is deployed. But in local system it works fine.
The data is very huge, more than 1000 JSON objects and it takes about 40 seconds to get the response in Local system.
The error logs is as follows
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:341) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:766) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:671) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:376) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:354) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96) ~[tomcat-embed-core-9.0.16.jar!/:9.0.16]
at org.springframework.session.web.http.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:620) ~[spring-session-core-2.1.4.RELEASE.jar!/:2.1.4.RELEASE]
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:639) ~[spring-security-web-5.1.4.RELEASE.jar!/:5.1.4.RELEASE]
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:639) ~[spring-security-web-5.1.4.RELEASE.jar!/:5.1.4.RELEASE]
and so on... Please help. Not finding any solution to fix this.
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 use SpringBoot and Jersey into my project and I often tackle the following error :
[ERROR - ServerRuntime$Responder - 2018-02-13 13:16:45,983] An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92)
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711)
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444)
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
It results with a 503 status response to my client.
Could you explain me why this error occured ?
Thanks
This kind of error usually happens servlet is writing data back on the stream and connection closed from client side.
It is like server in sending some data may be file, string, bytes etc.. but on client side like a browser has closed the connection, like you close the browser tab.
It cased early End of file exception on the server.
I have had this exception when I accidentally passed a null Response at the end of a call. You can verify this in the'caused by' section following the first exception:
Caused by: org.eclipse.jetty.io.EofException: null
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.