Discussion :

[owuzan]

Bonjour,
Nous utilisons Jodconverter comme API. La conversion de document "rtf" vers "pdf" met une trentaine de seconde.
Ceci se produit sur deux serveurs tournant sur une ditribution Debian Squeeze. Sur des anciens serveurs que nous possédons (Debian Lenny) nous n'avons pas ce type de problème, la conversion se fait quasi-instantanément.
Le démon soffice est bien lancé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ps ax|grep soffice
30100 pts/4    Sl     0:02 /opt/openoffice.org3/program/soffice.bin -headless -accept=socket,host=127.0.0.1,port=8100;urp; -nofirststartwizard

Un appel direct à jodconverter en ligne de commande met une trentaine de seconde à s'éxécuter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

jodconverter -f pdf test.rtf

Ce qui nous fait dire que le problème ne viens pas directement du code java de notre application, surtout que celui-ci a toujours bien fonctionné jusqu'à présent.

Nous aimerions savoir si d'autres personnes ont été confronté à ce type de problème. Nous ne savons pas si celui-ci vient d'une mise-à-jours de Debian ou des versions plus récentes de jodconverter et/ou de soffice.
Merci d'avance.

[tchize_]

premier truc à mesurer, le temps que vous mettez à charger ce fichier dans openoffice.

[owuzan]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$ time soffice test.rtf 
 
real	0m7.379s
user	0m0.060s
sys	0m0.052s

Merci pour la suggestion mais cela ne vient apparemment pas de là (surtout que dans ce simple test, c'est l'ouverture de l'interface graphique de soffice qui est importante). Se pourrait-il qu'il y est un bug dans le mode headless?

[tchize_]

si c'est le cas, vous allez être vite fixé. Retirez le headless dans la commande de lancement du serveur openoffice.

[owuzan]

Après plusieurs tests, le problème persiste, mais nos recherches ont avancé. Petit récapitulatif :

On utilise soffice pour la conversion de document. Celui-ci écoute sur le port 8100 à l'adresse 127.0.0.1.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/lib/openoffice/program/soffice.bin -headless -accept=socket,host=127.0.0.1,port=8100;urp; -nofirststartwizard

La conversion via l'api jodconverter met un temps anormalement élevé (40 secondes).
Durant ce travail de conversion, on observe plusieurs redirections de ports :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ netstat -na | grep 8100
tcp        0      0 127.0.0.1:8100          0.0.0.0:*               LISTEN     
tcp      129      0 127.0.0.1:8100          127.0.0.1:55617         ESTABLISHED
tcp6       0      0 127.0.0.1:55617         127.0.0.1:8100          ESTABLISHED

En passant tout en ipv4, on a le même problème de redirection de port.
Si on travail, hors connexion (non connecté à internet), on a plus ce problème de lenteur.

Il semblerait que le problème ne vienne ni de Jodconverter, ni de soffice. Faudrait-il déplacer cette discussion vers un autre forums plus axé vers les problèmes systèmes type Linux?
Merci

[tchize_]

dans votre capture, je vois juste une connexion établies (visible depuis les deux cotés puisqu'on reste en local) et une socket en attente. Rien de particulier donc.

Par contre, un temps d'attente important quand il y a une connexion internet et sa disparition quand on coupe la connexion indiquerait plutot une méthode qui parse un fichier xml, fichier xml qui a un XSD fournis sous forme d'une URL et qui tente de télécharger la XSD. Regardez dans vos méthodes annexes à la conversion qui manipule du XML, quelqu'un a du oublier d'utiliser un catalogue XSD ou quelque chose de similaire pour se passer d'une connexion internet. Un "snif" de la connexion internet (exemple avec tcpdump) devrais vous indiquer quelle xsd on essaie de télécharger.

[owuzan]

Merci de répondre aussi rapidement. Ce qui nous semblait bizarre, c'était la redirection de port de 8100 vers 55617. Est-ce normal?
L'étude avec tcpdump est judicieuse, mais n'a rien révélé d'anormal. Pour précision, lorsque nous débranchons le cable ethernet physiquement (aucune adresse ip attribué par dhcp), nous ne retrouvons plus ces problèmes de lenteurs.

[tchize_]

ben une connexion établie, c'est toujours

adresse 1: port1 <---> adresse 2 : port 2.

Comme tout est sur la meme machine, vos voyez donc les deux cotés de la socket dans netstat.

Cable débranché = erreur immédiate lors d'une tentative de connexion vers l'extérieur = pas besoin d'attendre un "timeout" pour voir qu'on arrive pas à se connecter au serveur contenant la XSD.

il faudrait faire un enregistrement de votre application avec une machine ayant un accès internet pour chopper la xsd coupable. En effet, sur une machine n'ayant pas d'accès extérieur, vous allez voir juste un tentative d'ouverture d'un port sur un ip, trop fugasse pour le repérer dans un dump tcp. Tandis qu'une communication http complète, ca se rate pas