Nous tentons de faire fonctionner Koha (application web, écrite en Perl)
sous mod_perl.
Comme Koha n'a pas été prévu pour fonctionner en mod_perl, nous utilisons
Apache::Registry, avec la configuration décrite ci-dessous.
Ca fonctionne plutôt bien, sauf pour quelques script (pas tous !)
pour lesquels, au début, cela fonctionne, et les fois suivantes, on semble
avoir perdu les coordonnées de la base de données ou qqc du genre, parce
qu'il affiche des listes vides (ou des formulaires vides) alors que les
paramètres sont bien passés.
* startup.pl contenant :
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use lib qw(home/paul/koha.dev/rel_3_0/); # this line fixe PERL5LIB !
>
> # you can add here what you want.
> # see perl.apache.org for more details.
>
> 1; # don't forget to add it.
* La config Apache générale est :
> <Files *.pl>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> PerlSendHeader On
> Options +ExecCGI
> </Files>
Le problème est constaté sous mandriva aussi bien que sous ubuntu
--
Paul
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) Tue, 12 Dec 2006 17:43:24 +0100, paul POULAIN écrivait (wrote):
Nous tentons de faire fonctionner Koha (application web, écrite en Perl) sous mod_perl.
Comme Koha n'a pas été prévu pour fonctionner en mod_perl, nous uti lisons Apache::Registry, avec la configuration décrite ci-dessous.
Ca fonctionne plutôt bien, sauf pour quelques script (pas tous !) pour lesquels, au début, cela fonctionne, et les fois suivantes, on sem ble avoir perdu les coordonnées de la base de données ou qqc du genre, pa rce qu'il affiche des listes vides (ou des formulaires vides) alors que les paramètres sont bien passés.
Le problème est constaté sous mandriva aussi bien que sous ubuntu
Je ne vois rien en lien avec une base de données donc je ne comprends pas la description de votre problème...
Que disent les logs ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 12 Dec 2006 17:43:24 +0100,
paul POULAIN <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
Nous tentons de faire fonctionner Koha (application web, écrite en Perl)
sous mod_perl.
Comme Koha n'a pas été prévu pour fonctionner en mod_perl, nous uti lisons
Apache::Registry, avec la configuration décrite ci-dessous.
Ca fonctionne plutôt bien, sauf pour quelques script (pas tous !)
pour lesquels, au début, cela fonctionne, et les fois suivantes, on sem ble
avoir perdu les coordonnées de la base de données ou qqc du genre, pa rce
qu'il affiche des listes vides (ou des formulaires vides) alors que les
paramètres sont bien passés.
À (at) Tue, 12 Dec 2006 17:43:24 +0100, paul POULAIN écrivait (wrote):
Nous tentons de faire fonctionner Koha (application web, écrite en Perl) sous mod_perl.
Comme Koha n'a pas été prévu pour fonctionner en mod_perl, nous uti lisons Apache::Registry, avec la configuration décrite ci-dessous.
Ca fonctionne plutôt bien, sauf pour quelques script (pas tous !) pour lesquels, au début, cela fonctionne, et les fois suivantes, on sem ble avoir perdu les coordonnées de la base de données ou qqc du genre, pa rce qu'il affiche des listes vides (ou des formulaires vides) alors que les paramètres sont bien passés.
Le problème est constaté sous mandriva aussi bien que sous ubuntu
Je ne vois rien en lien avec une base de données donc je ne comprends pas la description de votre problème...
Que disent les logs ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
paul POULAIN
Paul Gaborit wrote:
Je ne vois rien en lien avec une base de données donc je ne comprends pas la description de votre problème...
Que disent les logs ?
C'est un peu compliqué à décrire, je suis d'accord, mais je vais essayer de préciser...
Tout d'abord l'URL : http://i18.bureau.paulpoulain.com/cgi-bin/koha/admin/branches.pl (login test/test)
Il y a 2 comportements différents : - la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR, IPT et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'appelle branches. - la page se charge, mais la liste est vide.
Pour continuer à apporter des précisions : - les logs sont tout à fait vides :-( - le problème se pose dans 3 pages sur >200 que compte Koha - ca fonctionne parfaitement sans mod_perl - la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh { $db_driver="mysql"; my $db_name = $context->config("database"); my $db_host = $context->config("hostname"); my $db_user = $context->config("user"); my $db_passwd = $context->config("pass"); my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host", $db_user, $db_passwd); # Koha 3.0 is utf-8, so force utf8 communication between mySQL and koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communications to be in utf8)
$dbh->do("set NAMES 'utf8'"); return $dbh; }
Je précise, histoire de mettre la pression, qu'on est supposé passer en production le 3 janvier, et que sans mod_perl, ça ne tient pas bien la charge du tout (100 utilisateurs) Donc hhheeeeeeeeeelllllllllppppppppppppppp ;-) -- Paul
Paul Gaborit wrote:
Je ne vois rien en lien avec une base de données donc je ne comprends
pas la description de votre problème...
Que disent les logs ?
C'est un peu compliqué à décrire, je suis d'accord, mais je vais essayer de
préciser...
Tout d'abord l'URL :
http://i18.bureau.paulpoulain.com/cgi-bin/koha/admin/branches.pl
(login test/test)
Il y a 2 comportements différents :
- la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR, IPT
et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'appelle
branches.
- la page se charge, mais la liste est vide.
Pour continuer à apporter des précisions :
- les logs sont tout à fait vides :-(
- le problème se pose dans 3 pages sur >200 que compte Koha
- ca fonctionne parfaitement sans mod_perl
- la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh
{
$db_driver="mysql";
my $db_name = $context->config("database");
my $db_host = $context->config("hostname");
my $db_user = $context->config("user");
my $db_passwd = $context->config("pass");
my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host",
$db_user, $db_passwd);
# Koha 3.0 is utf-8, so force utf8 communication between mySQL and
koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communications
to be in utf8)
$dbh->do("set NAMES 'utf8'");
return $dbh;
}
Je précise, histoire de mettre la pression, qu'on est supposé passer en
production le 3 janvier, et que sans mod_perl, ça ne tient pas bien la
charge du tout (100 utilisateurs)
Donc hhheeeeeeeeeelllllllllppppppppppppppp ;-)
--
Paul
Je ne vois rien en lien avec une base de données donc je ne comprends pas la description de votre problème...
Que disent les logs ?
C'est un peu compliqué à décrire, je suis d'accord, mais je vais essayer de préciser...
Tout d'abord l'URL : http://i18.bureau.paulpoulain.com/cgi-bin/koha/admin/branches.pl (login test/test)
Il y a 2 comportements différents : - la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR, IPT et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'appelle branches. - la page se charge, mais la liste est vide.
Pour continuer à apporter des précisions : - les logs sont tout à fait vides :-( - le problème se pose dans 3 pages sur >200 que compte Koha - ca fonctionne parfaitement sans mod_perl - la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh { $db_driver="mysql"; my $db_name = $context->config("database"); my $db_host = $context->config("hostname"); my $db_user = $context->config("user"); my $db_passwd = $context->config("pass"); my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host", $db_user, $db_passwd); # Koha 3.0 is utf-8, so force utf8 communication between mySQL and koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communications to be in utf8)
$dbh->do("set NAMES 'utf8'"); return $dbh; }
Je précise, histoire de mettre la pression, qu'on est supposé passer en production le 3 janvier, et que sans mod_perl, ça ne tient pas bien la charge du tout (100 utilisateurs) Donc hhheeeeeeeeeelllllllllppppppppppppppp ;-) -- Paul
paul POULAIN
Au final, c'était pas un pb DBI, mais un pb HTML::Template. html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl my $template= template->new(...); sub dothis { $template->param(param => 'XXX'); } if ($qqc) { dothis(); }
Si on passe le template en paramètre à dothis, ca marche parfaitement. (d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureuse & source de pb à la maintenance : on met une fonction au milieu d'un script) -- Paul
Au final, c'était pas un pb DBI, mais un pb HTML::Template.
html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl
my $template= template->new(...);
sub dothis {
$template->param(param => 'XXX');
}
if ($qqc) {
dothis();
}
Si on passe le template en paramètre à dothis, ca marche parfaitement.
(d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureuse &
source de pb à la maintenance : on met une fonction au milieu d'un script)
--
Paul
Au final, c'était pas un pb DBI, mais un pb HTML::Template. html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl my $template= template->new(...); sub dothis { $template->param(param => 'XXX'); } if ($qqc) { dothis(); }
Si on passe le template en paramètre à dothis, ca marche parfaitement. (d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureuse & source de pb à la maintenance : on met une fonction au milieu d'un script) -- Paul
Paul Gaborit
À (at) Wed, 13 Dec 2006 09:26:01 +0100, paul POULAIN écrivait (wrote):
Il y a 2 comportements différents : - la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR , IPT et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'ap pelle branches. - la page se charge, mais la liste est vide.
Je vois plusieurs causes possibles dont :
Apache est multi-thread et/ou multi-processus, on peut donc supposer que différents threads et/ou processus donnent des résultats différents.
mod_perl autorise les variables persistantes et c'est peut-être une valeur persistante qui provoque ce changement de comportement.
Pour tenter de séparer les deux cas, on peut configurer Apache pour qu'il ne crée qu'une seule instance (thread et/ou processus). Si le bug continue à se manifester, c'est qu'on est dans la seconde situation.
Pour continuer à apporter des précisions : - les logs sont tout à fait vides :-(
Donc Apache et mod_perl sont toujours contents : ils trouvent tous les scripts, tous les modules et la connexion à la base s'effectue toujours bien.
- le problème se pose dans 3 pages sur >200 que compte Koha
Ce sont toujours les mêmes pages qui posent problèmes ? Dans ce cas, il faut rechercher ce qu'elles ont en commun et que n'ont pas les autres. De plus, cela ne milite pas pour un problème entre les instances d'Apache mis à part sur un paramètre spécifique à ces 3 pages.
- ca fonctionne parfaitement sans mod_perl
Ça, ce n'est malheureusement pas un critère suffisant de réussite. L'inverse est un critère suffisant d'échec (un peu comme la preuve par neuf).
- la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh { $db_driver="mysql"; my $db_name = $context->config("database"); my $db_host = $context->config("hostname"); my $db_user = $context->config("user"); my $db_passwd = $context->config("pass"); my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host", $db_user, $db_passwd); # Koha 3.0 is utf-8, so force utf8 communication between mySQL and koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communicatio ns to be in utf8)
$dbh->do("set NAMES 'utf8'"); return $dbh; }
Cette initialisation de la connexion se fait normalement dans chaque instance d'Apache et persiste d'une requête à l'autre. Est-ce le cas ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Dec 2006 09:26:01 +0100,
paul POULAIN <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
Il y a 2 comportements différents :
- la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR , IPT
et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'ap pelle
branches.
- la page se charge, mais la liste est vide.
Je vois plusieurs causes possibles dont :
Apache est multi-thread et/ou multi-processus, on peut donc supposer
que différents threads et/ou processus donnent des résultats
différents.
mod_perl autorise les variables persistantes et c'est peut-être une
valeur persistante qui provoque ce changement de comportement.
Pour tenter de séparer les deux cas, on peut configurer Apache pour
qu'il ne crée qu'une seule instance (thread et/ou processus). Si le
bug continue à se manifester, c'est qu'on est dans la seconde
situation.
Pour continuer à apporter des précisions :
- les logs sont tout à fait vides :-(
Donc Apache et mod_perl sont toujours contents : ils trouvent tous les
scripts, tous les modules et la connexion à la base s'effectue
toujours bien.
- le problème se pose dans 3 pages sur >200 que compte Koha
Ce sont toujours les mêmes pages qui posent problèmes ? Dans ce cas,
il faut rechercher ce qu'elles ont en commun et que n'ont pas les
autres. De plus, cela ne milite pas pour un problème entre les
instances d'Apache mis à part sur un paramètre spécifique à ces 3
pages.
- ca fonctionne parfaitement sans mod_perl
Ça, ce n'est malheureusement pas un critère suffisant de réussite.
L'inverse est un critère suffisant d'échec (un peu comme la preuve par
neuf).
- la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh
{
$db_driver="mysql";
my $db_name = $context->config("database");
my $db_host = $context->config("hostname");
my $db_user = $context->config("user");
my $db_passwd = $context->config("pass");
my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host",
$db_user, $db_passwd);
# Koha 3.0 is utf-8, so force utf8 communication between mySQL and
koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communicatio ns
to be in utf8)
$dbh->do("set NAMES 'utf8'");
return $dbh;
}
Cette initialisation de la connexion se fait normalement dans chaque
instance d'Apache et persiste d'une requête à l'autre. Est-ce le cas ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Dec 2006 09:26:01 +0100, paul POULAIN écrivait (wrote):
Il y a 2 comportements différents : - la page est bien chargée : il y a 3 lignes avec les 3 sites (code CPR , IPT et X) Ces 3 sites sont récupérés en lisant une table mySQL qui s'ap pelle branches. - la page se charge, mais la liste est vide.
Je vois plusieurs causes possibles dont :
Apache est multi-thread et/ou multi-processus, on peut donc supposer que différents threads et/ou processus donnent des résultats différents.
mod_perl autorise les variables persistantes et c'est peut-être une valeur persistante qui provoque ce changement de comportement.
Pour tenter de séparer les deux cas, on peut configurer Apache pour qu'il ne crée qu'une seule instance (thread et/ou processus). Si le bug continue à se manifester, c'est qu'on est dans la seconde situation.
Pour continuer à apporter des précisions : - les logs sont tout à fait vides :-(
Donc Apache et mod_perl sont toujours contents : ils trouvent tous les scripts, tous les modules et la connexion à la base s'effectue toujours bien.
- le problème se pose dans 3 pages sur >200 que compte Koha
Ce sont toujours les mêmes pages qui posent problèmes ? Dans ce cas, il faut rechercher ce qu'elles ont en commun et que n'ont pas les autres. De plus, cela ne milite pas pour un problème entre les instances d'Apache mis à part sur un paramètre spécifique à ces 3 pages.
- ca fonctionne parfaitement sans mod_perl
Ça, ce n'est malheureusement pas un critère suffisant de réussite. L'inverse est un critère suffisant d'échec (un peu comme la preuve par neuf).
- la BD est ouverte avec un package spécifique (Context.pm) :
sub _new_dbh { $db_driver="mysql"; my $db_name = $context->config("database"); my $db_host = $context->config("hostname"); my $db_user = $context->config("user"); my $db_passwd = $context->config("pass"); my $dbh= DBI->connect("DBI:$db_driver:$db_name:$db_host", $db_user, $db_passwd); # Koha 3.0 is utf-8, so force utf8 communication between mySQL and koha, whatever the mysql default config.
# this is better than modifying my.cnf (and forcing all communicatio ns to be in utf8)
$dbh->do("set NAMES 'utf8'"); return $dbh; }
Cette initialisation de la connexion se fait normalement dans chaque instance d'Apache et persiste d'une requête à l'autre. Est-ce le cas ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Paul Gaborit
À (at) Wed, 13 Dec 2006 11:18:17 +0100, paul POULAIN écrivait (wrote):
Au final, c'était pas un pb DBI, mais un pb HTML::Template. html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl my $template= template->new(...); sub dothis { $template->param(param => 'XXX'); } if ($qqc) { dothis(); }
Si on passe le template en paramètre à dothis, ca marche parfaitement. (d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureus e & source de pb à la maintenance : on met une fonction au milieu d'un scri pt)
Une variable globale ! Beurk !
Les variables globales (mal gérées) sont sources de problèmes... particulièrement avec mod_perl.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Dec 2006 11:18:17 +0100,
paul POULAIN <paul.poulain_nospam@free.fr.invalid> écrivait (wrote):
Au final, c'était pas un pb DBI, mais un pb HTML::Template.
html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl
my $template= template->new(...);
sub dothis {
$template->param(param => 'XXX');
}
if ($qqc) {
dothis();
}
Si on passe le template en paramètre à dothis, ca marche parfaitement.
(d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureus e &
source de pb à la maintenance : on met une fonction au milieu d'un scri pt)
Une variable globale ! Beurk !
Les variables globales (mal gérées) sont sources de problèmes...
particulièrement avec mod_perl.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 13 Dec 2006 11:18:17 +0100, paul POULAIN écrivait (wrote):
Au final, c'était pas un pb DBI, mais un pb HTML::Template. html::template n'aime PAS du tout (en mod_perl) la construction suivante :
#! /usr/bin/perl my $template= template->new(...); sub dothis { $template->param(param => 'XXX'); } if ($qqc) { dothis(); }
Si on passe le template en paramètre à dothis, ca marche parfaitement. (d'ailleurs, la syntaxe qui ne marche pas ne me semble pas bien rigoureus e & source de pb à la maintenance : on met une fonction au milieu d'un scri pt)
Une variable globale ! Beurk !
Les variables globales (mal gérées) sont sources de problèmes... particulièrement avec mod_perl.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
