Doppellistings abgleichen -- cmanager

[mic@]

Dazu einige Fragen:

a) Wenn man von sagen wir mal 100 Caches in der MyFinds gpx ausgeht, wie schnell sind die beim normalen cmanager abgearbeitet
und wie schnell sind die bei einem cmanager, wo die Parallelität abgeschaltet wäre, abgearbeitet?

b) Müsste nicht alle cmanager Nutzer von diesem Problem betroffen sein?
Oder ist es bloß problematisch, wenn man den cmanager mit zig-tausenden Funden füttert?

[FriedrichFröbel]

a) Wenn man von sagen wir mal 100 Caches in der MyFinds gpx ausgeht, wie schnell sind die beim normalen cmanager abgearbeitet
und wie schnell sind die bei einem cmanager, wo die Parallelität abgeschaltet wäre, abgearbeitet?

Ich kann hier keine absoluten und auch keine genauen Zahlen nennen, da das von verschiedenen Faktoren abhängt. Aktuell gibt es 10 Threads, sodass je nach gewählter Anzahl Threads der vermutlich Maximalfaktor trivial berechnet werden kann, ohne auf konkrete Werte verweisen zu müssen. Meine kurzen Tests für die genannten 30 Caches warfen mit 2 Threads teilweise keinen Fehlerdialog. Ohne jegliche Parallelität wäre es am sichersten, aber auch am langsamsten. Die weiteren Einschränkungen bezüglich kompatibler Listengrößen etc. liegen nicht unter meiner Kontrolle.

b) Müsste dieser Fehler dann nicht alle cmanager Nutzer betreffen, oder ist es bloß zum Fehler geworden,
wenn man den cmanager mit zig-tausenden Funden füttert?

Wie gesagt: Ich konnte den Fehler auch mit 30 Caches reproduzieren. Im ungünstigsten Fall betrifft das alle cmanager-Benutzer. Meines Erachtens ist das jetzige Auftreten allerdings nicht durch Änderungen meinerseits zu erklären, sondern möglicherweise (wie bereits erwähnt) durch eventuelle neue/verschärfte Sicherheitsmaßnahmen auf Seiten OC, was sich auch auf die OKAPI auswirken würde/könnte. (So wie auch die OKAPI in letzter Zeit nur sehr selten Fulldumps liefert.)

[rennschnecke60]

Hallo,
ich antworte direkt, rennschnecke60 hier:
hier der detaillierte Fehler aus dem DOS-Aufruf:

Code: Alles auswählen

Mai 22, 2023 7:43:28 PM org.apache.http.impl.execchain.RetryExec execute
INFORMATION: Retrying request to {s}->https://www.opencaching.de:443
org.apache.http.NoHttpResponseException: www.opencaching.de:443 failed to respond
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
        at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
        at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
        at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
        at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
        at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
        at cmanager.network.ApacheHttp.get(ApacheHttp.java:53)
        at cmanager.okapi.Okapi.completeCacheDetails(Okapi.java:203)
        at cmanager.oc.OcUtil.findSingleGeocache(OcUtil.java:173)
        at cmanager.oc.OcUtil.lambda$findOnOc$0(OcUtil.java:67)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1623)

[rennschnecke60]

Guten Abend,
ich habe das Problem für mich gelöst.
Aus meiner GPX Datei habe ich alle Events und Celebration Events gelöscht und dann normal den Vorgang durchlaufen lassen.
Jetzt funktioniert es.
Mich würde es trotzdem interessieren, warum das so ist.

Gruß
Manuela aka rennschnecke60

[FriedrichFröbel]

Event-Caches sollten im Zusammenhang mit der OKAPI keine besondere Behandlung erfahren - die relevante Filterung anhand des Eventdatums erfolgt im cmanager selbst. Daher kann ich mir den Effekt nicht ohne weitere Beeinflussung erklären. Beispiele hierfür wären ein großer Anteil an Eventcaches in der GPX-Datei, eine Beeinflussung durch die lokale Speicherung leerer Ergebnisse auf Seiten des cmanager oder Änderungen am Netzwerk.

[rennschnecke60]

Ich habe tatsächlich nur die Löschung der Events vorgenommen. Bei der Durchsicht der Logs ist aufgefallen, dass ich ein Event übersehen habe. Das war das Brockenevent. Das ist dann auch als Doppellog angezeigt worden. Warum und woran es nun gelegen hat, kann ich nicht beschreiben.