Ich habe kürzlich ein neues Notebook bekommen und wegen eines anderen Problems entschieden, nicht einfach das alte Notes-Daten-Verzeichnis zu übernehmen, sondern neu anzufangen. Ich habe den 32-bit Notes-Client/Domino Administrator/Designer-Client in der Version 12.0.2 FP1 deutsch installiert.
Etwas später ist mir bei der lokalen Replik meines Mail-Archivs aufgefallen, dass es keinen Volltextindex gab. Ich dachte, ich hätte ihn angelegt gehabt. Bei einer rund 17 GB großen Datenbank kann das natürlich auch etwas dauern. Zur Sicherheit habe ich ihn neu angelegt und den Notes-Client lange laufen lassen.
Am nächsten Tag war der Volltextindex immer noch nicht wirklich da. Das Unterverzeichnis wurde angelegt, war aber mit 6 MB unerwartet klein. Neue Runde, neues Glück..
Aber der Volltext-Index wurde einfach nicht erstellt. Ein paar andere lokale Datenbanken hatten aber funktionierende Volltextindexe?!
Seit Notes 10 hat HCL Apache Tika als Konvertierer für Dateianhänge neu in den Notes-Client (und im Domino-Server) eingebaut und damit das in die Jahre gekommene KeyView ersetzt. Wenn ein Volltextindex mit der Option "Konvertierungsfilter für unterstützte Dateien verwenden (genauere Suche)" erstellt oder aktualisiert wird, wird Apache Tika in Form eines lokalen Servers als Unterprozess des Notes-Clients bzw. des Domino-Servers gestartet. Update, Updall oder der Agent Manager (je nachdem, wer das gerade veranlasst hat) gibt den zu indexierenden Dateianhang per HTTP-Request an den Tika-Server, der dann seine Arbeit tut. Bekommt er ca. 30 Sekunden keine Anfragen mehr, fährt sich der Server herunter und wird beim nächsten Bedarf einfach wieder gestartet.
Ich habe bei mir mal mit dem Process Explorer geschaut, aber da war kein Tika-Server-Prozess. Die Update-Frequenz auf eine Sekunde erhöht und den Volltextindex neu erstellt. Da war er kurz, dann sofort wieder weg.
In den üblichen Protokollen unter Notes\Data\workspace\logs und in der console.log gab es nichts Auffälliges.
Naja, vielleicht muss man das Debugging erhöhen. Nach etwas Recherche habe ich es mal mit folgenden Einstellungen in der notes.ini versucht:
Debug_Filter_Timing=1
Debug_FT_Stream=1
Debug_FTV_Search=1
Debug_TIKA=1Und jetzt gab es schon etwas mehr zu lesen im Protokoll:
FTGetDocStream: INIT: Opened NoteID 1693AE in DB c:\Program Files (x86)\HCL\Notes\Data\...
Indexing Attachment Object: 'XXX.docx' Size = 24567 using Tika
28.06.2023 11:42:23 DEBUG_TIKA - Launched java process with PID '35980' and args ' -Djt="C:\Users\tbahn\AppData\Local\Temp\notesBBF207" -Dll="c:\Program Files (x86)\HCL\Notes\Data\IBM_TECHNICAL_SUPPORT\ndtika22744.log" -Dcf="C:\Program Files (x86)\HCL\Notes\log4jTika.xml" -jar "C:\Program Files (x86)\HCL\Notes\tika-server.jar" -c "C:\Program Files (x86)\HCL\Notes\dtikacfg.xml"
Could not Connect to Tika process!!!
28.06.2023 11:42:36 DEBUG_TIKA - Error recorded is: Ein früherer Versuch, den Server zu erreichen, ist fehlgeschlagen.
28.06.2023 11:42:36 DEBUG_TIKA - Failed curl_easy_perform in StartTika after 5 retries
28.06.2023 11:42:36 DEBUG_TIKA - ERROR: curl_easy_perform DocID 001693AE Attachment 'XXX.docx' Len 24567 DB 'c:\Program Files (x86)\HCL\Notes\Data\mail\lbahn.nsf'
28.06.2023 11:42:36 DEBUG_TIKA - ERROR: curl_easy_perform Tika PID 35980 Error 'Couldn't connect to server'
28.06.2023 11:42:36 DEBUG_TIKA - ERROR: curl_easy_perform DocID 001693AE Error 'Couldn't connect to server' Tika PID 35980
Indexing Attachment Object: 'YYY.docx' Size = 20917 using Tika
28.06.2023 11:42:38 DEBUG_TIKA - Launched java process with PID '25012' and args ' -Djt="C:\Users\tbahn\AppData\Local\Temp\notesBBF207" -Dll="c:\Program Files (x86)\HCL\Notes\Data\IBM_TECHNICAL_SUPPORT\ndtika22744.log" -Dcf="C:\Program Files (x86)\HCL\Notes\log4jTika.xml" -jar "C:\Program Files (x86)\HCL\Notes\tika-server.jar" -c "C:\Program Files (x86)\HCL\Notes\dtikacfg.xml"
28.06.2023 11:42:50 DEBUG_TIKA - Error recorded is: Ein früherer Versuch, den Server zu erreichen, ist fehlgeschlagen.
28.06.2023 11:42:50 DEBUG_TIKA - Failed curl_easy_perform in StartTika after 5 retries
28.06.2023 11:42:50 DEBUG_TIKA - ERROR: curl_easy_perform DocID 001693AE Attachment 'YYY.docx' Len 20917 DB 'c:\Program Files (x86)\HCL\Notes\Data\mail\lbahn.nsf'
28.06.2023 11:42:50 DEBUG_TIKA - ERROR: curl_easy_perform Tika PID 25012 Error 'Couldn't connect to server'
28.06.2023 11:42:50 DEBUG_TIKA - ERROR: curl_easy_perform DocID 001693AE Error 'Couldn't connect to server' Tika PID 25012Der Tika-Server wird gestartet, aber es kommt sofort die Meldung "Could not Connect to Tika process!!!" Der Rest sind Folgefehler. Auch der nächste Startversuch 15 Sekunden später verläuft nicht anders. Was mir jetzt fehlte, war ein konkreter Grund, warum der Tika-Server so schnell stirbt.
In der Dokumentation, in der HCL Knowledge Base, im Web habe ich jetzt nichts Passendes mehr gefunden. Aber wonach sollte man auch ohne weitere Details suchen?
Im Notes-Programmverzeichnis bin ich dann auf die log4jTika.xml gestoßen, mit der man offensichtlich das Logging für den Tika-Server konfigurieren kann.
Am Anfang der Datei steht im <Configuration>-Tag das Attribut status="OFF" und gegen Ende ist der CONSOLE_APPENDER auskommentiert, aber ansonsten sah alles schon gut aus. Den Anfang geändert in <Configuration status="ERROR"> und die XML-Kommentarzeichen <!-- und --> weiter unten entfernt, Notes-Client neu gestartet, Volltextindex neu erstellt und... Nichts. Zumindest nichts Neues. Gleiche Meldungen in der console.log. Eigentlich sollte es durch den ROLLING_FILE_APPENDER doch auch Protokolldateien vom Tika-Server selbst geben. Auf dem Server liegen die ndtika*.log-Dateien doch neben der console.log im IBM_TECHNICAL_SUPPORT-Verzeichnis. Nix. Nada.
Jetzt komme ich auf eine neue Idee: Im console.log stehen doch die gesamten Aufrufparameter der JVM. Das kann man doch auch einmal manuell nachstellen und versuchen. Gesagt, getan.
Terminal (die neue Eingabeaufforderung) gestartet, ins Notes-Programmverzeichnis gewechselt und folgendes Kommando abgesetzt:
jvm\bin\java.exe -Djt="C:\Users\tbahn\AppData\Local\Temp\notesBBF207" -Dll="c:\Program Files (x86)\HCL\Notes\Data\IBM_TECHNICAL_SUPPORT\ndtika29692.log" -Dcf="C:\Program Files (x86)\HCL\Notes\log4jTika.xml" -jar "C:\Program Files (x86)\HCL\Notes\tika-server.jar" -c "C:\Program Files (x86)\HCL\Notes\dtikacfg.xml"Als Belohnung kam eine echte, richtige, aussagekräftige und komplett verwirrende Fehlermeldung:
JVMJ9VM015W Initialisierungsfehler für Bibliothek j9gc29(2): Instanziieren des Heapspeichers ist fehlgeschlagen; 2G erforderlich
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
ERROR [main] 11:57:45,735 org.apache.tika.server.core.TikaServerCli Can't start:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Failed to start forked process -- forked is not alive
at java.util.concurrent.FutureTask.report(Unknown Source) ~[?:1.8.0_345]
at java.util.concurrent.FutureTask.get(Unknown Source) ~[?:1.8.0_345]
at org.apache.tika.server.core.TikaServerCli.mainLoop(TikaServerCli.java:121) ~[tika-server.jar:2.4.1]
...Die JVM konnte also den Heap-Speicher nicht instanziieren, weil dafür 2 GB erforderlich wären.
Hatte ich erwähnt, dass mein neues Notebook 64 GB RAM hat und unter einem 64-bit Windows 11 läuft?
Und natürlich waren mehr als 2 GB frei - viel mehr. Vielleicht zu viel? Egal, ich hatte jetzt etwas, wonach ich suchen konnte. Und tatsächlich gab es mehrere Treffer zu dieser Fehlermeldung. Nicht im Notes-Umfeld, aber z. B. bei Websphere. Im Kern ging es aber jeweils darum, dass ein 32-bit Programm nicht mehr als 2 GB nutzen könnten.
Aber in einem Kommentar im jazz.net-Forum blitze etwas auf, dass im Ergebnis doch zur Lösung führte.
Das Thema war "Insight: WAS MAX_HEAP_SIZE parameter?"
Und im letzten Kommentar zu dem Thread stand:
"Searching for "Failed to instantiate heap; 2G requested Could not create
the Java virtual machine" on Google I found a few hits. This one seems
to have the best explanation (according to the up votes anyway)
http://stackoverflow.com/questions/171205/java-maximum-memory-on-windows-xp
1850 MB seemed to be one of the higher values that was successfully used on Windows."
Der Foreneintrag war von 2012, die zitierte Frage auf stackoverflow.com von 2009 und bezog sich auf Windows XP!
Weiter unten stand in einem Kommentar zum zitierten Artikel:
"The Java heap size limits for Windows are:
- maximum possible heap size on 32-bit Java: 1.8 GB
- recommended heap size limit on 32-bit Java: 1.5 GB (or 1.8 GB with /3GB option)"
Kann es sein, dass 14 Jahre später eine 32-bit JVM immer noch keine 2 GB Heap-Speicher verträgt. Und überhaupt: Wo kommen die 2 GB überhaupt her?
Bei der Suche nach nützlichen Protokoll- und Konfigurationsdateien bin ich im Notes-Programmverzeichnis auf die Datei dtikacfg.xml gestoßen. Das klingt doch nach Tika...
Die XML-Datei ist offenbar eine Konfigurationsdatei für den Tika-Server und in den forkedJvmArgs steht auch das -Xmx mit dem der JVM die maximale Größe des Heap-Speichers vorgegeben wird. Heureka!
Ich ändere die Zeile in:
<arg>-Xmx1800m</arg>Danach: Notes-Neustart, Volltextindex neu erstellt und... Der Tika-Server läuft.
Im Process Explorer sehe ich die java.exe (und darunter eine weitere java.exe) als Unterprozess des Notes-Clients.
Im console.log kann ich nachvollziehen, wie diverse NoteIDs (also Dokumente) geöffnet und Dateianhänge in jeweils wenigen Millisekunden von Tika verarbeitet werden.
Ich frage mich nur noch: Warum gab es denn schon einige Volltextindexe? Ein zweites 32 GB RAM-Modul kam etwas verspätet. Vielleicht wurden diese Indexe angelegt, als mein Rechner noch 32 GB RAM hatte?! Ich werde es vermutlich nie erfahren.
