Blocage applicatif inexpliqué

[dufond]

Bonjour,

Nous avons un souci récurrent sur notre plateforme IceScrum V7.6 (installé avec l’image Docker).

Nous nous retrouvons bloqués en production une fois par jour sans raison apparente.

Sur le navigateur, s’affichent de drôles de chaines de caractères : «91|X1|X1|X» ou «31|X».
Dans le fichier icescrum.log, nous avons le message suivant à chaque fois que nous essayons de rafraichir la page:

[http-nio-8080-exec-10] ERROR org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[gsp] – Servlet.service() for servlet [gsp] in context with path [] threw exception
java.lang.IllegalStateException: Cannot forward after response has been committed
at grails.plugin.springsecurity.web.filter.GrailsAnonymousAuthenticationFilter.doFilter(GrailsAnonymousAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter.doFilter(MutableLogoutFilter.java:62)
at grails.plugin.springsecurity.web.SecurityRequestHolderFilter.doFilter(SecurityRequestHolderFilter.java:59)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

En relançant le container, le blocage disparaît.

Indépendamment du blocage, nous avons eu également le message suivant dans les logs:

[http-nio-8080-exec-7] ERROR StackTrace – Full Stack Trace:
java.lang.IllegalArgumentException: Secure object invocation FilterInvocation: URL: /p/ui/window/backlog/settings was denied as public invocations are not allowed via this interceptor. This indicates a configuration error because the rejectPublicInvocations property is set to ‘true’
at grails.plugin.springsecurity.web.filter.GrailsAnonymousAuthenticationFilter.doFilter(GrailsAnonymousAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter.doFilter(MutableLogoutFilter.java:62)
at grails.plugin.springsecurity.web.SecurityRequestHolderFilter.doFilter(SecurityRequestHolderFilter.java:59)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

Merci d’avance pour votre aide.

Jean-Christophe

[Nicolas Noullet]

Bonjour Jean Christophe,

Est ce qu’il y a un un front / proxy devant iceScrum ? Ce type de configuration extérieure à iceScrum pourrait être la cause du problème.

Il me semble que vous ne possédez pas de licence professionnelle. Dans le cadre du support inclus dans les license, nous pourrions être à même de prendre le temps nécessaire pour vous aider et corriger le problème.

Concernant la seconde erreur :

[http-nio-8080-exec-7] ERROR StackTrace – Full Stack Trace:
java.lang.IllegalArgumentException: Secure object invocation FilterInvocation: URL: /p/ui/window/backlog/settings

Il est normalement corrigé dans les version supérieurs à la 7.6.

[dufond]

Bonjour Nicolas,

Il y a effectivement un front apache devant IceScrum mais je ne vois pas où est le problème.

Voici la configuration de notre virtual host:
<virtualhost *:80>
ServerAdmin adminXXX@YYY.fr
ServerName icescrum.YYY.fr
ErrorLog logs/icescrum.YYY.fr_error_log
CustomLog logs/icescrum.YYY.fr_access_log common
ProxyPass / http://<notre_serveur_icescrum&gt;:8082/
ProxyPassReverse / http://<notre_serveur_icescrum&gt;:8082/
Header unset X-Frame-Options
<Location />
Order Allow,Deny
Allow from All
</Location>
</virtualhost>

Pour l’instant, je n’arrive pas à provoquer le blocage et je n’ai pas eu de souci ni hier, ni aujourd’hui.
Toute idée serait bien sûr bienvenue.

Depuis près d’un an, nous sommes en attente d’une commande de licence professionnelle qui ne se concrétise pas, ceci indépendamment de notre volonté.

Bonnes fêtes de fin d’année.

Jean-Christophe

[Nicolas Noullet]

Bonjour,

Merci pour vos retours.

A première vue il manque un point essentiel à votre configuration. En effet notre système de push de données utilise les Web Sockets or ici ils ne sont apparemment pas gérés. Je vous invite à consulter la documentation correspondante pour plus d’informations : https://www.icescrum.com/documentation/application-server/#proxy-ssl.

Si vous regardez la console javascript de votre navigateur en naviguant sur iceScrum, vous devriez voir des erreurs indiquant un échec de connexion du système de push.

Le problème des «1|X» est lié au système de push mais je ne peux pas garantir que corriger le problème que j’ai identifié suffira…

Je comprends votre problématique concernant une commande éventuelle, si nous pouvons faire quoi que ce soit pour faciliter le processus, n’hésitez pas à nous en faire part.

Excellentes fêtes de fin d’année à vous aussi !

[dufond]

Bonjour et meilleurs voeux !

Merci pour ces informations.

Effectivement, notre configuration n’est pas correcte. Nous allons essayer de la mettre à jour dès que possible sachant que cela implique de monter en version notre serveur Apache pour implémenter mod_proxy_wstunnel …

Bonne fin de journée.

[Nicolas Noullet]

Bonjour,

Merci, meilleurs voeux à vous aussi !

Nous attendons donc de vos nouvelles quand la configuration aura été mise à jour,

Nicolas

[dufond]

Bonjour,

Nous sommes passés en version 2.4.6 d’Apache avec la bonne configuration.
Nous avons également fait évoluer IceScrum en 7.10.1.
Les problèmes n’apparaissent plus.

Merci encore pour votre aide.

Jean-Christophe

[Nicolas Noullet]

Content que ça fonctionne, merci à vous pour vos retours !

[Autor]

Entradas