EDIT

Probably the reason is that potential deduplication candidates are not found correctly and the list of candidates is too long.

=====

ERS:

in letzter Zeit habe ich den Eindruck, dass die Performance des Parsers im Freitext-Editor stark nachgelassen hat. Es scheint mir ewig zu dauern, bis der Parser Namen, Autoren und Nomenklatorische Referenz atomisiert hat und das Taxon zum weiteren Editieren frei wird, die Sanduhr läuft und läuft…

KL:

danke für die Rückmeldung! Tritt dieses Phänomen im Zusammenhang mit dem neuen Release auf oder gab es das Problem schon länger bzw tritt das erst seit kurzem auf?
Ich frage, weil es ja an der Performance des CdmServers oder wirklich am Parser liegen kann. Ich werde auf jeden Fall aber auch nochmal testen und debuggen.

ERS:

ich habe den Eindruck, dass es mit dem neuen Release zusammenhängt. Um das Problem zu konkretisieren:

ich habe ein neues Taxon eingegeben (Rechtsklick auf den Elternknoten -> Neu-> Taxon-> Neues Taxon.
Hier gebe ich den kompletten Namen mit Autoren und Referenz ein, danach auf „finish and open“. Es dauert etwa 40-50 Sekunden, bis die Sanduhr abläuft und der Freitext-Editor sich öffnet. Daher vermute ich, dass die Verzögerung an der Stelle durch den Parser kommt, oder?

KL:

ich habe gestern schon mal ein bisschen getestet und mir scheint, dass tatsächlich beim Suchen der möglichen Kandidaten für Autoren irgendwie zu viele Ergebnisse zurück kommen, aber das muss ich nochmal verifizieren und dann an Andreas M. weiter leiten. Wobei an dieser Stelle eigentlich schon im Sommer gearbeitet wurde. Aber manchmal fällt es eben erst später auf.

ERS:

das klingt für mich insofern plausibel, als dass es deutlich schneller geht, wenn nur ein Autor vorhanden ist und nicht mehrere.

KL:

Hallo Andreas, Eckhard hat ja ... angemerkt, dass der Parser bei längeren Autorenlisten sehr langsam geworden ist. Ich habe mir das oberflächlich mal angesehen und bei den „potentiellen“ Autoren erscheinen sehr viele, bei denen mir nicht klar ist, wie sie in die Liste der potentiell matchenden Personen kommen, vielleicht kannst Du da selber nochmal drauf gucken?

AM:

Kannst du mir noch sagen, an welcher Stelle im Code das genau ist?
Und mit welchen Daten hast du getestet?

KL:

ich habe in meiner caryophyllales_ssp Instanz getestet und zum Beispiel, wenn man Freitag & G.Kadereit als Autorenteam angibt, dann bekommt man eine sehr lange Liste von candidates (s. u. und diese ist noch nicht vollständig… )
der code ist in CdmGenericDaoImpl ungefähr Zeile 658

bei einzelnen Autoren scheint es gut zu funktionieren, da kommen soweit ich das gerade eben nochmal getestet habe, passende Kandidaten (ich habe nur L. getestet)

Match candidate did not match: Eckl. & Zeyher, C.L.P.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Rose, J.N. & Standley, P.C.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Alvarado-Sizzo, H., Casas, A., Parra, F., Arreola-Nava, H. J., Terrazas, T. & Sánchez, C.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Barrios, D., González-Torres, L.R., Arias, S. & Majure, L.C.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Fuertes, J. F. & Nieto Feliner, G.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Dinter, M.K. & G.Schellenb.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Eckl. & Zeyher, C.L.P.
[local-test] 2022-01-03 10:59:19,095 INFO [eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImpl] - Match candidate did not match: Eckl. & Zeyher, C.L.P.
...

AM:

ok, ich schau mir das an. Kannst du evtl. noch mal kurz testen, ob es ein Problem ist, was nur bei Teams auftritt?

KL:

bei einzelnen Personen scheint das Problem nicht zu bestehen, da kommt nur eine Liste, wenn es wirklich mehrere Einträge mit dem selben Namen gibt, wie z.B. bei L.

ERS:

Im Nachgang zu meinen bisherigen Nachrichten:

Testet doch einmal die Eingabe folgenden Namens in den Freitext-Editor und seht, wie sich der Parser verhält.

Berberocarum Zakharova & Pimenov in Nordic J. Bot. 2021(e03206): 10. 2021

Es gibt auch zwei Problem-Meldungen, die ich eigentlich nicht verstehe:

„check rank“ (obwohl der Rang korrekt als Genus erkannt wird)
„reference title not parsable“ (liegt das an der ungewöhnlichen Bandangabe für electronic journals? Damit müsste der Parser aber auch umgehen können, d.h., dort sollte man alle Möglichkeiten offenhalten und die Eingabe nicht irgendwie beschränken)

Eine generelle Frage, die ich beobachtet habe: der Parser fängt ja anscheinend sofort an zu arbeiten, sobald ich etwas eintippe. Wenn ich also nicht mit copy&paste arbeite, sondern wirklich Freitext eintippe, wird sofort versucht zu parsen, auch wenn ich noch nicht fertig bin und z.B. die Seitenzahl oder etwas anderes noch kurz nachschlagen muss. Wenn meine Eingabe also noch nicht abgeschlossen ist, kommen dann Fehlermeldungen.
Bisher war mir das nicht so aufgefallen, da der Parser sehr schnell war. Aber wie gesagt, jetzt läuft es in dem Bereich (gefühlt seit einem der letzten Releases) sehr langsam.

Vielleicht hilft das Beispiel oben ja weiter, das Problem einzugrenzen. Schaut doch mal, wie lange das Parsen dieses Namens bei euch dauert und welche Schwierigkeiten dabei entstehen.

parallel AM:

Katja hat da drauf geschaut und bereits ein mögliches Problem gefunden. Kann es sein, dass das Problem nur bei Namen auftaucht, die ein Autorenteam und nicht einen Einzelautor haben?
Ich schaue mir das noch im Detail an und hoffe, dass wir es zum nächsten Release gelöst bekommen.

ERS:

da haben sich unsere mails gerade überschnitten. Ja, auf jeden Fall ist es bei Autorenteams besonders langsam.