WollMux Seriendruck als PDF-Ausgabe läuft instabil

[chrlutz]

From AKaw...@gmail.com on April 20, 2012 13:23:08

Welche Schritte sind nötig, um das Problem zu reproduzieren? 1.WollMux Seriendruck aufrufen und Gesamt-PDF erzeugen lassen Was ist das erwartete Ergebnis? Was passiert stattdessen? 1.Die Funktion Drucke (PDF) stürzt nach rund 100, 200 oder 500 Teildokumenten (3-seitig) ab, gelegentlich läuft sie auch durch.
2. Ich habe direkt im Anschluß an den Absturz (kein PC-Neutstart, keine Bereinigung der TEMP-ordner) die gleichen Dateien zur Erstellung einer Gesamt-ODT-Datei benutzt(1060 Datensätze).
Dies lief fehlerfrei durch. Der odt-Zweig zeigt sich insgesamt als sehr stabil.

Welche Version des WollMux wurde verwendet?

WollMux 12.3rev2002

OpenOffice.org 3.2.1
OOO320m19 (Build:9505)
LHM 110517001

Windows XP SP3 Bitte weitere Informationen hier angeben: Jeder Absturz hinterlässt zudem einige Hundert Temporäre PDF-dateien im Ordner (User)\Lokale Einstellungen\Temp

Original issue: http://code.google.com/p/wollmux/issues/detail?id=15

[chrlutz]

From chrl...@gmail.com on May 02, 2012 00:26:57

Gibt es im Fehlerfall irgend welche Meldungen in der wollmux.log? Beim Pdf-Druck durchläuft der WollMux die Fortschrittsanzeige zwei mal (pdfs erzeugen und pdfs mergen). In welchem Schritt bricht er ab? Falls der Abbruch im zweiten Schritt erfolgt könnte es evtl. helfen den Java-Heap zu in OOo zu vergrößern: Extras->Optionen//Java, dann die aktuelle jvm auywählen und bearbeiten. Im Feld "Java-Start-Parameter" den Wert "-Xmx128m" oder "-Xmx256m" eintragen und auf "zuweisen" klicken.

Bitte Rückmeldung ob das hilft. Wir können uns dann darüber unterhalten, wie man eine solche Konfiguration am besten automatisiert verteilt (ist schwieriger).

[chrlutz]

From AKaw...@gmail.com on May 03, 2012 07:18:22

Leider scheint meine Antwort aus der googlemail nicht korrekt eingegangen zu sein...
Hier meine Antwort von gestern:
Der Abbruch erfolgt im 1 Teil der Verarbeitung, also beim pdf erzeugen. Das Statusfenster verabschiedet sich während des Hochzählens der Datensätze einfach sang und klanglos. Der Absturzpunkt ist unbestimmt mal bei 40, 200 oder 900 von 1000 Datensätzen. Im WollMuxlog findet sich nichts auffälliges:

