Migration 2.1 vers 3b

[rgouyet]

J'ai fait la manipulation proposée un peu plus haut dans ce fil de discussion par Nicolas:

<document-format><name>Microsoft Word 2007</name>
    <family>Text</family>
    <mime-type>application/vnd.openxmlformats-officedocument.wordprocessingml.document</mime-type>
    <file-extension>docx</file-extension>
    <export-filters>
      <entry><family>Text</family><string>MS Word 2007</string></entry>
    </export-filters>
</document-format>
‍‍‍‍‍‍‍‍‍‍

Mais je viens de tester et mon document n'est pas indexé.
J'ai vérifié, le process soffice est bien chargé.
Le document s'ouvre bien avec swriter.exe
Le même document sauvegardé au format word 2003 est bien indexé.
Après, j'ai arrété Alfresco, supprimé le répertoire lucene-indexes, fait un index.recovery.mode=FULL mais ce n'est pas mieux…

J'ai oublié quelque chose ?

[nicolas_4463]

Bonjour,
Je partage avec vous quelques éléments de réflexion :

Concernant l'indexation, j'ai l'impression (mais ce n'est qu'une impression) que tout ne se joue pas au moment de la reconstruction des indexes.
En effet, un fois la tâche de reconstruction terminée, nous avons relevé dans le fichier catalina.out un certain nombre d'erreurs générées par POI lors de la lecture de fichiers Excel. Je me dis donc que les indexations continuent au delà de la reconstruction.

Petite question, le type mime associé (Content Type) à vos fichier docx est-il bien positionné ?
Nous avons un certain nombre de fichier docx dans le référentiel qui ont été déposés au tout début de notre passage en 2.1. A cette époque les fichiers docx ne faisaient pas partie du fichier de définition mimetype-map.xml. Ces fichiers ont été associés au type mime OctetStream par la version 2.1.
Je pense que cette mauvaise association  pourrait expliquer la non-indexation des documents docx.

Tiens, tiens,     je viens de vérifier dans la version 3stable migrée, nous avons perdu les Content Type de tous les fichiers docx ! Par contre l'icône associé est correct.
Effectivement, le seul docx qui ressort de mes recherches est celui que j'ai créé juste après la migration pour mes tests !

Après comparaison des deux fichiers  mimetype-map.xml j'ai une différence sur les docx :
Version 2.1

<mimetype mimetype="application/vnd.openxmlformats-officedocument.wordprocessingml.document" display="Microsoft Word 2007">
      <extension>docx</extension>
</mimetype>
‍‍‍‍‍

Version 3stable

<mimetype mimetype="application/vnd.openxmlformats-officedocument.wordprocessingml" display="Microsoft Word 2007">            
        <extension>docx</extension>
</mimetype>
‍‍‍‍‍

Côté Excel 2007, les types mimes sont bien identiques et nous n'avons rien perdu.
Ceci n'expliquerait-il pas cela ?!?

Nicolas

[rgouyet]

Je ne suis pas aussi avancé que vous dans les tests. Je n'ai pas commencé les tests de migration.
Pour le moment, je fais mes tests uniquement sur une version vierge de Alfresco 3 stable.
Donc mon repository est vide et je fais mes tests au coup par coup.
Dans la version 3.0, les mime type docx sont bien positionnés par défaut.

[rgouyet]

Concernant l'indexation, j'ai l'impression (mais ce n'est qu'une impression) que tout ne se joue pas au moment de la reconstruction des indexes.
En effet, un fois la tâche de reconstruction terminée, nous avons relevé dans le fichier catalina.out un certain nombre d'erreurs générées par POI lors de la lecture de fichiers Excel. Je me dis donc que les indexations continuent au delà de la reconstruction.
Nicolas

J'ai probablement trouvé l'explication dans ce post en anglais.

Note that the progress report you see during startup only reports on the synchronous (metadata indexing) part of the reindex process.
The asynchronous part (full text indexing) happens concurrently after the system has started, and depending on how much content you have could take quite a while (full text indexing involves extracting text from all of your documents, which is both an I/O and CPU intensive operation).‍‍

Pour les non anglophones, le processus de réindexation affiche l'avancement dans le fichier de log pour ce qui concerne l'indexation des métadonnés (traitement réalisé de manière synchrone). Le contenu est indexé par la suite de manière asynchrone et cela peut prendre beaucoup plus de temps.

Romain

[nicolas_4463]

Bonjour,
Nous avons terminé la migration de notre référentiel 2.1 vers la 3 labs, pour être précis :

