Accoona: SuperTarget Your Search

Le moteur de recherche Accoona qui a été lancé récemment en Europe, et qui fonctionne en 7 langues dispose d'une fonctionnalité intéressante pour un moteur de recherche, celle de pouvoir affiner une recherche sur le Web, et ce de manière incrémentale.

Ainsi, sur une requête comme "développement logiciel en langage C", Acoona propose d'insister dans la recherche sur les termes: développement, logiciel, langage.

Malheureusement, cette fonctionnalité ne tient pas compte des groupes de mots comptant comme un mot clé et se contente de découper les mots clés un à un en supprimant les mots de liaison.

Il est aussi possible avec Accona de sélectionner selon les "Publishers", c'est à dire la source d'information ou site Web qui contient des pages en rapport avec les mots clés entrés.

De la même façon, Accoona propose après coup de choisir la langue des documents renvoyés par le moteur de recherche ainsi que la localisation géographique.

La recherche incrémentale peut aussi être affinée selon les personnes concernées par les pages (People Search).

Par exemple, avec une recherche comme "linux debian", Accoona trouvera: Linus Torvalds et Richard Stallman.

Cette fonctionnalité ne semble néanmoins pas très pertinente quand elle me donne: Steve Ballmer ou Bill Gates et surtout Harry Potter ou Madonna !

Le moteur de recherche Accoona est disponible en Europe à l'adresse www.accoona.eu

Pas de R&D Google en France !

Google vient d'ouvrir un centre de Recherche et Développement au centre de Munich en Allemagne.

En Europe, Google compte déjà des sites de R&D dans les pays suivants: Suisse, Irlande, Danemark, Pologne, Grande-Bretagne, Suède, Norvège et Russie.

Aussi surprenant (ou pas ...) que cela puisse paraître, Google ne dispose toujours pas d'entités de R&D en France.

Alors ? La France n'attirerait donc pas les talents de R&D en informatique ???

pop3/tcp server failing (looping), service terminated

Alors que je testais un applicatif Java, dont le but était de faire communiquer un serveur mail et un middleware orienté message, je me suis aperçu que le super serveur inetd s’arrêtait rapidement.

Plus possible alors d’accéder au serveur mail via le protocole POP3 avec JavaMail.

La raison du problème ? Le code utilisant JavaMail se connectait en permanence pour vérifier la présence de nouveaux messages sur le serveur mail, et comme aucun message n’était disponible, on recommençait encore et encore et sans timer !

Seulement voilà, inetd n’aime pas les connexions intempestives depuis le même processus, et s’arrête (par défaut) au bout de 40 connexions en une minute. inetd voit ce genre de cinématique comme une attaque.

Au crédit d’inetd: il ne laisse pas faire n’importe quoi !

Au débit de JavaMail, il n’est pas simple par défaut de savoir si des messages nouveaux sont arrivés sur le serveur, et le seul moyen de le faire est d’ouvrir de nouveau le Folder POP3 …

En fait, JavaMail n’y est pour rien, c’est le protocole POP3 qui n’offre aucune possibilité de savoir si de nouveaux messages sont arrivés.

Aussi la méthode hasNewMessages() de la classe javax.mail.Folder renvoie toujours false !

Cette limite de 40 connexions par minute est ancienne et un peu obsolète, vu la puissance actuelle des machines ; néanmoins il est possible de changer ces valeurs par défaut:

* En recompilant inetd après avoir changé les #define appropriés.
* En modifiant la configuration du service qui reçoit trop de connexions.

Pour modifier la configuration du service, on remplacera dans inetd.conf, la ligne correspondant au service pop:

pop-3 stream tcp nowait root /usr/sbin/vm-pop3d vm-pop3d -i

par

pop-3 stream tcp nowait.500 root /usr/sbin/vm-pop3d vm-pop3d -i

pour autoriser par exemple 500 connexions par minute.

Il faut ensuite redémarrer inetd:

/etc/init.d/inetd reload

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Heure d'été, Classe Date, JDK 1.5 et TimeZone

Alors que l'on est passé à l'heure d'été ce week-end, soit UTC+0200 au lieu d'UTC+0100, je me suis aperçu ce matin que le JDK 1.5 de Sun ne me donnait pas (plus en fait !) l'heure correcte ... alors que la machine elle avait bien changé d'heure, comme le confirmait Gnome et la commande date.

