Upgrade 5.1.31 sur debian Resource not found code=MAIN

Thierry1 · March 3, 2022, 5:08pm

Bonjour,

suite à un problème annexe nous sommes repartis from scratch mais l’UI n’est plus accessible et nous avons une erreur Ressource not found.

Sur nos PC la mise à jour de la version 5.1.31 c’est correctement passé docker desktop et Simplicité ainsi que notre application est déployé.
Nous avons voulu déployé sur un environnement de recette
Linux dn1160 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64
Il n’y a aucune trace d’erreur sauf au moment on l’on accède à la page http://hostname:8080/ui

Technical information

Instance /health

[Platform]
Status=OK
Version=5.1.31
BuiltOn=2022-02-27 16:25
Git=release/8a0f5eefbf9cdfa38659c61d6f565c6883887cee
Encoding=UTF-8
EndpointIP=192.168.96.3
EndpointURL=http://aa03b3e56d26:8080
TimeZone=UTC
SystemDate=2022-03-03 16:58:29

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=http://dev-portail.ladom.fr:8080
ActiveSessions=2
TotalUsers=11
EnabledUsers=9
LastLoginDate=2022-03-03 16:48:40

[Server]
ServerInfo=Apache Tomcat/9.0.58
ServerType=WEB
ServerActiveSessions=2

[OS]
Name=Linux
Architecture=amd64
Version=4.19.0-13-cloud-amd64
DockerImageName=centos7
SystemEncoding=UTF-8

[Disk]
DiskFree=88378
DiskUsable=84245
DiskTotal=100759

[JavaVM]
Version=17.0.2
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.2+8
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=91955
HeapSize=321536
HeapMaxSize=3760128
TotalFreeSize=3530547

[Cache]
GrantCache=0
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=35
ObjectCacheMax=10000
ObjectCacheRatio=0
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=2
ProductName=MySQL
ProductVersion=5.5.5-10.7.3-MariaDB-1:10.7.3+maria~focal
DriverName=MySQL Connector/J
DriverVersion=mysql-connector-java-8.0.28 (Revision: 7ff2161da3899f379fb3171b6538b191b1c5c7e2)
DBDate=2022-03-03 16:58:29
DBDateOffset=0
DBPatchLevel=5;P01;3912ca6c44bd2eba0e0b0ca850d8e290
UsingBLOBs=true

[Healthcheck]
Date=2022-03-03 16:58:30
ElapsedTime=11

Browser logs

2022-03-03 17:00:00,223|SIMPLICITE|INFO||http://aa03b3e56d26:8080||ICORECM005|system|com.simplicite.util.CronJob|run||Result of job ImportXML : No XML file to import.
2022-03-03 17:00:00,223|SIMPLICITE|INFO||http://aa03b3e56d26:8080||INFO|system|com.simplicite.util.engine.JobQueue$PoolWorker|run||Event: Worker SimplicitePoolWorker-1 has been started.
2022-03-03 17:00:00,220|SIMPLICITE|INFO||http://aa03b3e56d26:8080||ICORECM004|system|com.simplicite.util.CronJob|run||Execute job ImportXML at 2022-03-03 17:00:00
2022-03-03 17:00:00,190|SIMPLICITE|INFO||http://aa03b3e56d26:8080||ICORECM005|system|com.simplicite.util.CronJob|run||Result of job HealthCheck : Application version : 1.0.0, platform version : 5 patchlevel P01
2022-03-03 17:00:00,176|SIMPLICITE|INFO||http://aa03b3e56d26:8080||ICORECM004|system|com.simplicite.util.CronJob|run||Execute job HealthCheck at 2022-03-03 17:00:00
2022-03-03 16:59:48,619|SIMPLICITE|INFO||http://aa03b3e56d26:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected, session ID: F185A2F418E42005F99240823C54DED1, timeout: 5 min , user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
2022-03-03 16:58:23,512|SIMPLICITE|ERROR||http://aa03b3e56d26:8080||ERROR|designer|com.simplicite.webapp.servlets.ui.ResourceServlet|doGet||Evénement: Resource not found: Resource not found code=MAIN
    com.simplicite.util.exceptions.NotFoundException: Resource not found code=MAIN
     at com.simplicite.webapp.WebServicesFactory.streamResource(WebServicesFactory.java:2893)
     at com.simplicite.webapp.servlets.ui.ResourceServlet.doGet(ResourceServlet.java:57)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:86)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at com.simplicite.webapp.filters.HTTPHeadersFilter.doFilter(HTTPHeadersFilter.java:39)
     at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:183)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540)
     at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:231)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
     at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:359)
     at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
     at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
     at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
     at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
     at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
     at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
     at java.base/java.lang.Thread.run(Thread.java:833)

david · March 3, 2022, 5:12pm

Qu’est ce que vous voulez dire exactement ?

Thierry1 · March 3, 2022, 5:37pm

Nous avons vidé les images et contenaires dockers de Simplicité et de la base de donnée mariadb.

david · March 3, 2022, 5:59pm

Désolé mais je ne comprends toujours pas ce que vous avez fait exactement, notamment au niveau du contenu la base.

Quoiqu’il en soit, un upgrade Simplicité doit toujours être fait en suivant la procédure suivante:

