topic Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION in Alfresco Archive

[RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Wed, 09 Jul 2008 13:01:43 GMT

Bonjour à tous,Il y a 2 jours, au retour de we… Alfresco est très lent, CIFS tombe en timeout… On décide de l'arrêter et le relancer… de nombreuses erreurs apparaissent. Nous cherchons dans la documentation et finalement, on décide de passer en recovery d'index FULL.Il met 36 heures et arrivé à 60%,

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Fri, 11 Jul 2008 08:53:15 GMT

Entre nous … cette erreur ne me dit rien …

Vous me direz que ça ne vous avance pas, mais je ne voulais pas que le message reste sans réponse

Par contre vous dites "de nombreuses erreurs apparaissent" mais sans les citer …. ça n'aide pas.

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Fri, 11 Jul 2008 19:56:51 GMT

Bonsoir Michael,

Effectivement, je n'ai pas été très prolixe… Voici l'histoire : Samedi, Alfresco plante (pour une raison encore inconnue : Nous avons supprimé les logs !). Nous le relancons lundi, mais il est extrêmement lent (cpu à 100%).
Nous décidons de l'arrêter, puis de le relancer… Pareil. Finalement, on décide de relancer une indexation FULL. A 60%, ça plante. Enfin c'est ce qu'on a pensé : Il était resté à 60% depuis 13 heures et des messages d'erreur liés au batch LDAP que j'avais mis en place apparaissaient. Nous avons arrêté la reindex et après avoir désactivé les batchs, avons relancé le reindex FULL… Voici ou nous en sommes :
0-10% : 1 heure
10-20% : 2 heures
20-30% : 4 heures
30-40% : 4 heures 25
40-50% : 5 heures 50
50-60% : 5 heures 30
60-70% : Il tourne depuis 33 heures maintenant et il n'a pas encore atteint les 70%…

Michael, vous qui êtes un spécialiste d'Alfresco, pensez-vous que l'on puisse rester optimiste ? A-t-on bon espoir que le rebuild se termine ? J'avoue que le délai me laisse penser qu'on est mal barré… Et inutile de dire que nos sauvegardes d'Alfresco ne fonctionnaient plus depuis le 06 juin… Donc c'est notre dernière chance… Avec des milliers de docs dedans !

Si l'un de vous, en plus de compatir, a une idée…

Greg

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Tue, 15 Jul 2008 08:03:55 GMT

Michael, vous qui êtes un spécialiste d'Alfresco, pensez-vous que l'on puisse rester optimiste ? A-t-on bon espoir que le rebuild se termine ? J'avoue que le délai me laisse penser qu'on est mal barré…

Même sans être un spécialiste, ce délai me laisserait en effet un peu songeur …

Et inutile de dire que nos sauvegardes d'Alfresco ne fonctionnaient plus depuis le 06 juin… Donc c'est notre dernière chance… Avec des milliers de docs dedans !

J'allais vous proposer de repartir sur un backup … ouille.

Sans vouloir être désagréable, j'ai le sentiment que vous cumulez les problèmes. Le premier ayant sans doute été de lancer un rebuild "pour voir".

Je ne sais pas si c'est vous qui avez fait l'installation, mais vous avez deux alternatives :
- Vous repartez sur l'ancien backup en oubliant plus d'un mois de travail (et sans savoir ce qui a causé le problème, et si il est réglé).
- Vous demandez de l'aide à de vrais pros d'Alfresco (ce qui va impliquer une souscription, mais ce n'est pas moi qui vais vous apprendre que vos données ont aussi une valeur).

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

rguinot — Tue, 15 Jul 2008 09:01:41 GMT

optimistic locking failed‍

Il semble que vous ayez plusieurs threads qui "travaillent" sur le même record.

Sans une investigation poussée, il va être difficile de répondre, mais :
* quelle est votre base de données ? est elle bien transactionnelle ? quel est le mode d'isolation des transactions en cours d'utilisation ?
* vous n'auriez pas par hasard "pour tester" changer le mode transactionnel par défaut dans transaction.properties ?

Vous pouvez essayer d'augmenter le nombre de réessais, ou passer en mode de locking pessimiste, ce qui réduira les performances .

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Wed, 16 Jul 2008 13:21:40 GMT

Merci Romain et Michael,

Nous avons finalement retrouvé une sauvegarde mensuelle du 05/07, 4 heures avant qu'Alfresco ne plante (un samedi donc) !
Nous sommes donc sauvés. Nous avons effectivement cumulé les problèmes, mais puisque cela se termine bien, cette expérience aura été riche d'enseignements :

D'abord, et comme vous le dites Michael, les données ont une valeur. Aussi la politique de sauvegardes et de disponibilité doit-elle être à la hauteur de cette valeur… La qualité d'Alfresco et ses fonctionnalités l'ont imposé très vite comme le standard de notre gestion documentaire, et nous avons été dépassé par son succès. Nous nous employons à réparer cette erreur : En nous appuyant sur la documentation du wiki anglais, nous allons mettre en place un disaster recovery plan + de la haute dispo pour Alfresco (tout tourne sous VM).
Ensuite, chose qui me chiffonne un tantinet, il est à priori impossible de récupérer des docs qui ont été "intégrés" dans le repository d'Alfresco. Et là on devine une certaine adhérence entre le modèle alfresco et les documents que j'intègre dans mon système. Ils sont transformés ! (nom changé pour prendre un id et extension passée en .bin)…
C'est pas joli joli de se dire que nos docs, si faciles à lire et à trier dans un sysex adapté (windows, linux ou mac en général) ne le sont plus une fois "fondus" dans alfresco… BEARK !!!
Vu les heures que j'ai passé dessus, j'ai pu m'apercevoir qu'il n'était pas si difficile de "détricoter" cette adhérence (je devrais dire "décoller"). Et je me prends à rêver d'une classe que je pousserais en AOP dans la config spring d'alf pour prendre note (en bdd ou en fichier) de l'ancien nom de fichier intégré dans alf et de son nouveau ptit nom, une date en plus, le N° de version au moment du dépot d'un doc dans le repo, et hop, le jour ou je veux m'en sortir avec simplement le repo (et plus ce mix repo / BDD / index lucenes), ben c'est jouable-facile-rapide… Qu'en pensez-vous Michael, Romain, et les autres ? Pour l'heure, je me suis contenté de grep et awk vite faits qui m'ont permis de sauver la vie de mes utilisateurs en leur redonnat rapidement les docs dont ils avaient besoin…

Enfin dernier point, reconstruire les index lucene, ben c'est long ! (et c'est pas Unisys qui va me contredire : http://unisys.com/eprise/main/admin/corporate/doc/Alfresco_Benchmark_Report_BL100093.pdf, page 9 : A full reindex was kicked off to see how long it would take. The single process took approximately 24 hours to reindex 10 percent of the complete set. Alfresco is addressing this.

Voila, mes 2 cents en retour d'expérience

Dernière question, pour le cas ou vous sauriez : Je fais une sauvegarde avec Tina… Et je sais qu'il est INTERDIT d'accéder aux fichiers d'index quand Alfresco tourne… Pensez-vous/savez-vous si je dois arrêter Alfresco avant une sauvegarde d'un outil tel que Tina ? Je me demande si la sauvegarde n'aurait pu être à l'origine de la défaillance du serveur…

Bien cordialement,

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

rguinot — Wed, 16 Jul 2008 13:48:32 GMT

Quelques remarques :

Concernant la "fonte" des documents dans Alfresco , il s'agit plutôt d'une intégration dans Lucene, et , plus généralement dans un ECM. Ce mécanisme d'intégration est décrit en détail dans le livre "Lucene in Action", très intéressant, et dispo chez Amazon. Pour l'avenir, rien ne vous empêche de développer un web script simple qui convertira l'id en chemin+nom si vous souhaitez contribuer. cela dit, cette information est peut être déjà disponible avec la bonne requête SQL.
Egalement, rien de vous empêche de programmer régulièrement (pour ne pas dire cron-er), EN PLUS de vos backups habituels et réguliers avec empreinte SHA1 et géographiquement distribués, un export complet de votre repository via FTP, et de le sauvegarder pour avoir un backup "de la dernière chance". vous perdrez néanmoins les métadonnées, les versions, les workflows etc…

En ce qui concerne la réindexation, cela dépend de la volumétrie, de l'environnement de déploiement (nb de cpus etc , params JVM..) , et de la config de nombreux paramètres (lucene entre autres, ceux de classes/alfresco/repository.properties, et sur ce point une souscription à du support aurait probablement pu vous aider)

Je ne connais pas du tout TINA donc je ne peux vous aider la dessus…De notre côté, nous arrêtons effectivement les JBoss notamment et les bases de données pour être plus safe vis à vis d'InnoDB notamment et d'autres composants qui préfèrent le froid.

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Wed, 16 Jul 2008 20:12:46 GMT

Bonsoir Romain,

Et merci pour ces réponses instructives (lucene in action commandé). Je serais ravi de servir la communauté en pondant un truc utile pour Alfresco… Je garde donc votre suggestion en tête.
Pour le tuning, vous avez raison, nous avons pêché… Et du support ne serait pas de trop. Je pense que ma société finira par y venir.

Je vais aussi suivre votre expérience pour la sauvegarde d'Alfresco, ce qui sera toujours plus safe…

En attendant, j'ai peut-être trouvé les raisons de ce plantage violent… Mais je continue d'analyser et vous fournirai mes conclusions.

Encore merci,

Greg

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Thu, 17 Jul 2008 12:29:54 GMT

Hello,

En ce qui concerne la manière dont Alfresco stocke les données, Romain en a dit pas mal. Juste retenir qu'il n'y a pas beaucoup de méthodes de stockage qui permettent l'unicité du nom, de lever les problèmes d'encodage, et cela sans renommer les documents (comprendre "aucune").

Il ne faut jamais confondre "alf_data" qui est un répertoire système avec les interfaces que sont CIFS, NFS, ou FTP. Considérez bien que ce dossier est le seul qui permette, associé à une base de données, d'enrichir les données pour aller franchement plus loin qu'un "vulgaire" (je ne trouve pas d'autre mot même si ce n'est pas le meilleur) système de fichier.

Sinon ce serait un peu comme se plaindre parce que nos jolies données sous format texte sont stockées dans un SGBDR sous un format qu'on ne comprend pas et demander à MySQL de tout stocker dans des fichiers ASCII

Pour en venir au système de "détricotage", j'avoue ne pas en voir l'intérêt. Je préfère de loin une bonne (donc testée) sauvegarde à un système qui me fait penser à la réinvention d'un … entrepôt de données. Mais je suis peut-être dans le faux

Ensuite oui, reconstruire un index prend du temps. Et on ne le cache pas. D'où l'intérêt de le lancer en toute connaissance de cause. Je peux juste vous dire que le doc Unisys a raison : ça va s'améliorer grandement dans les versions à venir (parallélisation).

Enfin oui, le backup à chaud … c'est chaud ! Préférer le backup à froid si possible, en prenant soin de ne pas arréter Alfresco pile à l'heure où il lance ses tâches de maintenance quotidienne (vers 3h ou 4h du matin).

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Thu, 17 Jul 2008 17:15:03 GMT

En ce qui concerne la manière dont Alfresco stocke les données, Romain en a dit pas mal. Juste retenir qu'il n'y a pas beaucoup de méthodes de stockage qui permettent l'unicité du nom, de lever les problèmes d'encodage, et cela sans renommer les documents (comprendre "aucune").

==> Je suis d'accord Michael. N'en jetez plus !

Il ne faut jamais confondre "alf_data" qui est un répertoire système avec les interfaces que sont CIFS, NFS, ou FTP. Considérez bien que ce dossier est le seul qui permette, associé à une base de données, d'enrichir les données pour aller franchement plus loin qu'un "vulgaire" (je ne trouve pas d'autre mot même si ce n'est pas le meilleur) système de fichier.

==> Là, je ne vois pas bien : alf_data est le repository quand vous me parlez de CIFS, NFS, FTP, ou encore WEBDAV qui ne font "qu'exposer" ce repository. Ca je le comprends plutôt bien. Vous pensiez que je confondais ?

Sinon ce serait un peu comme se plaindre parce que nos jolies données sous format texte sont stockées dans un SGBDR sous un format qu'on ne comprend pas et demander à MySQL de tout stocker dans des fichiers ASCII

==> Bon là, j'avoue m'être un peu emballé (pour l'adhérence entre ma donnée et le système, quoique). Mais votre métaphore me fait sourire : ca aurait beau être dans des fichiers ascii, ça ne signifie pas que je le comprendrais mieux 😉
Moi, y a un truc que j'aime bien. C'est lightroom. Je ne sais pas si vous connaissez, mais l'idée de ne pas toucher à un fichier (encore qu'on puisse y stocker les méta-données) et stocker les méta-données dans des fichiers xmp à part (oui Michael, je sais qu'on peut manipuler des données xmp dans Alfresco), ben ça j'aime bien. Y a une base de données, soit, qui fait toute la force de lightroom avec ces xmp, n'empêche que les fichiers, jamais, ne sont renommés !

Pour en venir au système de "détricotage", j'avoue ne pas en voir l'intérêt. Je préfère de loin une bonne (donc testée) sauvegarde à un système qui me fait penser à la réinvention d'un … entrepôt de données. Mais je suis peut-être dans le faux

==> Ben non. Z'êtes plutôt convaincant. Je n'en vois pas plus l'intérêt que ça, si ce n'est que ce serait fichtrement génial qu'Alfresco ne touche pas à mes fichiers, qu'il les enrichisse etc… OUI (il le fait excellemment bien, je dois le reconnaître et c'est bien la raison pour laquelle j'avais, il y a 2 ans, réussi à l'imposer comme solution de gestion documentaire à ma direction informatique). Mais voilà… On en veut toujours plus, et j'avoue que je râle depuis longtemps sur l'interface graphique pas facile à modifier et pas très ergonomique d'Alfresco (ça change en bien et j'ai adoré Opsoro pour la petite histoire). Je profitais de mes déboires pour trouver un nouveau sujet de râle (arrghh) : Pourquoi Alfresco qui ferait po comme mon Lightroom ? Hein ?
Bon la question est peut-être un peu benoîte, voire stupide comme ça, mais quand même, ça me chatouille c't'histoire, pas vous (y aura bien quelqu'un pour m'aider !)

Ensuite oui, reconstruire un index prend du temps. Et on ne le cache pas. D'où l'intérêt de le lancer en toute connaissance de cause. Je peux juste vous dire que le doc Unisys a raison : ça va s'améliorer grandement dans les versions à venir (parallélisation).

==> Ahhhh ben merci Michael ! Un vous me donnez raison, Deux vous me donnez de l'espoir ! (au fait, je pense vraiment avoir lancé mon rebuild en toute connaissance de cause pour avoir lu auparavant le doc d'unisys et avoir dépiauter tous les posts des forums alfresco et autres google links…)

Enfin oui, le backup à chaud … c'est chaud ! Préférer le backup à froid si possible, en prenant soin de ne pas arréter Alfresco pile à l'heure où il lance ses tâches de maintenance quotidienne (vers 3h ou 4h du matin).

==> C'est vrai qu'il y a sa maintenance de 3h… Et pis j'ai réactivé (après mes déboires de sauvegarde ultra perfectionnée Tina-qui-envoie-les-sauvegardes-en-chine-et-te-propose-un-café-en-attendant) mon bon vieux batch (inspiré largement de celui de David Musser) qui arrête la BDD à 23h pour opérer une sauvegarde… Donc le créneau se raccourcit… Qu'importe, vous me le conseillez froid, je partage votre avis.

Enfin, il me faut FAIRE UNE MISE EN GARDE A L'USAGE DE TOUS LES USERS D'ALFRESCO (je vois Michael qui fronce le sourcil"keskiva dire encore ?) :

J'AI FAIT UNE BOULETTE !!! UNE INSIDIEUSE BOULETTE QUI AURAIT PU ME MENER EN ENFER !!!!

Un jour, je me suis cru intelligent (et fainéant, donc informaticien quoi). J'ai activé la fonction de versionning automatique SUR TOUT le repository !

Comme ça, tout est versionné que je me suis dit ! Bah vi, mais en même temps, j'ai proposé et conseillé l'utilisation de CIFS, pour mes petits utilisateurs débutants (tous quoi dans mon contexte actuel). Et vous savez ce que fait un word qui ouvre un fichier directement en CIFS (enfin les notres y font ça). Ben y sauvegardent ! Et plus souvent qu'à leur tour, passke y a des malins qu'activent la sauvegarde auto de word toutes les 2 minutes !!!

Z'imaginez le nombre de versions créées ??? Z'imaginez la place disque ?

Alors voilà, Michael, Romain, votre avis/ expérience / conseil ? Pour moi, il ne faut activer le versionning auto que sur les docs (voire les espaces) qui le méritent. Pour les autres. pas de versionning auto. Ce sera toujours mieux, même si les gens doivent se faire à ce truc qu'on appelle chech-in/check-out et que j'ai dû dépensé 3 à 4 semaines de ma vie à expliquer aux utilisateurs-gentils-mais-qui-comprennent-pas-du-premier-coup-et-j'avoue-qu'y-peut-y-avoir-confusion…

En conclusion, Alfresco fait partie de ma panoplie des open source indispensables. J'avais crû lire qu'une 3.0 community était prévue fin juillet, mais au regard de l'evolution des dev (cf. lien donné par Michael), ça me semble compromis.
Qu'à cela ne tienne, I'll be patient !

last but not least : Michael, Romain : la 2.9b, je peux la tenter en prod instead of ma 2.1 ?

Encore merci en tout cas.

Greg

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Fri, 18 Jul 2008 18:12:49 GMT

==> Je suis d'accord Michael. N'en jetez plus !

Déformation de participant au forum, je radote !

==> Là, je ne vois pas bien : alf_data est le repository quand vous me parlez de CIFS, NFS, FTP, ou encore WEBDAV qui ne font "qu'exposer" ce repository. Ca je le comprends plutôt bien. Vous pensiez que je confondais ?

Non, oui … disons que je préférais faire une redite dans le doute

Sinon ce serait un peu comme se plaindre parce que nos jolies données sous format texte sont stockées dans un SGBDR sous un format qu'on ne comprend pas et demander à MySQL de tout stocker dans des fichiers ASCII
==> Bon là, j'avoue m'être un peu emballé (pour l'adhérence entre ma donnée et le système, quoique). Mais votre métaphore me fait sourire : ca aurait beau être dans des fichiers ascii, ça ne signifie pas que je le comprendrais mieux 😉

On ne se moque pas de la métaphore, ça m'a pris du temps pour en trouver une bien mauvaise :wink:

Moi, y a un truc que j'aime bien. C'est lightroom. Je ne sais pas si vous connaissez, mais l'idée de ne pas toucher à un fichier (encore qu'on puisse y stocker les méta-données) et stocker les méta-données dans des fichiers xmp à part (oui Michael, je sais qu'on peut manipuler des données xmp dans Alfresco), ben ça j'aime bien. Y a une base de données, soit, qui fait toute la force de lightroom avec ces xmp, n'empêche que les fichiers, jamais, ne sont renommés !

Je ne connais pas … on parle du Lightroom d'Adobe ?

Pour en venir au système de "détricotage", j'avoue ne pas en voir l'intérêt. Je préfère de loin une bonne (donc testée) sauvegarde à un système qui me fait penser à la réinvention d'un … entrepôt de données. Mais je suis peut-être dans le faux
==> Ben non. Z'êtes plutôt convaincant. Je n'en vois pas plus l'intérêt que ça, si ce n'est que ce serait fichtrement génial qu'Alfresco ne touche pas à mes fichiers, qu'il les enrichisse etc… OUI (il le fait excellemment bien, je dois le reconnaître et c'est bien la raison pour laquelle j'avais, il y a 2 ans, réussi à l'imposer comme solution de gestion documentaire à ma direction informatique).

Il n'y touche pas trop, il les renomme à peine :mrgreen:

Mais voilà… On en veut toujours plus, et j'avoue que je râle depuis longtemps sur l'interface graphique pas facile à modifier et pas très ergonomique d'Alfresco (ça change en bien et j'ai adoré Opsoro pour la petite histoire).

Alors vous allez adorer DOCASU qui est encore plus avancé (et utilisé/utilisable en production).

Je profitais de mes déboires pour trouver un nouveau sujet de râle (arrghh) : Pourquoi Alfresco qui ferait po comme mon Lightroom ? Hein ?

Je ne connais pas Lightroom, mais sans doute qu'à cahiers des charges différents, on trouve des solutions différentes.

Bon la question est peut-être un peu benoîte, voire stupide comme ça, mais quand même, ça me chatouille c't'histoire, pas vous (y aura bien quelqu'un pour m'aider !)

Moi ça va merci :wink:

Ensuite oui, reconstruire un index prend du temps. Et on ne le cache pas. D'où l'intérêt de le lancer en toute connaissance de cause. Je peux juste vous dire que le doc Unisys a raison : ça va s'améliorer grandement dans les versions à venir (parallélisation).
==> Ahhhh ben merci Michael ! Un vous me donnez raison, Deux vous me donnez de l'espoir ! (au fait, je pense vraiment avoir lancé mon rebuild en toute connaissance de cause pour avoir lu auparavant le doc d'unisys et avoir dépiauter tous les posts des forums alfresco et autres google links…)

Pas bête ça, changer le nom du forum en "toi qui entre ici, retrouve espoir" :wink:

Enfin oui, le backup à chaud … c'est chaud ! Préférer le backup à froid si possible, en prenant soin de ne pas arréter Alfresco pile à l'heure où il lance ses tâches de maintenance quotidienne (vers 3h ou 4h du matin).
==> C'est vrai qu'il y a sa maintenance de 3h… Et pis j'ai réactivé (après mes déboires de sauvegarde ultra perfectionnée Tina-qui-envoie-les-sauvegardes-en-chine-et-te-propose-un-café-en-attendant) mon bon vieux batch (inspiré largement de celui de David Musser) qui arrête la BDD à 23h pour opérer une sauvegarde… Donc le créneau se raccourcit… Qu'importe, vous me le conseillez froid, je partage votre avis.

J'adore quand on est d'accord avec moi. On gagne un temps fou

Enfin, il me faut FAIRE UNE MISE EN GARDE A L'USAGE DE TOUS LES USERS D'ALFRESCO (je vois Michael qui fronce le sourcil"keskiva dire encore ?) :

Nan, même pas.

J'AI FAIT UNE BOULETTE !!! UNE INSIDIEUSE BOULETTE QUI AURAIT PU ME MENER EN ENFER !!!!

Un jour, je me suis cru intelligent (et fainéant, donc informaticien quoi). J'ai activé la fonction de versionning automatique SUR TOUT le repository !

Comme ça, tout est versionné que je me suis dit ! Bah vi, mais en même temps, j'ai proposé et conseillé l'utilisation de CIFS, pour mes petits utilisateurs débutants (tous quoi dans mon contexte actuel). Et vous savez ce que fait un word qui ouvre un fichier directement en CIFS (enfin les notres y font ça). Ben y sauvegardent ! Et plus souvent qu'à leur tour, passke y a des malins qu'activent la sauvegarde auto de word toutes les 2 minutes !!!

Z'imaginez le nombre de versions créées ??? Z'imaginez la place disque ?

Ouais, très bien même.
Parce que tout le monde passe par cette étape un jour :roll:

Alors voilà, Michael, Romain, votre avis/ expérience / conseil ? Pour moi, il ne faut activer le versionning auto que sur les docs (voire les espaces) qui le méritent. Pour les autres. pas de versionning auto. Ce sera toujours mieux, même si les gens doivent se faire à ce truc qu'on appelle chech-in/check-out et que j'ai dû dépensé 3 à 4 semaines de ma vie à expliquer aux utilisateurs-gentils-mais-qui-comprennent-pas-du-premier-coup-et-j'avoue-qu'y-peut-y-avoir-confusion…

Non, pas de conseils, je suis d'humeur joueuse ce soir, pas conseilleuse (la chaleur sans doute).
Cela dit oui, le versionning doit s'activer au cas par cas (espace par espace, c'est un niveau suffisant) et rarement sur un entrepôt entier.

En conclusion, Alfresco fait partie de ma panoplie des open source indispensables. J'avais crû lire qu'une 3.0 community était prévue fin juillet, mais au regard de l'evolution des dev (cf. lien donné par Michael), ça me semble compromis.
Qu'à cela ne tienne, I'll be patient !

En juillet si tout va bien (et dans tous les cas bientôt), on va voir une 3.0 beta. Mais il y aura ensuite un cycle avec des previews, et tout ce qui sera nécessaire pour chasser les méchants bugs, et être sûr qu'on a fait les bons choix !

last but not least : Michael, Romain : la 2.9b, je peux la tenter en prod instead of ma 2.1 ?

Nan. Définitivement. Restez encore un peu en 2.1. On vous tiendra au courant

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Wed, 20 Aug 2008 14:52:30 GMT

De retour de vacances…

La surprise de la 3.0 beta, Docasu, la réponse sympa de Michael… Que demander de plus ?

Une 3.0 pas bêta 😉

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Wed, 20 Aug 2008 14:57:22 GMT

De retour de vacances…

J'ai le même problème …

Que demander de plus ?
Une 3.0 pas bêta 😉

On y travaille

P.S : Vous avez vérifié le backup ?

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

bessong — Sat, 23 Aug 2008 21:57:33 GMT

Salut Michael !

Pour le backup… oui ! 😉

Pour la version labs 3, je suis réellement impressionné. La vitesse à laquelle Alfresco évolue n'a de cesse de me faire rêver. Comment donc est géré ce projet ?

Vous avez une démarche projet agile ou classique ?

Quelle est la structure de l'organisation des dev ? (Je veux la même ! :cry: )

Greg

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

michaelh — Mon, 25 Aug 2008 15:46:06 GMT

Une démarche projet classique et agile

Pas de solution miracle, juste un nombre de développeurs maintenant très conséquent, tous avec un grand nombre d'années d'expérience.

Si on creuse un peu on se dit que la 3.0 va vite, mais la plateforme SURF découle de l'API webscripts ajoutée il y a un an, qui elle-même découle des API Javascript et Freemarker ajoutées il y a 2 ans, etc …

C'est donc plus une question de cohérence dans les développements et de vision long terme.

Re: [RESOLU] Alfresco 2.1 Redhat 5 PLANTAGE EN PRODUCTION

zomurn — Mon, 30 Mar 2009 09:04:10 GMT

Intéressant tout ça !! j'ai eu EXACTEMENT la même expérience ce WE : HibernateOptimisticLockingFailureException
Ca a causé plein de merde: "java out of memory error" "lucene merge index error" "can't create directory…"
J'ai arrete le job, mais impossible de restorer les index lucene (avec FULL).
En prod, pas le tps de réfléchir, je viens à l'instant de restaurer un backup !