En fait, la classe Date de Java était restée à l'ancienne heure, contrairement à moi qui ai vu mon week-end écourté, mais bref.

En effet, Java tient compte du TimeZone, et un simple

new Date();

doit vous donner la date courante et tenir compte du TimeZone, et non vous donner la date GMT définie par nos amis Anglais.

La raison de ce problème est que le JDK 1.5 ne me donnait pas le TimeZone me correspondant. Au lieu d' "Europe/Paris" j'obtenais GMT+0100 soit le TimeZone de la semaine dernière.

TimeZone.getDefault().getID()=GMT+01:00

Pour remédier à ce problème, il suffit soit d'utiliser un JDK plus récent, c'est à dire un JDK 1.6, soit de modifier le TimeZone par programme comme suit:

TimeZone tz = TimeZone.getTimeZone("Europe/Paris");
TimeZone.setDefault(tz);

On peut également modifier la propriété "user.timezone" et lui affecter la valeur "Europe/Paris", par exemple sur la ligne de commande Java, via un -D.

Je n'ai pas testé toutes les versions de JDK 1.5, mais les dernières versions du JDK 1.5 (jdk1.5.0_14 et jdk1.5.0_15) ont toutes deux ce bug sous Linux.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

De l’usage des programmes d’exemple

Un utilisateur m’appelle pour une question sur l’implémentation JMS dans le middleware orienté message sur lequel je travaille.

Il m’envoie un bout de code et me demande ce qui ne va pas dans son code, et pourquoi il perd des messages.

Je me rends compte que comme la majorité des exemples d’appels à un provider JMS que l’on trouve sur le net, sa session est non transactionnelle en AUTO_ACKNOWLEDGE.

Donc, si son applicatif s’arrête entre la réception du message et avant le traitement de ce dernier, le message est “perdu” puisque commité par le queue manager (AUTO_ACKNOWLEDGE !) et non traité par l’application !

Pourquoi est-ce que dès que les développeurs ont 15 lignes de code à écrire, il leur faut un exemple ?

Normalement, c’est leur métier d’écrire des programmes, ils ne devraient pas avoir des sueurs devant une page blanche !

L’exemple n’a rien de mauvais en soi, mais ce que je lui reproche, c’est l’utilisation qui en est faites la plupart du temps: si on prend un exemple pour aller plus vite dans son travail, sans prendre le (peu de) temps nécessaire pour savoir ce que l’exemple fait ou ne fait pas, au final, au lieu de gagner du temps, on en perds !

Et beaucoup plus que ce qu’on pensait gagner initialement.

Utiliser un exemple est une bonne chose, mais pas si on l’utilise comme une boite noire et surtout sans réfléchir.

Après, l’étape suivante, c’est de poster un message sur les forums: “voilà, je fais ça, ça a l’air bon mais ça ne marche pas … Est-ce quelqu’un peut m’aider ?” ….

Enfin, malheureusement, les exemples sont rarement faits pour résoudre précisément votre problème, sinon la vie serait trop belle, et puis il faut lire (un minimum) la Javadoc JMS.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
JavaMail en IMAP avec un serveur Exchange

Java 1.5: Utilisation des imports avec JMS

La facilité en Java consiste à utiliser des imports "génériques" du genre:

import java.util.*;

ou

import javax.jms.*;

.
Autre méthode possible, laisser Eclipse réorganiser les imports du fichier source Java.

Lorsqu'on utilise Java 1.5 sur du code Java écrit pour la version 1.4 voire 1.3 du JDK, on peut rencontrer l'erreur suivante à la compilation:

reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match

