LanguageTool richtig installieren

[visioneer_cgn]

OK - manchmal sieht man den Wald vor Bäumen nicht - Fehler gefunden. Lag am Benutzer. Copy/Past birgt die Gefahr, das man schlicht das https:// vor der Adresse vergisst. Doof nur das der dann keine Fehlermeldung herausgibt. 20x drauf geschaut und es nicht wahrgenommen. Korrekt in die Word Erweiterung eingegeben funktioniert es. #peinlich

 

[plang.pl]

Bei mir steht nach einiger Zeit immer, dass der Container "unhealthy" ist. Im Log ist aber nix zu finden, was das begründet (denke ich)

 

[haydibe]

War ein Bug nach der Umstellung vom Healtheck von curl auf wget. Das hatte ich vor einigen Tagen behoben. Einfach das neue 9.6er ziehen und neu deployen.

 

[plang.pl]

Ahja, jetzt sehe ich das auch:


Hab jetzt noch mal den Container neu erstellt mit "Always pull the image".
Allerdings steht er immer noch auf unhealthy mit dem gleichen Fehler.
Ich habe auch watchtower am laufen, also eigentlich sollte ich die neueste Version haben

 

[haydibe]

Der Output zeigt das nicht das aktuelle Image verwendet wird. Ich hatte am 04.12 curl mit 5.9-5 ausgebaut und am 07.12 dann den fehlerhaften Healthcheck mit 5.9-7 gefixed.

In den Stats kann ich sehen, dass Leute auch immer noch ältere Versionen des Imges ziehen.

 

[plang.pl]

Hab etz mal manuell den Tag auf 5.9-7 geändert. Besteht aber immer noch

 

[haydibe]

Hmm. ich schau mal nach was da los ist. Sollte jetzt eigentlich gehen.

Update: ich hab Portainer jetzt mal installiert: bei mir wird der Container als Healthy angezeigt.

Schau doch mal, ob das was Portainer anzeigt überhaupt stimmt: docker inspect languagetool --format '{{json .State.Health}}' |jq

Und ob der Healthcheck wirklich der richtige ist: docker inspect languagetool --format '{{json .Config.Healthcheck}}' |jq
Die Ausgabe sollte so aussehen:

{
  "Test": [
    "CMD-SHELL",
    "wget --quiet --post-data \"language=en-US&text=a simple test\" -O - http://localhost:8010/v2/check > /dev/null 2>&1  || exit 1"
  ],
  "Interval": 30000000000,
  "Timeout": 10000000000,
  "StartPeriod": 10000000000
}

 

[plang.pl]

Hab jetz noch mal den Container, alle Dateien und Images gelöscht und alles neu gemacht. Aktuell lädt er die ngrams. Mal schauen, vielleicht gehts dann wieder

 

[haydibe]

Ohje, warum hast Du denn die ngrams gelöscht. Aus dem Volume sollte man nichts löschen müssen.

 

[plang.pl]

Ich weiß, dass man das nicht muss. Wenn ich den Container schon neu erstelle, machs ich aber gleich inklusive allem

 

[haydibe]

Du kannst auch schauen, ob der HealtCheck im Image korrekt ist:

docker image inspect meyay/languagetool:latest --format '{{json .ContainerConfig.Healthcheck}}' | jq
{
  "Test": [
    "CMD-SHELL",
    "wget --quiet --post-data \"language=en-US&text=a simple test\" -O - http://localhost:8010/v2/check > /dev/null 2>&1  || exit 1"
  ],
  "Interval": 30000000000,
  "Timeout": 10000000000,
  "StartPeriod": 10000000000
}

Wenn da etwas anderes steht, dann ist es nicht das aktuelle latest==5.9-7.

 

[plang.pl]

Jap. Hab ich grad gesehen, dass du den Eintrag oben editiert hast. Ich wart jetz erstmal den Download ab und werde das dann ggfs. testen

 

[plang.pl]

Also nun läuft er "healthy" und der Befehl von dir liefert auch die gewünschte Ausgabe!
Also alles wieder in Butter!

 

[plang.pl]

Nun habe ich seit ein paar Tagen ein anderes Problem. Der Container schmiert zwar anscheinend nicht ab, beantwortet aber gehäuft Anfragen nicht mehr.
Der Log sagt HTTP ERROR 500:

Spoiler: Portainer Log

