1.9 Snapshot Threads blocked
Submitted by Ben_Charlton on Thu, 25/02/2016 - 14:13
I have installed 1.9 snapshot and I am seeing a few problems I cant determine if they are local or more code based
The first is we are getting a whole stack of Threads locked. by the ESCI dispatcher on check order - here is the current live stack and below in red is a stacktrace of thread 220.(edit clearly not 221)
org.openvpms.esci.adapter.dispatcher.DefaultESCIDispatcher.dispatch ( DefaultESCIDispatcher.java:157 )
org.openvpms.web.workspace.supplier.order.ESCISupplierCRUDWindow.checkInbox ( ESCISupplierCRUDWindow.java:102 )
org.openvpms.web.workspace.supplier.order.ESCISupplierCRUDWindow$1.onAction ( ESCISupplierCRUDWindow.java:91 )
org.openvpms.web.echo.event.ActionListener.actionPerformed ( ActionListener.java:40 )
nextapp.echo2.app.button.AbstractButton.fireActionPerformed ( AbstractButton.java:135 )
echopointng.ButtonEx$1.actionPerformed ( ButtonEx.java:120 )
nextapp.echo2.app.button.DefaultButtonModel.fireActionPerformed ( DefaultButtonModel.java:70 )
echopointng.model.DefaultButtonModelEx.doAction ( DefaultButtonModelEx.java:51 )
echopointng.ButtonEx.processInput ( ButtonEx.java:202 )
nextapp.echo2.app.update.ClientUpdateManager.process ( ClientUpdateManager.java:116 )
nextapp.echo2.app.update.UpdateManager.processClientUpdates ( UpdateManager.java:89 )
nextapp.echo2.webcontainer.ContainerSynchronizeService.renderUpdate ( ContainerSynchronizeService.java:471 )
nextapp.echo2.webrender.service.SynchronizeService.service ( SynchronizeService.java:279 )
nextapp.echo2.webrender.WebRenderServlet.process ( WebRenderServlet.java:273 )
org.openvpms.web.echo.servlet.SpringWebContainerServlet.process ( SpringWebContainerServlet.java:178 )
nextapp.echo2.webrender.WebRenderServlet.doPost ( WebRenderServlet.java:189 )
javax.servlet.http.HttpServlet.service ( HttpServlet.java:641 )
javax.servlet.http.HttpServlet.service ( HttpServlet.java:722 )
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter ( ApplicationFilterChain.java:305 )
org.apache.catalina.core.ApplicationFilterChain.doFilter ( ApplicationFilterChain.java:210 )
org.openvpms.web.echo.servlet.Log4JMDCUserFilter.doFilter ( Log4JMDCUserFilter.java:58 )
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter ( ApplicationFilterChain.java:243 )
org.apache.catalina.core.ApplicationFilterChain.doFilter ( ApplicationFilterChain.java:210 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:330 )
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke ( FilterSecurityInterceptor.java:118 )
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter ( FilterSecurityInterceptor.java:84 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter ( ExceptionTranslationFilter.java:113 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.session.SessionManagementFilter.doFilter ( SessionManagementFilter.java:103 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter ( AnonymousAuthenticationFilter.java:113 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter ( SecurityContextHolderAwareRequestFilter.java:154 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter ( RequestCacheAwareFilter.java:45 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter ( AbstractAuthenticationProcessingFilter.java:199 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal ( WebAsyncManagerIntegrationFilter.java:50 )
org.springframework.web.filter.OncePerRequestFilter.doFilter ( OncePerRequestFilter.java:106 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter ( SecurityContextPersistenceFilter.java:87 )
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter ( FilterChainProxy.java:342 )
org.springframework.security.web.FilterChainProxy.doFilterInternal ( FilterChainProxy.java:192 )
org.springframework.security.web.FilterChainProxy.doFilter ( FilterChainProxy.java:160 )
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate ( DelegatingFilterProxy.java:343 )
org.springframework.web.filter.DelegatingFilterProxy.doFilter ( DelegatingFilterProxy.java:260 )
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter ( ApplicationFilterChain.java:243 )
org.apache.catalina.core.ApplicationFilterChain.doFilter ( ApplicationFilterChain.java:210 )
org.apache.catalina.core.StandardWrapperValve.invoke ( StandardWrapperValve.java:224 )
org.apache.catalina.core.StandardContextValve.invoke ( StandardContextValve.java:169 )
org.apache.catalina.authenticator.AuthenticatorBase.invoke ( AuthenticatorBase.java:472 )
org.apache.catalina.core.StandardHostValve.invoke ( StandardHostValve.java:168 )
com.googlecode.psiprobe.Tomcat70AgentValve.invoke ( Tomcat70AgentValve.java:38 )
org.apache.catalina.valves.ErrorReportValve.invoke ( ErrorReportValve.java:98 )
org.apache.catalina.valves.AccessLogValve.invoke ( AccessLogValve.java:927 )
org.apache.catalina.core.StandardEngineValve.invoke ( StandardEngineValve.java:118 )
org.apache.catalina.connector.CoyoteAdapter.service ( CoyoteAdapter.java:407 )
org.apache.coyote.http11.AbstractHttp11Processor.process ( AbstractHttp11Processor.java:987 )
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process ( AbstractProtocol.java:579 )
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run ( AprEndpoint.java:1805 )
java.util.concurrent.ThreadPoolExecutor.runWorker ( unknown source )
java.util.concurrent.ThreadPoolExecutor$Worker.run ( unknown source )
java.lang.Thread.run ( unknown source )
You can see that it dispatches to check the inbox and then it blocks ...
The second issue is that the Appointment reminders while being scheduled and marked are not being sent...its like the job never runs? I was wondering if they might be related - I am now going to restart the app and see what comes of it
Re: 1.9 Snapshot Threads blocked
Okay so update completely restarted Tomcat to clear the blockage ...interesting the docloader was also not running. ie it was blocked and as soon as the app finished loading I started seeing the following...
I suspect the time out may be because of gmails rapid smtp supression it can enact on this sort of stuff as a result of spam - I am in the process of moving to sendgrid
BUT the important thing to note that a blockage in the jobscheduler threads blocked all jobs from running - probably expected but it makes it important we can clear blocked threads
Re: 1.9 Snapshot Threads blocked
You can only have one ESCI dispatch running at a time. It won't prevent other non-ESCI jobs running.
I expect you are seeing your supplier not responding. Try and access their WSDL, and see if it responds.
Re: 1.9 Snapshot Threads blocked
But thats the issue Tim - staff can hit check inbox ...it locks up because the supplier doesnt respond and then they close the session (open a new one) the thread blocks and eventually enough accumulate over a few days and we block the entire job scheduler
Re: 1.9 Snapshot Threads blocked
And no offence but it categorically was preventing the other jobs from running...they simply were not running...I watched and rescheduled them over a 1hr period with those thread blocks in place ...as soon as I cleared it with a reboot they all went back to work.
Re: 1.9 Snapshot Threads blocked
OK - its because the supplier isn't responding and all job threads (10) are busy trying to contact the supplier. They should time out.
We will need to force timeouts in the ESCI client e.g. as per: http://stackoverflow.com/a/3851784
In the meantime, contact your supplier.
Re: 1.9 Snapshot Threads blocked
I actually think this could be cause by internet dropout at the location - you would get the same response if the server lost internet - if the ESCI inbox reader job locks and is set to run every 2hrs does it run again if it locks ? or are the subsequent blocks the staff manually checking.
Re: 1.9 Snapshot Threads blocked
Due to OBF-240 Quartz will re-schedule the inbox reader while a prior instance is blocked. In your case you have 10 scheduler_Worker-* threads blocked due to scheduling.
The other http-apr-8080-exec-* threads blocked in DefaultESCIDispatcher have been initiated by Check Inbox or by submitting an order.
When OBF-240 is fixed, it will block one thread, allowing document loads etc to continue to run. When a user does a Check Inbox however, one of the http-apr threads will be consumed.
Re: 1.9 Snapshot Threads blocked
Also see https://openvpms.atlassian.net/browse/OVPMS-1724