Current version 3.0.0 (Stable 1526) schema 1002 - Installed version 1.2.1 schema‍

Trois bonnes semaines sur la plate-forme de test auront été nécessaires.
Quatre ou cinq patchs "maison" pour réctifier nos soucis de migration à savoir :

a) Les anciens documents versionnés qui faisaient disjoncter un des patchs: des noeuds dans le versionStore n'avaient pas la propriété figée (frozen property) "dbid".
b) Une erreur sur le "user homes directory", nous avions eu le malheur de le renommer en "Espaces personnels" erreur fatale. Remarque: Ce patch était plus en perspective, d'un espoir, éventuel, que la version 3.2 nous réserve pas une belle surprise… J'ai fait un post à ce sujet: le CIFS toujours au coeur des ennuis :mrgreen: 
c) Un changement massif, post-migration, des mimetypes pour les document Word2007. Ils n'étaient pas bon et du coup, ne passaient pas à l'indexation.

Une petite optimisation du principal script SQL, histoire de migrer la base de données en moins de 3 jours.
Nous avons abandonné le FileSystem de type NFS, au profit d'un ReiserFS, pour passer outre la limitation d'un nombre maxi de fichiers ou de répertoires (j'sais plus).
Nous sommes passés au JDK 1.6.0_15.
La migration s'est passée d'un tenant et sans erreur.  

A partir de là, nous sommes entrés dans une autre dimension: Aucun soucis côté application Web mais hélas, comme d'habitude, d'énormes emm…, pardon, ennuis avec le CIFS  :mrgreen:
Nous avons migré sur notre serveur de production, appelons-le ANACUT.
Dès le démarrage d'Alfresco et lors des premiers accès aux fichiers via le CIFS, punition immédiate :

21:29:29,603 ERROR [transaction.SpringAwareUserTransaction.trace] Detected first UserTransaction which is being garbage collected without a commit() or rollback() 
21:29:29,826 ERROR [transaction.SpringAwareUserTransaction.trace] Logging of transaction call stack is now enabled and will affect performance 
03:03:49,146 ERROR [transaction.SpringAwareUserTransaction.trace] UserTransaction being garbage collected without a commit() or rollback(). 
   Started at: 
      org.alfresco.util.transaction.SpringAwareUserTransaction.begin(SpringAwareUserTransaction.java:389) 
      org.alfresco.filesys.alfresco.AlfrescoDiskDriver.beginTransaction(AlfrescoDiskDriver.java:332) 
      org.alfresco.filesys.alfresco.AlfrescoDiskDriver.beginWriteTransaction(AlfrescoDiskDriver.java:180) 
      org.alfresco.filesys.repo.ContentDiskDriver.closeFile(ContentDiskDriver.java:1822) 
      org.alfresco.jlan.smb.server.VirtualCircuit.closeCircuit(VirtualCircuit.java:474) 
      org.alfresco.jlan.smb.server.SMBSrvSession.cleanupSession(SMBSrvSession.java:349) 
      org.alfresco.jlan.smb.server.SMBSrvSession.run(SMBSrvSession.java:1302) 
      java.lang.Thread.run(Thread.java:595) 
‍‍‍‍‍‍‍‍‍‍‍‍‍‍

L'accès devient instable de plus en plus lent jusqu'à innacessible, le log se tartine d'erreurs :

ERROR [org.alfresco.util.transaction.SpringAwareUserTransaction.trace] UserTransaction being garbage collected without a commit() or rollback(). 
   Started at: 
      org.alfresco.util.transaction.SpringAwareUserTransaction.begin(SpringAwareUserTransaction.java:389) 
      org.alfresco.filesys.alfresco.AlfrescoDiskDriver.beginTransaction(AlfrescoDiskDriver.java:332) 
      org.alfresco.filesys.alfresco.AlfrescoDiskDriver.beginWriteTransaction(AlfrescoDiskDriver.java:180) 
      org.alfresco.filesys.repo.ContentDiskDriver.closeFile(ContentDiskDriver.java:1822) 
      org.alfresco.jlan.smb.server.VirtualCircuit.closeCircuit(VirtualCircuit.java:474) 
      org.alfresco.jlan.smb.server.SMBSrvSession.cleanupSession(SMBSrvSession.java:349) 
      org.alfresco.jlan.smb.server.SMBSrvSession.run(SMBSrvSession.java:1302) 
      java.lang.Thread.run(Thread.java:595) 
‍‍‍‍‍‍‍‍‍‍‍

Le plus fort de tout est que durant 3 semaines d'essais, sur un serveur de test strictement identique (hormis le nom et l'adresse IP), nous n'avons jamais eu la moindre erreur lors des accès CIFS.
Après plusieurs tentatives nous arrivons aux hypotèses suivantes :

