Projet

Général

Profil

Actions

Anomalie #17437

fermé

Les fichiers volumineux ne sont pas capturés (Capture)

Ajouté par Etienne FAMERY il y a plus de 3 ans. Mis à jour il y a presque 3 ans.

Statut:
R&D - Terminé
Priorité:
0-Bloquant
Assigné à:
Quentin RIBAC
Version cible:
Début:
14/06/2021
Echéance:
07/10/2021

Description

Un fichier volumineux a été scanné par le service (380Mo/~500pages). Après paramétrage, la capture fonctionne, le LOT se trouve bien dans le dossier Done de Capture, les autres pdf sont consultables dans MaarchCourrier mais le pdf de 380Mo ne se trouve pas dans MaarchCourrier.


Demandes liées 1 (0 ouverte1 fermée)

Lié à Backlog Courrier - Anomalie #17806: Impossible d'enregistrer un document très volumineuxClôturé19/07/2021Actions

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de A qualifier à R&D - A étudier
  • Assigné à changé de EDI PO à Florian AZIZIAN

Mis à jour par Florian AZIZIAN il y a plus de 3 ans

  • Assigné à changé de Florian AZIZIAN à Etienne FAMERY

Mis à jour par Florian AZIZIAN il y a plus de 3 ans

  • Statut changé de R&D - A étudier à Complément d'Informations

Mis à jour par Etienne FAMERY il y a plus de 3 ans

  • Assigné à changé de Etienne FAMERY à Florian AZIZIAN
  • Priorité changé de 2-Sérieux à 0-Bloquant

Tests de l'import d'un fichier de 500Mo avec le module MaarchWSClient :

  • Test du paramétrage avec un fichier de 1Mo => import dans MaarchCourrier fonctionnel
  • Test avec le fichier de 500Mo => différentes erreurs liées à la config de php.ini retournées, après modification du post_max_size, upload_max_filesize et memory_size, aucune erreur retournée dans :
    logs apache, logs php, logs technique et php de MaarchCourrier et logs de MaarchCapture,

La seule information retournée est lors de l'exécution du script de Capture :

********************************************************************************
**                                Maarch Capture                              **
**  (c) since 2008 Maarch SAS                                                 **
********************************************************************************
[...]
Workflow initialized with id 'WMAARCH_SCAN_TO_MC-1624442042-1369719840'
Get first workflow step name...
Next step name is 'ImportFiles'
MaarchCapture step inputs: Array
(
    [0] => Directory
    [1] => Target
    [2] => Action
    [3] => MoveDirectory
)

MaarchCapture step: Array
(
    [positional] => Array
        (
        )

    [executable] => MaarchCapture.php
    [command] => Array
        (
            [opts] => Array
                (
                    [positional] => Array
                        (
                        )

                    [ConfigName] => Capture
                    [executable] => init
                    [BatchName] => MAARCH_SCAN_TO_MC
                )

            [name] => init
        )

)

Capture::processStep(ImportFiles)
control of /opt/maarch/MaarchCapture/files/maarchBD//5_GB.pdf
Capture::processStep(SendToMaarch)
Killed

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Projet changé de Backlog Courrier à 544
  • Statut changé de Complément d'Informations à R&D - A étudier
  • Version cible 291 supprimé

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Echéance changé de 21/06/2021 à 28/06/2021
  • Assigné à changé de Florian AZIZIAN à Alex ORLUC

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Version cible mis à 1.8 (Stable)

Mis à jour par Alex ORLUC il y a plus de 3 ans

  • Assigné à changé de Alex ORLUC à Guillaume HEURTIER

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de R&D - A étudier à En cours

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de En cours à R&D - En cours

Mis à jour par Guillaume HEURTIER il y a plus de 3 ans

  • Projet changé de 544 à Backlog Courrier
  • Statut changé de R&D - En cours à R&D - En test
  • Assigné à changé de Guillaume HEURTIER à Etienne FAMERY
  • Version cible changé de 1.8 (Stable) à 291

Mis à jour par Ludovic ARAUJO il y a plus de 3 ans

  • Statut changé de R&D - En test à En cours
  • Assigné à changé de Etienne FAMERY à EDI PO

Nous avons constaté que la capture ce fait avec capturekofax,
La configuration du serveur a été édité : les ram php, le post_max_file_size et upload_max_size

Quentin aurai une idée de l'anomalie sur les fichier volumineux ?
Seule la pièce jointe volumineuse n'est pas ajoutée.

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de En cours à R&D - En cours

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Echéance changé de 28/06/2021 à 03/08/2021

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de R&D - En cours à Complément d'Informations
  • Assigné à changé de EDI PO à Ludovic ARAUJO

Le contournement a-t-il débloqué la situation ?

Si oui, nous cherchons une solution plus aboutie mais cela va prendre un certain temps.

Mis à jour par Quentin RIBAC il y a plus de 3 ans

  • Assigné à changé de Ludovic ARAUJO à Quentin RIBAC

Mis à jour par Quentin RIBAC il y a plus de 3 ans

J’ai pu reproduire l’erreur avec un fichier volumineux (700Mo).

Le script de capture kofaxToMC génère des logs. Pour connaître leur emplacement :

  • voir dans la crontab la ligne appelant kofax_capture.sh
  • sur cette ligne, kofax_capture.sh doit être suivi d’un chemin d’un dossier
  • dans ce dossier il doit y avoir un dossier LogsKofaxToMC, les logs sont à cet endroit

Le log de l’erreur reproduite est :

user@maarch-pc$ cat ../../LogsKofaxToMC/kofax_capture_20210712-151820.log 
--- kofaxToMC ---

