Temps de conversion de document PDF anormalement élevé

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:

---

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:

---

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.

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

Code:

---

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?

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

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:

---

/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:

---

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

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.

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.

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 :D