ANACUT est défaillant côté hardware
Les données du référentiel et/ou de la base de données fraichement migrées sont daubées
Nous avons oublié de sacrifier un poulet sur le serveur  :lol:

Pour essayer d'éliminer l'hypotése des données, nous les copions vers ANACUT-TNI, la machine que nous avons utilisée pour réaliser les tests préalables.
Nous remettons en service, tout se passe bien, pas d'erreur avec les accès CIFS.
La balance penche sensiblement vers l'hypotese d'un soucis matériel.
Qu'à cela ne tienne, nous arrêtons ANACUT, et renommons ANACUT-TNI en ANACUT avec l'IP de l'ancien ANACUT.
Très confiant, c'est parti pour un "alfresco.sh start". Dès les premiers accès CIFS vlan, mêmes erreurs plantage dans tout les sens, CIFS inutilisable.
ARRRRRRRRRRGGGGGGGGGGH  :twisted:
Marche arrière, on revient avec le nom ANACUT-TNI et l'IP initial de ce nom. Remise en route, ca fonctionne bien. :shock:
On regarde dans les coins de la pièce pour vérifier s'il n'y a pas quelques caméras cachées, on évoque à demi-mots l'émission SUPRISE SUR-PRISE.
Et on est surtout très vert (de rage), victime une fois de plus d'une stabilité douteuse du CIFS. 

Mais l'histoire ne s'arrête pas là, nous décidons d'abandonner le nom ANACUT pour notre serveur de production au profit de ANACUT-DORP.
Puisque, apparamment, c'est un nom composé qui semble convenir (j'vous jure qu'avec le recul, je suis effrayé des stupidités dans lesquelles on s'engouffre, confronté à ce genre de situation).

Redémarrage, quelques tests: Youpi ! Tout fonctionne, allons-y gaiment ouvrons aux utilisateurs !

Pour faire court, nous avions juste repoussé la sentence !
Dès la première grosse montée en charge le CIFS s'est lamentablement effondré, avec toujours les mêmes erreurs pour au final devenir inaccessible.
Mais quelle aventure palpitante !!!
En tout cas, si les nouvelles versions d'Alfresco ne brillent pas par leur stabilité côté CIFS, elles excellent dans la convivialité des moments passés ( heureusement,je ne suis pas seul sur le coup, sinon c'est dans la cave, au bout d'une corde que l'on m'aurait découvert  :mrgreen: ).

Voilà, où nous en sommes, le CIFS est coupé (enfin presque, si on le désactive par le fichier de paramétrage, tout explose) donc les ports sont fermés.
Le bug est référencé : https://issues.alfresco.com/jira/browse/ETHREEOH-1553
Nous avons mis en service en guise de pseudo substitution l'accès FTP et nous avons une semaine pour trouver une solution digne de ce nom.
Pour la suite, on va s'attacher à trouver une solution rapidement sinon, c'était et ce sera, nos derniers instants avec Alfresco et nos dernières contributions au forum de la version communautaire (3 Labs( on confirme)……  Stable :lol: )

Nicolas

[michaelh]

Mouaip …. Ca fait partie de ces bugs vicieux qui touchent une infime partie des gens et qui sont excessivement difficiles à reproduire.

Dans le cas présent on a reçu des signalements, le développeur n'a jamais réussi à le reproduire, et l'équipe de test une seule fois … et plus jamais ensuite !
Idem coté utilisateur où comme vos tests le montre, il est difficile de trouver la logique derrière tout ça. Autant dire que ça n'aide pas à la résolution (Ce serait réglé depuis longtemps si ça touchait tout le monde et pas juste une large minorité).

Les pistes sont nombreuses : problème de JVM (la majorité l'a résolu avec un tuning de JVM), problème avec Spring, … mais aucune satisfaisante. On peut juste dire qu'on a autant envie que vous de trouver LA solution parce que passer des semaines sur un bug unique, ça n'amuse personne.

Bref, si c'est frustrant pour vous, ça l'est aussi pour nous.
Ce qui ne va pas vous avancer beaucoup, j'en conviens

(et laissez ce pauvre poulet tranquille !  :wink: )

[jmi9999]

Bonjour,

J'ai le même problème de perte de documents (version).  Une solution ?

Merci
JMi