2020-05-13 15:22:33,833 ERROR [com.simplicite.webapp.servlets.ui.ResourceServlet] SIMPLICITE|https://dev-sim:10513/karta|/karta|ERROR|p0350024l|com.simplicite.webapp.servlets.ui.ResourceServlet|doGet||Evénement: Resource not found: java.io.IOException: Relais brisé (pipe)
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Relais brisé (pipe)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:351)
at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:776)
at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:681)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:386)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:364)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
at com.simplicite.webapp.tools.ServletTool.writeStream(ServletTool.java:2796)
at com.simplicite.webapp.WebServicesFactory.streamResource(WebServicesFactory.java:2575)
at com.simplicite.webapp.servlets.ui.ResourceServlet.doGet(ResourceServlet.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:187)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.io.IOException: Relais brisé (pipe)
at java.base/sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at java.base/sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:113)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:79)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
at java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:138)
at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101)
at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:152)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioEndpoint.java:1253)
at org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:740)
at org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWrapperBase.java:560)
at org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:504)
at org.apache.coyote.http11.Http11OutputBuffer$SocketOutputBuffer.doWrite(Http11OutputBuffer.java:538)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:112)
at org.apache.coyote.http11.Http11OutputBuffer.doWrite(Http11OutputBuffer.java:190)
at org.apache.coyote.Response.doWrite(Response.java:601)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:339)
Ok dans ce cas j’ai besoin de la définition de vos 4 PT pour essayer de comprendre, et être sur qu’il n’y a pas de pb à ce niveau.
Sinon si je comprends bien : les PT sont bien chargés dans l’objet au début (vous pouvez imprimer en PDF…), puis disparaissent en mémoire après quelques actions à identifier (puisque NPE) et l’objet ne s’affiche plus (s’il est cassé = plus de metadata = logout pour recharger sa session).
Il faut voir si vous accédez aux PrintTemplates en mémoire via getPrintTemplates()
Ou suite à quelles actions UI on perd les pointeurs… ça orientera vers les hooks à vérifier
2020-05-13 15:40:12,051 ERROR [com.simplicite.util.tools.JSONTool] SIMPLICITE|https://dev-sim:10513/karta|/karta|ERROR|p0350024L|com.simplicite.util.tools.JSONTool|actionToJson||Evénement: Unable to generate action definition [print_CrbKartaProjet-PT-XLS-instruction]
java.lang.NullPointerException
at com.simplicite.util.tools.JSONTool.actionToJson(JSONTool.java:1924)
at com.simplicite.util.tools.JSONTool.rowMetaDataToJson(JSONTool.java:1703)
at com.simplicite.util.tools.JSONTool.listToJson(JSONTool.java:2241)
at com.simplicite.util.tools.JSONTool.list(JSONTool.java:2599)
at com.simplicite.webapp.tools.JSONServletTool.search(JSONServletTool.java:710)
at com.simplicite.webapp.ObjectJson.search(ObjectJson.java:219)
at com.simplicite.webapp.ObjectJson.search(ObjectJson.java:195)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:540)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:136)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:187)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
J’ai testé des PT “xlsx en liste+form” sans aucun pb.
Vos PT sont configurés en “List + Form” donc les meta sont appelées pour chaque ligne de la liste, ça explique pourquoi c’est verbeux, mais c’est passant (l’action sera ignorée en back, donc pas affichée en front).
Je n’ai toujours pas compris quand ou après quelle(s) action(s) utilisateur cela se produit, dès le premier affichage de la liste ou après quelles manipulations ?
au 1er affichage ça passe, mais après, dès qu’une action est faite, la liste ne s’affiche plus.
enfin, maintenant, elle s’affiche mais j’ai des erreurs à la pelle …
On peut retirer les erreurs en back, mais cela ne résoudra pas le pb si l’action est sensé s’afficher, il faut savoir :
si l’utilisateur doit avoir accès à ces actions dans votre cas (habilité instructeur) ou non via surcharge du isActionEnable pour masquer l’action dans certains cas. S’il n’a pas accès ça ne serait alors qu’un bug en back pour ne pas tracer cette erreur (null = pas habilité à gérer)
Si elle doit bien être accessible, quelle action explicitement (open form/close, save, edit liste, filtre…), car elle modifie l’objet en mémoire en lui retirant les PT XLS
Je n’explique pas pourquoi cela se produit que pour les XLS car Simplicité ne change pas de comportement à ce niveau en fonction du type.
les publications qui posent pb sont celles qui sont Habilitables.
les messages d’erreur ne s’affichent dès que je me connecte avec un profile qui n’a pas l’habilitation.
L’application est plus performante (l’indicateur tombe à 25 %), mais une montée en charge semple toujours intervenir. cf. les logs tomcat :
14-May-2020 08:47:33.873 GRAVE [http-nio-10518-exec-4] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Echec de la fin de traitement d'une requête
java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:172)
at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538)
at java.base/java.lang.StringBuilder.append(StringBuilder.java:174)
at com.simplicite.util.tools.JSONTool.jsonResponse(JSONTool.java:366)
at com.simplicite.util.tools.JSONTool.jsonResponse(JSONTool.java:359)
at com.simplicite.webapp.tools.JSONServletTool.search(JSONServletTool.java:713)
at com.simplicite.webapp.ObjectJson.search(ObjectJson.java:219)
at com.simplicite.webapp.ObjectJson.search(ObjectJson.java:195)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:540)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:77)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:136)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:187)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
Plus généralement, est-ce que SERVICE_TOMCATMINMEM et SERVICE_TOMCATMAXMEM correspondent au heapspace Java ? Auriez-vous une doc qui explique le fonctionnement de la mémoire Simplicité ? Y a-t-il des bonnes pratiques dans l’augmentation de la “heap” ?
Simplicité stocke en mémoire les resources qu’on lui demande d’utiliser = pour chaque session on a en mémoire N copies des définitions d’objets (les “instances d’objet”) et chaque instance contient les dernières données consultées (dernière liste - en général paginée - et dernier item), etc.
Tant qu’une session UI ou API n’est pas expirée (au sens Tomcat) tout ce qui y est associé reste alloué et n’est donc pas éligible à être traité par le GC de la JVM.
D’expérience le GC de la JVM travaille selon un profil de ce genre:
Le GC fait de “petits” flush reguliers partiels et quand ça approche de la limite il fait un “gros” flush, cela donne typiquement une courbe à 2 niveaux de “dents de scie”, ce n’est donc pas inquiétant de voir monter la mémoire au fil des “petits” flushs du moment qu’il finit par y avoir un “gros” flush à l’approche de la limite.
Par contre quand on atteint un out of memory c’est que le volume de données non éligible au GC (donc associé à des sessions Tomcat non expirées) est trop important vs la limite de mémoire allouée.
Donc, si vous êtes dans ce cas là, les premières choses à regarder dans vos paramétrages/code sont:
les timeouts de session UI/API trop longs
les recherches non paginées qui ramènent de grosses quantités de données et qui ne sont pas explicitement vidées
la multiplication des instances d’objets
Souvent les “dérives mémoire” sont dues à des appels externes (genre des “pings” de supervision) qui créent à intervalles réguliers des sessions publiques qui n’expirent pas, ou pas rapidement. Pour ce genre de supervision externe il est impératif d’utiliser le /health et rien d’autre, en effet celui-ci est prévu pour tuer sa session immédiatement s’il n’est pas appelé dans une session déjà établie.
Cela peut aussi être lié à des tâches cron specifiques très “gourmandes” en resources et/ou lancées très fréquemment.
Il faut activer le monitoring de Simplicité (Menu operation / Monitoring / Start), il donnera des indications sur le heap au fil du temps.
Et aussi au niveau du debugger du navigateur, vous pouvez dans l’onglet Network voir les flux et leurs tailles en fonction du nombre de champs (surtout l’appel xhr obj/search qui est verbeux et proportionnel au nombre de champs ramenées).
Des optimisations du flux JSON sont en cours en V5 sur ce point car vous n’êtes pas les seuls à utiliser de “gros objets”, mais difficilement back-portable pour le moment car très sensible.
Sur Karta, je me rappelle que qu’il y avait beaucoup d’attributs sur l’objet central, il faut s’assurer que peu sont visibles ou recherchable en liste, sinon les metadata seront énormes suivant le nombre de lignes ramenées. Il faut interdire la mise à jour en liste, etc.
En V3, on avait opté pour un design à 2 objets : un simple avec peu d’attributs pour la liste + 1 complet pour le formulaire (via getTargetObject pour rediriger)