En effet, les classes java.util.Queue et javax.jms.Queue existent toutes les deux ... dans le JDK et comme j'ai mis les deux imports, j'obtiens une ambiguité et la compilation échoue (ce n'est pas un warning).

Personnellement, je préfère de loin spécifier au début du fichier source Java l'intégralité des imports dont j'ai besoin. Par exemple, dans un programme d'envoi et de réception de messages JMS:

import javax.jms.QueueConnectionFactory;
import javax.jms.QueueConnection;
import javax.jms.Session;
import javax.jms.QueueSession;
import javax.jms.Queue;
import javax.jms.QueueReceiver;
import javax.jms.QueueSender;
import javax.jms.MessageListener;

import javax.jms.Message;
import javax.jms.MapMessage;

import javax.jms.JMSException;

Comme cela, non seulement je sais exactement quelles classes Java j'utilise mais je vois également en un coup d'oeil que telle classe qui pourrait me poser un problème n'est pas utilisée dans mon implémentation.

Pour une fois, incitons les développeurs à être un peu moins "lazy" que d'habitude :-)

Note: L'erreur "reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match" survient sur le programme d'exemple JMS de Sun TransactedExample.java, qui avait été écrit avant Java 1.5 évidemment.

 Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

10 ans après ...

Presque 10 ans après le premier billet de ce blog, JavaMail en IMAP avec un serveur Exchange, et plusieurs années de moindre activité (voire de plus d'acivité du tout ...), il est temps maintenant de continuer la suite ailleurs.

En effet mon nouveau blog est actif depuis Juin 2013 et s'intitule Exile on Keyboard St.

Comme son nom l'indique, il traitera (encore !) d'informatique et de développement logiciel, toujours avec Linux.

JavaMail en IMAP avec un serveur Exchange

Accéder à un compte IMAP avec JavaMail ne pose à priori pas de problèmes.

J’étais en train de tester un bridge entre un MOM JMS et des serveurs Mails divers et variés, quand je me suis mis à tester sur Exchange, le serveur de Microsoft.

Sur Exchange, surprise à l’ouverture du Folder IMAP, la mailbox n’existe pas !
Ah bon, pourtant, j’ai un user valide et je suis connecté.

La raison de l’erreur dont la stack suit:

Exception occurred: javax.mail.MessagingException: A2 NO There is no replica for that mailbox on this server.;
nested exception is:
com.sun.mail.iap.CommandFailedException: A2 NO There is no replica for that mailbox on this server.
at com.sun.mail.imap.IMAPFolder.doCommand(IMAPFolder.java:2125)
at com.sun.mail.imap.IMAPFolder.exists(IMAPFolder.java:406)
at com.sun.mail.imap.IMAPFolder.checkExists(IMAPFolder.java:280)
at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:779)

est que le serveur Exchange me redirigeait vers un deuxième serveur pour m’authentifier, et utilisait le premier (celui que je lui avais donné à la connexion) pour ouvrir la INBOX.

Manque de chance, la INBOX n’existe (normal) que sur le deuxième serveur (celui que j’ignorais) !

Moralité, si vous rencontrez la belle erreur “There is no replica for that mailbox on this server", pensez à mettre les traces IMAP et regardez si vous ne voyez pas passer un autre nom de serveur ; c’est celui-ci qu’il faudra utiliser.

Les développeurs de chez Microsoft pourraient étoffer le message d’erreur, par exemple: “you’ve been redirected for authentification, please check serveur name” !

Les devéloppeurs ne pensent jamais assez à l’utilisateur final …

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple

Erreurs de débutant en Java: fermer les fichiers !

Les développeurs Java débutants (j'en vois qui ont de l'expérience et qui continuent de faire cette erreur chaque jour ...) considèrent souvent qu'il est inutile de libérer les ressources allouées.

Comme il s'agit de Java et que le Garbage Collector veille, il est trop souvent considéré que la mémoire se libère de façon automatique, ce qui n'est que partiellement vrai.

Une des erreurs courantes consiste à ne pas fermer les fichiers ouverts, que ce soit en lecture ou en écriture.

Considérons la méthode suivante qui consiste à copier un fichier par bloc de 1024 octets sur un autre filesystem:

public static boolean copyTo(File src, File dest, boolean close)
throws IOException {
FileOutputStream out = null;
FileInputStream in = null;
try {
if (!src.exists())
throw new FileNotFoundException(src.getAbsolutePath());
if (dest.exists() || !dest.createNewFile())
return false;
out = new FileOutputStream(dest);
in = new FileInputStream(src);
int len = 1024;
int nread;
byte[] b = new byte[len];
for (;;)
if ( (nread = in.read(b, 0, len)) <= 0) break; else out.write(b, 0, nread); return true; } finally { if (close) { try { out.close(); } catch (IOException ioe) { } try { in.close(); } catch (IOException ioe) { } } } }

Le paramètre close permet de fermer ou non les flux ouverts (input et output).

Si on appelle cette méthode, par exemple 2048 fois avec un nom de fichier de destination qui change et le paramètre close à false, on obtient l'erreur suivante:

java.io.IOException: Too many open files
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:883)
at FileNotClosed.copyTo(FileNotClosed.java:36)
at FileNotClosed.main(FileNotClosed.java:17)