--- [1/1] /home/user/Documents/CD78/kofaxdocs/src/lot/17607_001.xml ---
Hash correct pour : /home/user/Documents/CD78/kofaxdocs/src/lot/17607_001_001.pdf
Hash correct pour : /home/user/Documents/CD78/kofaxdocs/src/lot/17607_001_002.pdf
injection du document principal ... (PDF) 
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 990436236 bytes) in /home/user/Documents/CD78/kofaxToMC/php/main.php on line 234

À cette endroit du code il y a l’appel à base64_encode(file_get_contents($filename)). Ce qui pose problème : il faut charger en mémoire à la fois le contenu de $filename par file_get_contents puis ce contenu encodé en base64 par base64_encode. C’est un double chargement, de plus un fichier en base64 est toujours ~30% plus lourd que l’original, donc pour être sûr, il faudrait allouer, pour un fichier PDF de 500Mo, environ 1.3Go en plus de ce qui est actuellement alloué.

À voir si on peut fournir à la fonction base64_encode autre chose qu’un texte brut, pour n’avoir à allouer que la mémoire pour la base64 et non pour le fichier original.

Mis à jour par Quentin RIBAC il y a plus de 3 ans

  • Statut changé de Complément d'Informations à R&D - En cours

Mis à jour par Quentin RIBAC il y a plus de 3 ans

  • Statut changé de R&D - En cours à A livrer
  • Assigné à changé de Quentin RIBAC à Ludovic ARAUJO

Un commit correctif du paquet kofaxToMC a été fait ici :

https://labs.maarch.org/deliveryteam/cd78/commit/13ca4d7d1e88b25eb36e9f677438683d7d914377

Au lieu de charger les fichiers en brut et en base64 puis en json, on prépare un stream du fichier avec un filtre d’encodage base64 qui n’est vraiment ouvert qu’au dernier moment, c’est-à-dire à la construction du json de la requête cURL.

Pour le déployer, se rendre dans le dossier d’installation actuel. Il s’agit normalement de /opt/maarch/modules/kofaxToMC, sinon voir le fichier référencé dans la crontab.

Vérifier que le code est à jour avec le commit 04684fb1988944d18a582c6569fe1dae0f7f13a4 (avant-dernier commit sur le dépôt) à l’aide de git log puis récupérer les sources avec git pull. Attention, il faut sauvegarder config.xml avant de mettre à jour.

Ceci fonctionne sur ma machine pour un pdf de 700Mo en document principal ou en pièce-jointe, cependant il a fallu mettre memory_limit=-1 dans le php.ini de apache2, et le chargement est très long à l’ouverture du courrier dans l’application, de l’ordre de la minute.

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de A livrer à R&D - En test

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de R&D - En test à Complément d'Informations

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de Complément d'Informations à R&D - Terminé

Mis à jour par Ludovic ARAUJO il y a plus de 3 ans

Les correctifs ne permettent la résolution de l'anomalie.
A voir avec nous sur le serveur clients si vous le souhaitez

Mis à jour par Ludovic ARAUJO il y a plus de 3 ans

  • Statut changé de R&D - Terminé à A traiter
  • Assigné à Ludovic ARAUJO supprimé

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Echéance changé de 03/08/2021 à 16/08/2021
  • Statut changé de A traiter à R&D - A étudier
  • Assigné à mis à Guillaume HEURTIER

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de R&D - A étudier à Etude planifiée

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Sujet changé de Courrier capturé n'arrive pas dans MaarchCourrier à Les fichiers volumineux ne sont pas capturés (Capture)

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Lié à Anomalie #17806: Impossible d'enregistrer un document très volumineux ajouté

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de Etude planifiée à R&D - A planifier
  • Assigné à Guillaume HEURTIER supprimé

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Statut changé de R&D - A planifier à R&D - En cours
  • Assigné à mis à Quentin RIBAC

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Echéance changé de 16/08/2021 à 20/08/2021

Mis à jour par GIT LAB il y a environ 3 ans

Commit ajouté sur la branche fix/17437/develop de MaarchCourrier
FIX #17437 TIME 1:30 revert to finfo::buffer where the new method was useless, added error handling for new method, removed “resource” mode for getMimeTypeAndFileSize()
https://labs.maarch.org/maarch/MaarchCourrier/commit/0f7fa47d2b55497ce8a011fc9a35f2554b1fe0f9

Mis à jour par Quentin RIBAC il y a environ 3 ans

  • Statut changé de R&D - En cours à R&D - En test

Mis à jour par GIT LAB il y a environ 3 ans

Commit ajouté sur la branche fix/17437/develop de MaarchCourrier
FIX #17437 TIME 0 better error messages
https://labs.maarch.org/maarch/MaarchCourrier/commit/2b8b7681454afef5951f4b65aa5450ac651748b5

Mis à jour par GIT LAB il y a environ 3 ans

Commit ajouté sur la branche fix/17437/develop de MaarchCourrier
FIX #17437 TIME 0:10 added missing error handling
https://labs.maarch.org/maarch/MaarchCourrier/commit/eeb22be0405b5f7bec2c56ba953f2fb71f2ffd6d

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Echéance changé de 20/08/2021 à 21/09/2021

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Version cible changé de 291 à 20.03 (Sécurité)

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Version cible changé de 20.03 (Sécurité) à 291

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Echéance changé de 21/09/2021 à 05/10/2021

Mis à jour par Emmanuel DILLARD il y a environ 3 ans

  • Echéance changé de 05/10/2021 à 07/10/2021

Mis à jour par Quentin RIBAC il y a environ 3 ans

  • Statut changé de R&D - En test à R&D - Terminé

Mis à jour par Emmanuel DILLARD il y a presque 3 ans

  • Version cible changé de 291 à 20.03 TMA4
Actions

Formats disponibles : Atom PDF