2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='#DS', value='977')
2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='#SB', value='977')
2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='BVNAME', value='Maier-1728')
(...)
2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='ASTR', value='Basler Landstraße -17421')
2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='#DS', value='978')
2012-05-02 11:04:15 DEBUG(WollMuxEventHandler:334): Process WollMuxEvent OnSetFormValue(#-789844562, id='#SB', value='978')
(Hier endet das Log - Mitten in der Verarbeitung)

Im einem Fall war ich schon fast mit dem PDF erzeugen durch und trotz eines Absturzes schien der merge anzulaufen und brachte mal eine Fehlermeldung auf den Bildschirm.
Den Parameter "-Xmx256m" habe ich probiert, aber ohne Erfolg (er war ja eher für den zweiten Schritt gedacht)
Was kann ich weiter tun?

Fehler beim PDF-Druck
Beim Drucken in das PDF-Gesamtdokument in ein Fehler aufgetreten.

com.sun.star.task.errorcodeioexception:
com.sun.star.bridges.jni_uno.jni_proxy.dispatch_call(native method)
com.sun.star.bridges.jni_uno.jni_proxy.invoke(jni_proxy.java:175)
$proxy89.storetourl(unkown source)
de.muenchen.allg.d101.pdfmailmerge.mailmergeoutput(pdfmailmerge.java:332)
sun.reflect.generatemethodaccessor4.invoke(unknown source)
sun.reflect.delegatingmethodaccessorimpl.invoke(unknown source)
de.muenchen.allg.itd51.wollmux.func.externalfunction.invoke(externalfunction.java:228)
de.muenchen.allg.itd51.wollmux.func.printfunction$1.run(printfunction.java:101)
java.lang.thread.run(unknown source)

[chrlutz]

From chrl...@gmail.com on May 10, 2012 23:13:40

Abbrüche im ersten Teil habe ich in der LHM-Zeit auch manchmal beobachtet. In der Regel war dann das asynchronous Finalizer-Problem von OpenOffice für den Absturz verantwortlich (das aber glaube ich mit den LHM-Officebuilds reduziert werden konnte). Kannst du bitte mal schauen, ob im Arbeitsverzeichnis des Benutzers eine hserrXXX.pid-Datei erzeugt wird? Diese bitte hier anhängen.

[chrlutz]

From AKaw...@gmail.com on May 11, 2012 01:24:52

Ja, die hs_err_pid3200.log wurde nach rund 70 von 1070 erzeugt. Ich arbeite derzeit auf einem LHM-Build:
OpenOffice.org 3.2.1
OOO320m19 (Build:9505)
LHM 110517001

Attachment: hs_err_pid3200.log

[chrlutz]

From chrl...@gmail.com on May 11, 2012 09:54:21

Bingo! Der ominöse AsynchronousFinalizer hat auch hier zugeschlagen. Leider ist OpenOffice hier nicht sonderlich Thread-safe. Wir konnten diesbezüglich auch schon beobachten, dass der Seriendruck auf langsamen single CPU-Prozessoren stabiler lief als auf schnellen Mehrkernern.

Die Ursache muss OpenOffice-seitig gelöst werden. Vielleicht kann Herr Ertsey hierzu noch wertvollen Input liefern. Ich habe jedenfalls im Moment leider keine Idee was man hier WollMux-seitig beitragen kann um das Problem weiter zu entschärfen.

Soweit ich mich erinnern kann, kann man das OOo-Problem auch ohne WollMux mit einem kleinen Makro reproduzieren, das wiederholt ohne Pause einen PDF-Export auf ein Textdokument ausführt. Vielleicht existiert das Makro noch irgendwo in der LHM? Das könnte dann vielleicht dabei helfen, eine Issue seitens OpenOffice/LibreOffice zu eröffnen (wenn es das nicht eh schon längst gibt - das weiß ich aber gerade nicht)

[chrlutz]

From AKaw...@gmail.com on May 14, 2012 00:43:57

Ich habe Herrn Ertsey direkt per Mail kontaktiert, da ich nicht weis, wie regelmäßig er in den Tracker schaut.

[chrlutz]

From eymux2...@gmail.com on May 14, 2012 01:32:27

Ich habe vor einiger Zeit auf der LibreOffice-Mailingliste mit einem Entwickler über den AsynchronousFinalizer-Absturz gesprochen.

Kurz gesagt: Es handelt sich um ein Multithreading-Problem und es gibt keine einfache Lösung dafür. Tatsächlich müsste man weite Teile von OOo/LO umschreiben, um den Fehler zu beheben. So weit ich weiß, wird daran auch gearbeitet, aber wie lange das dauert, weiß kein Mensch.
Als Workaround wurde mir ein sehr schmutziger Hack vorgeschlagen, den ich auch als Patch für unsere OOo-Version umgesetzt habe. Der Patch funktioniert auch so weit es den Seriendruck betrifft. Er ist aber nicht umfangreich getestet. Und weil unsere Testressourcen begrenzt sind, ist der Patch auch noch nicht im Einsatz.

Ich werde den Patch anhängen, falls jemand interessiert ist.

[chrlutz]

From eymux2...@gmail.com on May 14, 2012 01:39:37

https://issues.apache.org/ooo/show_bug.cgi?id=105557

Attachment: hack_105557.patch

[sikelerd]

Die Option: Gesamtdokument (PDF) wird nicht mehr angeboten. Stattdessen soll

• Gesamtdokument (ODT) mit anschließendem export nach PDF
• oder direkt Drucken mit einem PDF-Drucker
  verwendet werden.