vlahoda
commented
1 year ago V logu Tomcatu je v tom case tato chyba: 25-Sep-2022 21:32:15.538 SEVERE [cz.incad.kramerius.processes.impl.ProcessSchedulerImpl-thread] cz.incad.kramerius.processes.impl.DatabaseProcessManager.updateLongRunningProcessState ERROR: duplicate key value violates unique constraint "process_batch_pkey" Detail: Key (batch_token)=(fbb85dcd-80bd-49f8-8cfb-c7558d7d47d3) already exists. Where: SQL statement "INSERT into process_batch SELECT processes.token AS batch_token, batch_state(processes.status) AS batch_state, count() AS process_count, min(processes.process_id) AS first_process_id, min(processes.status) AS first_process_state, min(processes.uuid) AS first_process_uuid, min(processes.defid) AS first_process_defid, min(processes.name) AS first_process_name, min(processes.planned) AS planned, min(processes.started) AS started, max(processes.finished) AS finished, min(processes.owner_id) AS owner_id, min(processes.owner_name) AS owner_name FROM processes WHERE processes.token=rec.token GROUP BY processes.token ORDER BY first_process_id DESC" PL/pgSQL function refresh_process_batch() line 17 at SQL příkaz org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "process_batch_pkey" Detail: Key (batch_token)=(fbb85dcd-80bd-49f8-8cfb-c7558d7d47d3) already exists. Where: SQL statement "INSERT into process_batch SELECT processes.token AS batch_token, batch_state(processes.status) AS batch_state, count() AS process_count, min(processes.process_id) AS first_process_id, min(processes.status) AS first_process_state, min(processes.uuid) AS first_process_uuid, min(processes.defid) AS first_process_defid, min(processes.name) AS first_process_name, min(processes.planned) AS planned, min(processes.started) AS started, max(processes.finished) AS finished, min(processes.owner_id) AS owner_id, min(processes.owner_name) AS owner_name FROM processes WHERE processes.token=rec.token GROUP BY processes.token ORDER BY first_process_id DESC" PL/pgSQL function refresh_process_batch() line 17 at SQL příkaz at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354) at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169) at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:136) at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136) at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136) at cz.incad.kramerius.utils.database.JDBCUpdateTemplate.executeUpdate(JDBCUpdateTemplate.java:79) at cz.incad.kramerius.processes.impl.DatabaseProcessManager.updateLongRunningProcessState(DatabaseProcessManager.java:366) at cz.incad.kramerius.processes.impl.AbstractLRProcessImpl.startMe(AbstractLRProcessImpl.java:220) at cz.incad.kramerius.processes.NextSchedulerTask.run(NextSchedulerTask.java:45) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505)
pavel-stastny
Dobrý den, máme stále pokračující problém, je to velmi podobné jako v issue https://github.com/ceskaexpedice/kramerius/issues/742 https://github.com/ceskaexpedice/kramerius/issues/897
Problém uzavírání tokenů při hromadných úlohách. Při hromadném importu, hromadném setPrivate nebo setPublic, při zmenách dnnt a pod. Pokud při importu do jednoho adresáře dám více jak 10, 12 max 15 root adresářů (třeba 15 monographií), importování náhodně může selhat. Aby byl import alespoň trochu rychleji zadán, dávám do jednoho adresáře max. 10 souborů (root adresářů). Import proběhne, reindex se pak většinou spustí, dokončí se, ale nakonec to skončí chybou neuzavření tokenu. https://admin.k7-test.mzk.cz/processes/333664 https://admin.k7-test.mzk.cz/processes/332744 https://admin.k7-test.mzk.cz/processes/332799 a další...
Někdy se token uzavře, ale stejně se v logu označí jako chyba. https://admin.k7-test.mzk.cz/processes/333289
Minulý víkend, pri několikadenním importování se při nahromadění několik desítek (možná stovek) neuzavřených tokenů na servru vyčerpala pamět. Museli jsme restartovat. Avšak pokud importuji tak, že každý root-adresář dám do vlastního import adresáře, (např. monograph1, monograph2,...... monographX), v daném adresáři bude jenom jeden soubor (root-adresář), tak počet takto po sobě postupně za sebou spouštěných importů může být jakékéliv množství - import do akubry pak proběhne vždy, reindex se spustí vždy a nakonec se všude token uzavře, zde při tomto způsobu (po jednom) chyba nevznikne. Nesouvisí to pro ten plánovač nějak s časy (timestamp)? Když ty adresáře otrocky za sebou spouštím postupně, každý soubor dostane jiný čas. Chtělo by to vyřešit tak, aby se z hromadných importů (nebo z hromadných jakýkoliv úloh, kde se zapisuje do akubry) staly postupně za sebou jdoucí jednotlivé úlohy.