Meilleure architecture

  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:a71a1990bcb22a0e4461b1d6fa48154f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,</p>\n<p>Je travaille maintenant depuis plusieurs semaines sur la mise en place de ORI<br />\nOAI. La solution de départ qui a été adopté est de mettre en place un<br />\nmodule sur chaque serveur virtuel différent. Donc un module par serveur<br />\nvirtuel. jusque là tout fonctionne. Ensuite j\'ai installé un frontal apache<br />\npar serveur. Et j\'ai laissé l\'accès des différents modules à tout le monde<br />\nvia le port 80.</p>\n<p>Je me suis rendu compte que je rencontrais beaucoup de problèmes :<br />\n- Des moissons qui fonctionnent aléatoirement<br />\n- Dans le module Search ; Impossible d\'accéder à la fiche</p>\n<p>J\'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.</p>\n<p>Quelle est la meilleure architecture ? Faut-il restreindre l\'accès à certains<br />\nmodules ? Par exemple le Workflow et le Search ouvert à tous et les autres<br />\nmodules ouvert à certaines personnes seulement ?</p>\n<p>Merci d\'avance.<br />\n--<br />\nCe message a\n</div>\n', created = 1507747932, expire = 1507834332, headers = '', serialized = 0 WHERE cid = '4:a71a1990bcb22a0e4461b1d6fa48154f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:1bf902dbd0f5ed886d3dfcc049d2cbec' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\"><!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n<html>\n<head>\n <meta content=\"text/html;charset=UTF-8\" http-equiv=\"Content-Type\">\n <title></title>\n</head>\n<body bgcolor=\"#ffffff\" text=\"#000000\">\n<font size=\"-1\"><font face=\"Verdana\">Bonjour,<br>\n<br>\nDans la config de commons-parameters.properties, faites-vous\ncommuniquer les modules ensemble par le port 80 ?<br>\nJe vous conseille de laisser les ports TOMCAT pour les propriétés\nsuivantes:<br>\n<br>\nPORT_INDEXING=8182<br>\nPORT_VOCABULARY=8183<br>\n<br>\nLes autres modules appelleront donc indexing et vocabulary sans passer\npar le frontal.<br>\n<br>\nYohan<br>\n<br>\n</font></font><br>\nJulien a écrit :\n<div class=\"emailFilter_Toggle\"><div class=\"emailFilter_Author_0\"><blockquote>\n <pre wrap=\"\">Bonjour,\n\nJe travaille maintenant depuis plusieurs semaines sur la mise en place de ORI\nOAI. La solution de départ qui a été adopté est de mettre en place un\nmodule sur chaque serveur virtuel différent. Donc un module par serveur\nvirtuel. jusque là tout fonctionne. Ensuite j\'ai installé un frontal apache\npar serveur. Et j\'ai laissé l\'accès des différents modules à tout le monde\nvia le port 80.\n\nJe me suis rendu compte que je rencontrais beaucoup de problèmes :\n- Des moissons qui fonctionnent aléatoirement\n- Dans le module Search ; Impossible d\'accéder à la fiche\n\nJ\'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.\n\nQuelle est la meilleure architecture ? Faut-il restreindre l\'accès à certains\nmodules ? Par exemple le Workflow et le Search ouvert à tous et les autres\nmodules ouvert à certaines personnes seulement ?\n\nMerci d\'avance.\n </pre>\n</blockquote></div></div>\n</body>\n<br />-- \n<br />Ce message a </div>', created = 1507747934, expire = 1507834334, headers = '', serialized = 0 WHERE cid = '4:1bf902dbd0f5ed886d3dfcc049d2cbec' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:1f401fe83057c0af3eac5397e245b696' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
  • user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,<br />\nJe n\'avais pas répondu la semaine dernière.<br />\nAutant il parait confortable d\'avoir un Serveur Tomcat par<br />\nApplication/Module ORI-OAI, autant ici un serveur virtuel par module<br />\nORI-OAI me parait très lourd au niveau gestion de l\'ensemble.<br />\nJe vous conseillerais donc d\'avoir sur un seul serveur l\'ensemble de vos<br />\ntomcat (un par module).<br />\nEnsuite vous avez un unique frontal Apache (avec mod jk ou proxy ajp)<br />\ndonnant accès aux modules vis à vis des utilisateurs internautes.<br />\nComme le suggère Yohan, la communication entre Tomcat est à faire<br />\ndirectement (sans passer par le frontal Apache).<br />\nVincent.</p>\n<p>Yohan Colmant wrote:<br />\n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\"><p>> Bonjour,<br />\n><br />\n> Dans la config de commons-parameters.properties, faites-vous<br />\n> communiquer les modules ensemble par le port 80 ?<br />\n> Je vous conseille de laisser les ports TOMCAT pour les propriétés<br />\n> suivantes:<br />\n><br />\n> PORT_INDEXING=8182<br />\n> PORT_VOCABULARY=8183<br />\n><br />\n> Les autres modules appelleront donc indexing et vocabulary sans passer<br />\n> par le frontal.<br />\n><br />\n> Yohan<br />\n><br />\n><br />\n> Julien a écrit :</p></blockquote>\n<blockquote class=\"emailFilter_Author_1\"><p>>> Bonjour,<br />\n>><br />\n>> Je travaille maintenant depuis plusieurs semaines sur la mise en place de ORI<br />\n>> OAI. La solution de départ qui a été adopté est de mettre en place un<br />\n>> module sur chaque serveur virtuel différent. Donc un module par serveur<br />\n>> virtuel. jusque là tout fonctionne. Ensuite j\'ai installé un frontal apache<br />\n>> par serveur. Et j\'ai laissé l\'accès des différents modules à tout le monde<br />\n>> via le port 80.<br />\n>><br />\n>> Je me suis rendu compte que je rencontrais beaucoup de problèmes :<br />\n>> - Des moissons qui fonctionnent aléatoirement<br />\n>> - Dans le module Search ; Impossible d\'accéder à la fiche<br />\n>><br />\n>> J\'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.<br />\n>><br />\n>> Quelle est la meilleure architecture ? Faut-il restreindre l\'accès à certains<br />\n>> modules ? Par exemple le Workflow et le Search ouvert à tous et les autres<br />\n>> modules ouvert à certaines personnes seulement ?<br />\n>><br />\n>> Merci d\'avance.<br />\n>> </p></blockquote>\n<blockquote class=\"emailFilter_Author_0\"><p>><br />\n> --<br />\n> Ce message a �t� v�rifi� par<br />\n> pour des virus ou des polluriels et rien de<br />\n> suspect n\'a �t� trouv�. </div>\n</blockquote>\n<p>--<br />\nCe message a\n</div>\n', created = 1507747934, expire = 1507834334, headers = '', serialized = 0 WHERE cid = '4:1f401fe83057c0af3eac5397e245b696' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
