nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Imprécision ConversionCacheHolder

jelninos_

J'ai essayer de faire la conversion de 2 images différentes. J'ai pris une première image. Pour faire la seconde, je suis partis de la première, fais une rotation à 180 degrés, et écris un texte au milieu de l'image. Je me suis dis, voila j'ai bien deux images différentes.

et pourtant :

visuellement, elles sont bien différentes
les clés obtenues par CacheKeyGenerator.computeKey(converterName, blobHolder, parameters) sont aussi différentes :
/> image 1 : conv1:77984d4e6d53c6c45ee4bcf43738b2ac
/> image 2 : conv1:76e5ae0e9f25405c2d8a7b5e3297877e
par contre en Base64 dans la fonction getSubPathFromKey(String key) de ConversionCacheHolder.java, les premiers caractères sont semblables :
/> image 1 : cGljdHVyZTJkemk6Nzc5ODRkNGU2ZDUzYzZjNDVlZTRiY2Y0MzczOGIyYWM=
/> image 2 : cGljdHVyZTJkemk6NzZlNWFlMGU5ZjI1NDA1YzJkOGE3YjVlMzI5Nzg3N2U=

Et malheureusement la fonction se base sur les 10 premiers caractères pour générer le PATH du fichier de cache :
/> image 1 : .. nxserver/data/convertcache/cG/lj/dH/Vy/ZT
/> image 2 : .. nxserver/data/convertcache/cG/lj/dH/Vy/ZT

Du coups le cache de ma deuxième image a écrasé le cache de la première. J'ai dû monter la valeur de la variable "subPathPartSize" à 4 pour obtenir des PATH différents et ainsi obtenir les bons fichiers depuis le cache.

Suggestion : augmenter la valeur par défaut de "subPathPartSize" ou ajouter une autre clé pour être sûr d'avoir un Hash différent pour construire le PATH ?

Find more posts tagged with

Comments

Florent_Guillau

Quelle version de Nuxeo utilisez-vous ?

Je ne peux pas reproduire ce problème, en effet même si le préfixe de path utilisé est le même (ce qui n'est certes pas optimal mais pas grave), le nom de fichier final utilisé dans le dernier répertoire est différent, c'est le has MD5 du fichier donc il n'y a pas de collision. Sur une conversion récente d'une image en trois versions réduites par exemple j'ai:

./cG/lj/dH/Vy/ZV/577271a835555baaaa685c3f31746f02
./cG/lj/dH/Vy/ZV/791374bb6258958947573304121db5c4
./cG/lj/dH/Vy/ZV/baace5a9f76e27a5aadb100bc8977b4e

jelninos_

Bonjour, et merci pour votre réponse.
/> Je travaille sur la version 7.2
/> Effectivement il ya à la fin du PATH le MD5. Sauf que pour le cas où il ya plusieurs Blob dans le BlobHolder, seul le MD5 du premier Blob de la série est pris en compte.
/> A priori pour pourvoir regrouper tous les Blobs dans un même répertoire :

public String persist(String basePath) throws IOException {
    if (blobs == null || blobs.isEmpty()) {
        return null;
    }
    Path path = new Path(basePath);
    >>> path = path.append(getHash()); <<<<
    if (blobs.size() == 1) {
        File file = new File(path.toString());
        getBlob().transferTo(file);
        return file.getAbsolutePath();
    } else {
        File dir = new File(path.toString());
        dir.mkdir();
        for (Blob blob : blobs) {
            dir = new File(path.toString());
            dir.mkdir();
            File file = new File(path.append(blob.getFilename()).toString());
            blob.transferTo(file);
        }
        return dir.getAbsolutePath();
    }
}

résultat dans le répertoire de cache :
/> ./cG
/> ./cG/lj
/> ./cG/lj/dH
/> ./cG/lj/dH/Vy
/> ./cG/lj/dH/Vy/ZT
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/11-0_2.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/10-0_2.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/12-6_10.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/12-0_5.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/12-1_2.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/11-3_5.jpeg
/> ./cG/lj/dH/Vy/ZT/137a73f51e1744ff4f84032855e2c6c6/8-0_0.jpeg

Il se trouve que dans mon cas de conversion :

les noms de fichiers sont toujours les mêmes mais leur contenu change
le premier fichier est binairement identique dans mes 2 conversions et c'est normal

Du coup je me retouve dans mes 2 conversions avec la même base de PATH suivi du même MD5 (celui du premier fichier), suivi des mêmes noms de fichiers (mais leur contenu change !)
/> Pour préciser il s'agit d'une conversion d'image au format DZI.

Quelques suggestions si cela peut aider :

faire en sorte que pour chaque fichier se soit son propre MD5 dans son PATH, car effectivement ne pas mettre en cache 2 fichiers binairement identique est louable.
du coup on pert le "regroupement" des fichiers du BlobHolder, il faut donc trouver une autre solution que le PATH pour les regrouper.
pourquoi pas un fichier supplémentaire à la racine du cache (convertcache) qui a comme nom par exemple le BASE64 (ou la valeur cachekey) de la conversion et qui contient la liste des PATH de Blob à récupérer
on pourrait aussi y stocker le nom du fichier (qui peut changer même si le binaire ne change pas) et les autres informations du blob qui sont malheureusement aujourd'hui perdues lors de l'utilisation du cache
ainsi à la fonction "load(String path)" on ne lui passe plus un PATH racine mais un fichier contenant tous les PATH à récupérer

A bientôt 🙂

Florent_Guillau

Merci pour les détails exacts sur la manière dont vous reproduisez le problème. Nous allons revoir ce système de cache ([NXP-17097](https