Clustering Jackrabbit 1.5.x with DataStore configuration

Jackrabbit is the reference implementation of JSR-170 : JCR, Java Content Repository.

One day we felt the needs to run a Jackrabbit repository in a clustered environment for reliability. So a JCR runs on two separated servers, backed by the an Oracle db and a NFS shared datastore.

It exists some difficulties to run such architecture, mainly because both JCR nodes (JCR1 and JCR2) do not know each others. So if we insert some content on one node, it takes some time before we can read it on the other node.

In Jackrabbit 1.5.x, Session.refresh do not work correctly, so we need to do some trick to enable cluster (synchronization) features.

First of all, we add a custom ServletFilter which handle the GET (read) request and transform it on a HEAD one (test if the content exists) using apache.commons.HttpClient.

If the return of the query says the content exists, then we run the normal request. If the content do not exists, we way for some arbitrary time and relaunch the HEAD request.

This filter will let enough time to the node to synchronize itself, and then perform the query in the right way.

Other possibilities like HEAD on the current node and then HEAD on a different node should also be possible, but this will require every nodes to know about every other nodes. No the best idea.

One another tricky point is to store all the content to the configured datastore. Be carefull to not rely on a JNDI persistence manager, but be sure to use a subclass of a bundle persistence manager, otherwise you will have some surprise with the size of the database.

Une liste de USER AGENTS parsable

Il est toujours utile d'avoir sous la main une liste de USER AGENTS facilement parsable.

La mienne, qui ne contient que des USER AGENTS ^Mozilla/.* se trouve à l'adresse http://www.noisette.ch/useragents/. Elle est mises-à-jour journalièrement sur la base des navigateurs qui se connectent sur mon serveur, tous sites confondus. Elle va donc suivre l'évolution des numéros de version des Firefox et autres IE...

Cette liste, couplée à la fonction url_get_contents définie antérieurement, permet facilement de disposer d'un USER AGENT pour faire ce qu'il est possible de faire avec un USER AGENT généré :)

Illustration en PHP :

$useragents = explode("\n", url_get_contents('http://www.noisette.ch/useragents/list.txt'));
$useragent = $useragents[rand(0, count($useragents) - 1)];

Gentoo avec Apache2 + PHP5 + Suexec + FastCGI (dynamic)

FastCGI est un concept tout à fait intéressant qui permet, dans le cadre de PHP, d'allier rapidité et sécurité. Il permet conjointement d'avoir la rapidité de mod_php avec la sécurité de PHP/CGI, notemment en terme de droits d'utilisateurs.
Je ne vais pas vous refaire une série de benchmark comme c'est le cas sur beaucoup d'autre site, mais je viens de réaliser un article explicant en détail l'installation, la configuration et surtout les problèmes qu'on peut rencontrer avec la mise en place PHP, FastCGI dynamique et Suexec :

• Configuration de PHP avec FastCGI et Suexec pour Apache2

Système de réécriture d'URL (URL Rewriting)

Les systèmes de réécriture d'URL posent rapidement des problèmes de scalabilité pour un site générant un trafic respectable (genre dès 1000 visiteurs uniques par jour). Je l'ai déjà exprimé dans un précédent article : Mambo 404 SEF, et souhaite maintenant apporter un design de solution.

Une technique relativement simple pour palier à ce problème de VARCHAR non- ou mal -indexable est d'introduire une variable aléatoire dans l'URL, variable à partir de laquelle la vrai URL sera chargée : www.domaine.com/14523623423/news/ma_premiere_news.html
L'important dans cet URL est donc la variable 14523623423, alors que ce qui se situe après n'a aucune importance et peut être modifié à souhait (on remarque aussi ici que cette technique permet rapidement de mettre un place de l'URL flooding, utilisants des URLs de toute sorte pour pointer sur la même page. Attention à ne pas en abuser, car on risque de voir son site se faire bannir des moteurs de recherche).

La requête SQL devient donc

SELECT realurl FROM redirections WHERE urlid = 14523623423

Mieux ça non ? Le problème évoqué ici est en fait global à tout design de base de données : les champs utilisés sans intervention d'un utilisateur dans une condition devraient toujours être de type entier ou un dérivé. Car même si les chaines de caractères sont relativement rapide lors des tests, la réaction à haute charge est très souvent mauvaise...