3 messages / 0 nouveaux
Sujet clos
Dernière contribution
3 mars 2009 - 10:03am
#1
julientroubat
Meilleure architecture
Bonjour,

Je travaille maintenant depuis plusieurs semaines sur la mise en place de ORI
OAI. La solution de départ qui a été adopté est de mettre en place un
module sur chaque serveur virtuel différent. Donc un module par serveur
virtuel. jusque là tout fonctionne. Ensuite j'ai installé un frontal apache
par serveur. Et j'ai laissé l'accès des différents modules à tout le monde
via le port 80.

Je me suis rendu compte que je rencontrais beaucoup de problèmes :
- Des moissons qui fonctionnent aléatoirement
- Dans le module Search ; Impossible d'accéder à la fiche

J'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.

Quelle est la meilleure architecture ? Faut-il restreindre l'accès à certains
modules ? Par exemple le Workflow et le Search ouvert à tous et les autres
modules ouvert à certaines personnes seulement ?

Merci d'avance.
--
Ce message a

Haut
Étiquettes:
9 mars 2009 - 8:22am
#2
Yohan Colmant
Bonjour,

Dans la config de commons-parameters.properties, faites-vous communiquer les modules ensemble par le port 80 ?
Je vous conseille de laisser les ports TOMCAT pour les propriétés suivantes:

