Sur ton instance:
Le code de ton objet correspond à un ID de document qui n’existe pas.
J’ai forcé à null la colonne obj_script_id de m_object pour ton objet puis j’ai récréé le code (Java)
Après un clear cache, il y a à nouveau le même pb : le document n’existe pas/plus:
Est-ce que votre base de données ne serait pas limitée en volume ou en nombre/volume de BLOBs ou va savoir quoi d’autre du même genre… ?
En tout cas sur une instance cloud chez nous, on ne reproduit pas ça.
Bonjour David, Gaylord,
je suis joueur et après avoir lancé un rebuild index m_document_pkey il semble que l’enregistrement du code fonctionne à nouveau…
SELECT conname FROM pg_constraint WHERE conname LIKE 'm_document%';
--> m_document_pkey
REINDEX INDEX m_document_pkey;
Pouvez-vous vérifier?
Non, suite au rebuild index, j’ai pu recréer le code de l’objet (l’init du code a bien été enregistré) mais lors de la première modification, l’erreur duplicate key value violates unique constraint “m_document_uk” est revenue…
Je continue à pencher plus vers un pb de volume limité dans votre service database/DBaaS ou dans le genre…
Sinon je vais monter un environnement de test cloud un peu plus iso au votre = image Docker :latest (P23) + PostgreSQL 10 pour voir si ce ne serait pas un pb lié à cette version 10 de PostgreSQL qu’on ne teste pas vraiment (mais de toute façon l’image Docker 10.x de PostgreSQL et actuellement une 10.9, pas une 10.6 comme chez vous)
SELECT current_database();
--> rdrfs_int1
SELECT pg_size_pretty( pg_database_size('rdrfs_int1') );
--> 610 MB
mais ça ne nous dit pas combien il reste de place sur le FS concerné…
Ca me semble énorme. Sur ma base de test:
SELECT pg_size_pretty(pg_database_size('sitesdaz'));
pg_size_pretty
----------------
48 MB
(1 row)
N’auriez vous pas activé la supervision ou lancé des jobs fréquents qui crachent beacoup de logs en base ?
Quelle taille après avoir purgé les supervisons et les logs en base ?
Comment est-ce que je peux purger tout ça ?
Supervisons:
Jobs:
Logs:
NB: Ca peut aussi se faire via un curl sur I/O: /io?service=<PURGESUPERVISIONS|PURGEJOBS|PURGELOGS>
Mais bon, si vous avez des cron ou de la supervision trop fréquentes ça va se reremplir très vite.
Et faire de la place ne résoudra pas le fond du pb. Si c’est un pb de volume de stockage dans la base, ça finira par réapparaître.
Bonjour,
J’ai testé de purger les trois, le problème apparaît toujours. Par ailleurs j’ai testé d’uploader une grosse image (3.64 Mo) en MD IMAGE et ça a bien marché donc il semblerait que ça ne vient pas d’un problème d’espace de stockage en base.
Deuxième test :
Créer un nouvel objet vide et lui créer du code (j’ai simplement ajouté “test” en commentaire). A la sauvegarde du code de cette objet, c’est la stack Error DocumentSystem :
2019-07-02 16:29:16,151 ERROR [com.simplicite.util.ObjectDirect] SIMPLICITE|http://71e4dd1fef56:8080||ECORED0001|system|com.simplicite.util.ObjectDirect|save||Error DocumentSystem
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "m_document_uk"
Detail: Key (dbd_path)=(ObjectInternal/obo_script_id/0/2123/SitesTestDBVolume.java) already exists.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2440)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2183)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:308)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:143)
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:120)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1528)
at com.simplicite.util.engine.ObjectManager.create(ObjectManager.java:1675)
at com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:2706)
at com.simplicite.util.ObjectDirect.save(ObjectDirect.java:442)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:946)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:933)
at com.simplicite.util.tools.DocTool.upload(DocTool.java:526)
at com.simplicite.util.engine.ObjectManager.upload(ObjectManager.java:1772)
at com.simplicite.util.engine.ObjectManager.update(ObjectManager.java:2301)
at com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:2727)
at com.simplicite.util.ObjectDirect.save(ObjectDirect.java:442)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:946)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:933)
at com.simplicite.util.tools.EditorTool.save(EditorTool.java:253)
at com.simplicite.util.tools.EditorTool.service(EditorTool.java:65)
at com.simplicite.webapp.tools.JSONServletTool.applicationService(JSONServletTool.java:296)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:70)
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:115)
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:490)
at com.simplicite.tomcat.valves.APISessionValve.invoke(Unknown Source)
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:678)
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:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
OK c’est déjà ça, il faut toujours investiguer par élimination d’hypothèses…
Ce qui est étrange c’est qu’en ayant importé ton module et ajouté ton code je ne constate pas le pb sur l’instance cloud testdaz.simplicite.io. Je ne comprends vraiment pas ce qu’il pourrait y avoir de particulier sur cet objet métier là qui pourrait poser pb. @Francois pensait à un caractère non UTF-8 dans ton code, dans ce que tu m’as copié collé par mail je n’en vois pas mais peut être que sur ton instance il y en a un…
Quoiqu’il en soit je suis toujours preneur des logs complètes (i.e. depuis le démarrage) Tomcat et Simplicité. Quand il y a un pb bizarre il faut toujours essayer de remonter à la source car parfois le symptôme visible n’a rien à avoir avec la vraie cause initiale du pb.
Bonsoir David,
cette instance a subit de nombreuses manipulations dont certaines n’étaient pas tout à fait maîtrisées (ça me rappelle mes débuts sur la BCSI; j’ai bien dû repartir une dizaine de fois “à blanc” après avoir cassé quelque-chose).
Nous allons voir avec Gaylord comment prendre la main sur l’instance PostGRE pour faire un diagnostic complet de la base et probablement procéder à un reset complet pour repartir sur une base P23 saine.
Bruno
Cet index n’est plus sensé être unique depuis pas mal de temps déjà (3/4 ans d’après un vieux commit sur le ficher create table pour postgre).
Historiquement, le dbd_path est devenu un “texte long” et plus un “varchar court” qui limitait des cas complexes de chemin trop long (une base mySQL ne peut d’ailleurs créer un index que sur 255car maximum dans le cas d’un type text, pour postgreSQL il doit aussi y avoir une limitation).
Vous devez le dropper et le recréer :
DROP INDEX IF EXISTS m_document_uk;
CREATE INDEX m_document_uk ON m_document (dbd_path);
L’unicité est gérée par Simplicité. Essayez de changer cet index via l’accès à la base et retestez.
@david je ne sais pas où il redevient unique dans le template docker ?
Dans le cas il faut aussi le renommer en _idx car _uk pas unique c’est bizarre… Donc plutôt:
DROP INDEX IF EXISTS m_document_uk;
CREATE INDEX m_document_idx ON m_document (dbd_path);
Je vais regarder pourquoi cet index est unique sur les templates (sachant que les scripts de setup MySQL et PostgreSQL sont générés depuis le master HSQLDB)
Fonctionnellement il est unique, mais techniquement les bases ne permettent pas toutes de créer un index unique sur un long text (l’index tronque la donnée et du coup ce ne peut plus être unique mais juste un hash non unique).
Il faut voir si on peut revenir un type varchar(4000) indexable de façon unique.
Il y a 4 ans on ne pouvait pas faire mieux qu’un index unique de varchar(255).
(mais certains clients avaient des noms de fichier à la con sur 250 caractères + path => on a été contraint de passer en long text non unique)
Ok donc avoir un duplicate key ne devrait pas arriver (surtout que là on ne trouve pas de doublon en base qui le justifierait… cf. les échanges précédents)
Est-ce qu’il serait possible que cette duplicate key se produise avant le commit (genre un “retry” dans la même transaction suite à un pb d’écriture du BLOB) ?
Attention à cette conversion pour mySQL exemple :
CREATE INDEX m_system_idx1 ON m_system (sys_value);
devient
CREATE INDEX m_system_idx1 ON m_system (sys_value(255));
CREATE UNIQUE INDEX m_user_token_uk ON m_user_token (utk_usr_id,utk_token);
devient
CREATE INDEX m_user_token_uk ON m_user_token (utk_usr_id,utk_token(255));
=> car impossible que ce soit unique si on tronque à 255 le champ text.
Sinon je n’ai jamais eu ce problème de duplicate puisque l’index n’est pas unique dans la base.
J’ai vérifié sur le template 4.0 (P23 et P24), dans le dump PostgreSQL initial, on a bien un index non unique :
CREATE INDEX m_document_uk ON m_document USING btree (dbd_path);
Je ne vois pas trop comment il aurait pu devenir unique…
La requête suivante a réglé le problème :
DROP INDEX IF EXISTS m_document_uk;
CREATE INDEX m_document_idx ON m_document (dbd_path);