2023-01-01 20:06:53.888 +0000 ERROR org.languagetool.server.LanguageToolHttpHandler An error has occurred: 'java.lang.NoClassDefFoundError: Could not initialize class dumonts.hunspell.bindings.HunspellLibrary, detected: de-DE', sending HTTP code 500. Access from 172.17.0.1, HTTP user agent: Mozilla/5.0 (Windows NT 10.0; rv:108.0) Gecko/20100101 Firefox/108.0, User agent param: webextension-firefox-ng, v: 6.0.1, Referrer: null, language: auto, h: 1, r: 8006, time: 2213m: ALL_BUT_TEXTLEVEL_ONLY, l: PICKY, iID: 80948:1672603621270, Stacktrace follows:java.lang.RuntimeException: java.lang.NoClassDefFoundError: Could not initialize class dumonts.hunspell.bindings.HunspellLibrary, detected: de-DE
at org.languagetool.server.TextChecker.checkText(TextChecker.java:507)
at org.languagetool.server.ApiV2.handleCheckRequest(ApiV2.java:172)
at org.languagetool.server.ApiV2.handleRequest(ApiV2.java:83)
at org.languagetool.server.LanguageToolHttpHandler.handle(LanguageToolHttpHandler.java:185)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
at jdk.httpserver/sun.net.httpserver.AuthFilter.doFilter(Unknown Source)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(Unknown Source)
at jdk.httpserver/com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
at jdk.httpserver/sun.net.httpserver.ServerImpl$Exchange.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class dumonts.hunspell.bindings.HunspellLibrary
at java.base/java.util.concurrent.FutureTask.report(Unknown Source)
at java.base/java.util.concurrent.FutureTask.get(Unknown Source)
at org.languagetool.server.TextChecker.checkText(TextChecker.java:489)
... 12 more
Caused by: java.lang.NoClassDefFoundError: Could not initialize class dumonts.hunspell.bindings.HunspellLibrary
at dumonts.hunspell.Hunspell.<init>(Hunspell.java:21)
at org.languagetool.rules.spelling.hunspell.DumontsHunspellDictionary.<init>(DumontsHunspellDictionary.java:33)
at org.languagetool.rules.spelling.hunspell.Hunspell.getDictionary(Hunspell.java:46)
at org.languagetool.rules.spelling.hunspell.HunspellRule.init(HunspellRule.java:584)
at org.languagetool.rules.de.GermanSpellerRule.init(GermanSpellerRule.java:1557)
at org.languagetool.rules.spelling.hunspell.HunspellRule.ensureInitialized(HunspellRule.java:558)
at org.languagetool.rules.spelling.hunspell.HunspellRule.match(HunspellRule.java:220)
at org.languagetool.rules.de.GermanSpellerRule.match(GermanSpellerRule.java:1475)
at org.languagetool.JLanguageTool.checkAnalyzedSentence(JLanguageTool.java:1370)
at org.languagetool.JLanguageTool.access$1500(JLanguageTool.java:74)
at org.languagetool.JLanguageTool$TextCheckCallable.getOtherRuleMatches(JLanguageTool.java:1950)
at org.languagetool.JLanguageTool$TextCheckCallable.call(JLanguageTool.java:1866)
at org.languagetool.JLanguageTool$TextCheckCallable.call(JLanguageTool.java:1833)
at org.languagetool.JLanguageTool.performCheck(JLanguageTool.java:1294)
at org.languagetool.JLanguageTool.checkInternal(JLanguageTool.java:991)
at org.languagetool.JLanguageTool.check2(JLanguageTool.java:918)
at org.languagetool.server.TextChecker.getPipelineResults(TextChecker.java:802)
at org.languagetool.server.TextChecker.getRuleMatches(TextChecker.java:751)
at org.languagetool.server.TextChecker.lambda$checkText$5(TextChecker.java:472)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
... 3 more

2023-01-01 20:06:53.888 +0000 INFO org.languagetool.server.LanguageToolHttpHandler Handled request in 2214ms; sending code 500

@haydibe Weißt du, was hier zu tun ist?

 

[haydibe]

Seit ein paar Tagen? Ich hab vorgestern auf die Schnelle das 6.0er Image gebaut nach kurzem Test gepushed.

Ich schau mir die Logs mal an

Die Fehler hab ich tatsächlich auch. Entweder ist da beim languagetool 6.0 Release etwas schief gelaufen oder es haben sich evtl. startparameter geändert die ich im Entrypoint-Skript nachziehen muss.

Notfalls einfach das Tag "5.9" verwenden und die stabile Version von davor verwenden.

 

[haydibe]

In den Release notes steht nichts zu den Startparametern.

Es wirkt es mal so, dass es ein Problem des 6.0er Releases ist. Mit dem Download des 6.0er Releases erbt das Image solche Probleme natürlich mit.
Ich kann morgen mal schauen, ob die Klasse mit dem Package in einem der anderen jar-Dateien liegt und man ggf. durch das erweitern des Classpath ein Workaround hinbekommt.

@plang.pl Danke für die Info! Ich entferne das 6.0er Tag erstmal wieder...

 

[plang.pl]

Danke für die schnelle Antwort. Ich habe das mal fix getestet. Mit dem 5.9-7 haut alles hin.
Gib halt nochmal Rückmeldung, wenns was neues gibt.

 

[haydibe]

Im Release 6.0 wird eine zusätzliche Linux-Bibliothek benötigt, die so in 5.9 scheinbar nicht benötigt wurde.
Ich push gerade 6.0-2. Bisher sehen die Logs gut aus

 

[plang.pl]

Versuch ich morgen mal.
Tolle Arbeit. Und by the way: A Gsundes neues Jahr noch!

 

[haydibe]

Wünsche ebenso ein frohes und gesundes neues Jahr!