Et on n'arrive qu'à copier 510 fichiers, ce qui veux dire qu'on en a ouvert 2*510 soit 1020 fichiers, parce que le max open files défini par process sur cette machine Linux est de 1024:

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32768
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 32768
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Les autres fichiers ouverts le sont par la JVM elle même.

En conséquence de quoi, il est primordial de fermer TOUS les fichiers ouverts après leur utilisation, et ce de façon systématique dans le bloc finally afin que la fermeture soit faites dans tous les cas.

Evidemment si un System.exit() est appelé, le bloc finally correspondant lui ne le sera pas.

Ce genre d'erreur se voit tous les jours, et dans un serveur d'applications par exemple, cela fait des ravages !

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Un très ancien bug non découvert jusque là

Dans un billet où je tirais à boulets rouges sur le Copier/Coller, je mettais en évidence les inconvénients de cette pratique trop répandue.

Une fois n'est pas coutume, j'ai corrigé la semaine dernière un bug qui date d'au moins 2 ans, sur une implémentation JMS, bug qui n'avait pas été encore découvert car la plupart des utilisateurs d'applications JMS (comme les autres d'ailleurs) utilisent le Copier/Coller à outrance !

Le problème était le suivant.

Si l'on fermait le contexte JNDI juste après les appels aux lookup() JNDI des queue et queue connection factory, les connexions JMS échouaient par la suite !

C'est à dire que les connexions JMS avaient besoin du contexte JNDI pour se connecter au queue manager JMS, ce qui est une erreur.

Si ce bug n'a pas été découvert plus tôt, c'est parce que la majorité des programmes d'exemples JMS ferment le contexte JNDI en même temps que les autres ressources de l'application JMS, et non après les opérations de lookup() JNDI, ce qui serait la manière logique de faire.

Donc, pour une fois, merci au Copier/Coller !

Cela dit, de manière générale, je préconise généralement de ne pas fournir de programmes d'exemples dans les livrables d'un logiciel, car, malgré les avertissements d'usage dans les cartouches d'entête des fichiers, les utilisateurs et programmeurs utilisent trop souvent ces programmes d'exemples comme templates de base à leurs développements.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Microsoft: le ridicule ne tue pas !

Microsoft annonce une version 7.0 d'Internet Explorer prévue pour le quatrième trimestre 2006.

Si la sortie de Microsoft Internet Explorer a le même sort que Windows Vista, il faudra être très patient !

Cette version 7.0 d'Internet Explorer semble très critique ; comprendre elle corrige un certain nombre de failles de sécurité importantes !

Mais le plus fort, c'est que Microsoft prévoit de mettre à la disposition des entreprises un petit logiciel destiné à empêcher l'installation de Microsoft Internet Explorer 7.0 ...

En clair, il faut notifier à Windows Update de mettre le système à jour, excepté Microsoft Internet Explorer.

Là, je me retiens de ne pas tomber de ma chaise !!!

Travaillant dans le développement logiciel depuis bientôt 10 ans, j'en ai vu des vertes et des pas mures, mais des stupidités pareilles .... là, franchement j'ai du mal ...

IBM: Lotus Notes 7.0.1 disponible sous Linux

La version 7.0.1 de Lotus Notes qu'IBM a rendu disponible hier est maintenant portée sous Linux.

Très sensible à l'Open Source, IBM, après l'adoption du format Open Document, est en train de finaliser la future version de Lotus Notes, nom de code Hannover, qui devrait sortir en 2007.

Cette future version de Lotus Notes est basée sur Eclipse, un framework de développement Open Source.