1.1) faire un dump de la base
1.2) arrêter le container Simplicité en révision x.y.N
1.3) puller l’image en révision x.y.N+k
1.4) démarrer un container Simplicité en révision x.y.N+k

Lors du 1.4 vérifier dans les logs que tout se passe bien lors de ce 1er démarrage, surtout si k est > 1. En effet, c’est lors de ce 1er démarrage que sont appliqués les patches système qui potentiellement peuvent modifier la structure de la base de données.

En cas de pb (par exemple s’il y a eu des erreurs bizarres au 1.4 - à conserver pour investigation) ou simplement pour revenir à l’état précédent la procédure est la suivante:

2.1) arrêter le container Simplicité x.y.N+k
2.2) restaurer la base
2.3) démarrer le container Simplicité x.y.N

L’étape 2.2, et donc la 1.1, sont absolument obligatoires sinon on est dans un état indéterminé qui peut induire des comportements totalement imprévisibles.

PS: je ne traite pas ici d’un éventuel upgrade de la base qui peut potentiellement aussi générer des pbs spécifiques, personnellement si je dois faire ce type d’upgrade de la base je le fais toujours indépendamment d’un upgrade Simplicité afin de bien isoler les pbs le cas échéant.

Thierry1 · March 4, 2022, 7:47am

Bonjour David,
C’est un environnement de tests donc nous ne gardons pas les données. Nous n’avons pas besoin de sauvegarde des données.
La base mariadb est dans un contenaire docker ainsi que que Simplicité.
Nous faisons des docker compose up pour mettre à jour les images et parfois nous supprimer docker rm les contenaires dockers pour repartir de zéro.
Ce qui est étrange cette fois c’est que nous avons systématiquement cette erreur de main not found. Je ne vois pas d’où cela peut venir car il n’y a plus de base.
Thierry

david · March 4, 2022, 8:14am

OK si, je comprends bien ce que vous dites, on parle d’un déploiement initial, pas d’un upgrade comme le titre le votre post semblait l’indiquer.

J’ai fait, un tests docker-compose de déploiement initial 5.1 (avec la révision à jour = 5.1.33) sur une MySQL à jour (8.0) et je n’ai pas constaté de pb.

Mon docker-compose.yml:

version: "3"
services:
  db:
    image: mysql:latest
    restart: always
    container_name: db
    command: --default-authentication-plugin=mysql_native_password
    environment:
      MYSQL_ROOT_PASSWORD: "simplicite"
      MYSQL_DATABASE: "simplicite"
      MYSQL_USER: "simplicite"
      MYSQL_PASSWORD: "simplicite"
    volumes:
      - db:/var/lib/mysql
  simplicite:
    image: simplicite/platform:5-latest
    restart: always
    container_name: simplicite
    environment:
      DB_SETUP: "true"
      DB_VENDOR: "mysql"
      DB_HOST: db
      DB_USER: "simplicite"
      DB_PASSWORD: "simplicite"
      DB_NAME: "simplicite"
      DB_WAIT: 100
      DB_WAIT_INTERVAL: 10
    ports:
      - 127.0.0.1:8443:8443
    volumes:
      - git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git
    depends_on:
      - db
volumes:
  db:
  git:

Avez vous bien supprimé vos volumes, notamment celui qui contient les données de la base, avant de déployer ?
Avez vous bien mis DB_SETUP: "true" (pour rappel cette variable d’environnement signifie “charger la base si elle est vide”, il ne sert donc que lors d’un déploiement initial) ?
Etc.

NB: Par acquis de conscience je vais essayer de faire un test docker-compose avec MariaDB 5.5 si c’est possible mais je ne vois pas de raison que ça ne marche pas car c’est ce qu’on utilise sur nos serveurs d’instances (SIM) et j’y ai déployé une 5.1 à jour qui marche elle aussi très bien:

PS: pour mémoire les révisions 5.1.32 et 5.1.33 embarquent la dernière version des libs Log4J et des correctifs au niveau de l’authent sur le endpoint API. Cf. la release note, bref utilisez cette révision la plus à jour

david · March 4, 2022, 8:51am

Pas de pb non plus sur un déploiement initial docker compose sur MariaDB 5.5:

Mon docker-compose.yml:

version: "3"
services:
  db:
    image: mariadb:5.5
    restart: always
    container_name: db
    environment:
      MYSQL_ROOT_PASSWORD: "simplicite"
      MYSQL_DATABASE: "simplicite"
      MYSQL_USER: "simplicite"
      MYSQL_PASSWORD: "simplicite"
    volumes:
      - db:/var/lib/mysql
  simplicite:
    image: simplicite/platform:5-latest
    restart: always
    container_name: simplicite
    environment:
      DB_SETUP: "true"
      DB_VENDOR: "mysql"
      DB_HOST: db
      DB_USER: "simplicite"
      DB_PASSWORD: "simplicite"
      DB_NAME: "simplicite"
      DB_WAIT: 100
      DB_WAIT_INTERVAL: 10
    ports:
      - 127.0.0.1:8443:8443
    volumes:
      - git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git
    depends_on:
      - db
volumes:
  db:
  git:

Thierry1 · March 4, 2022, 5:15pm

Bonjour David,

effectivement le titre du ticket n’est pas le bon.
J’ai vidé les volumes mais cela ne change rien.
Je vais refaire un test la semaine prochaine.
Thierry

system · April 3, 2022, 5:15pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.