PORT_INDEXING=8182
PORT_VOCABULARY=8183

Les autres modules appelleront donc indexing et vocabulary sans passer par le frontal.

Yohan


Julien a écrit : 
Bonjour,

Je travaille maintenant depuis plusieurs semaines sur la mise en place de ORI
OAI. La solution de départ qui a été adopté est de mettre en place un
module sur chaque serveur virtuel différent. Donc un module par serveur
virtuel. jusque là tout fonctionne. Ensuite j'ai installé un frontal apache
par serveur. Et j'ai laissé l'accès des différents modules à tout le monde
via le port 80.

Je me suis rendu compte que je rencontrais beaucoup de problèmes :
- Des moissons qui fonctionnent aléatoirement
- Dans le module Search ; Impossible d'accéder à la fiche

J'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.

Quelle est la meilleure architecture ? Faut-il restreindre l'accès à certains
modules ? Par exemple le Workflow et le Search ouvert à tous et les autres
modules ouvert à certaines personnes seulement ?

Merci d'avance.

--
Ce message a
Haut
9 mars 2009 - 9:19am
(Répondre à #2) #3
vincentbonamy
Bonjour,
Je n'avais pas répondu la semaine dernière.
Autant il parait confortable d'avoir un Serveur Tomcat par
Application/Module ORI-OAI, autant ici un serveur virtuel par module
ORI-OAI me parait très lourd au niveau gestion de l'ensemble.
Je vous conseillerais donc d'avoir sur un seul serveur l'ensemble de vos
tomcat (un par module).
Ensuite vous avez un unique frontal Apache (avec mod jk ou proxy ajp)
donnant accès aux modules vis à vis des utilisateurs internautes.
Comme le suggère Yohan, la communication entre Tomcat est à faire
directement (sans passer par le frontal Apache).
Vincent.

Yohan Colmant wrote:

> Bonjour,
>
> Dans la config de commons-parameters.properties, faites-vous
> communiquer les modules ensemble par le port 80 ?
> Je vous conseille de laisser les ports TOMCAT pour les propriétés
> suivantes:
>
> PORT_INDEXING=8182
> PORT_VOCABULARY=8183
>
> Les autres modules appelleront donc indexing et vocabulary sans passer
> par le frontal.
>
> Yohan
>
>
> Julien a écrit :

>> Bonjour,
>>
>> Je travaille maintenant depuis plusieurs semaines sur la mise en place de ORI
>> OAI. La solution de départ qui a été adopté est de mettre en place un
>> module sur chaque serveur virtuel différent. Donc un module par serveur
>> virtuel. jusque là tout fonctionne. Ensuite j'ai installé un frontal apache
>> par serveur. Et j'ai laissé l'accès des différents modules à tout le monde
>> via le port 80.
>>
>> Je me suis rendu compte que je rencontrais beaucoup de problèmes :
>> - Des moissons qui fonctionnent aléatoirement
>> - Dans le module Search ; Impossible d'accéder à la fiche
>>
>> J'ai donc besoin de conseil pour éviter de refaire le travail plusieurs fois.
>>
>> Quelle est la meilleure architecture ? Faut-il restreindre l'accès à certains
>> modules ? Par exemple le Workflow et le Search ouvert à tous et les autres
>> modules ouvert à certaines personnes seulement ?
>>
>> Merci d'avance.
>>

>
> --
> Ce message a �t� v�rifi� par
> pour des virus ou des polluriels et rien de
> suspect n'a �t� trouv�.

--
Ce message a

Haut

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur « Enregistrer les paramètres » pour activer vos changements.
Sujet clos
‹ Sujet précédent : quelques questions sur le module d'indexation Sujet suivant : modification configIndexing.xml du module d'indexation ›