Non-Retryable requests when transactions are being used?
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
Rechercherichtung
Beginne mit OkHttpServices.sendRequestWithRetry und seinen Aufrufern, insbesondere headImplExec und DocumentManagerImpl.exists, und verwende den Stacktrace sowie das Transaktionsargument als Einstiegspunkte. Überprüfe das bestehende Retry-Verhalten und die Tests für vorübergehende Servicefehler. Erledigt ist die Aufgabe, wenn die Retry-Entscheidung zwischen Kommunikationsfehlern und der Transaktionsverarbeitung unterscheidet und die transaktionale exists-Anfrage durch Regressionstests abgedeckt ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
We run our integration tests in gitlab in a dockerized environment, and since we started to use MarkLogic server transactions more we noticed our tests behaving increasingly flaky. We suspect the dockerized environment to induce some connection and availability issues. Here is a stacktrace of one of the issues:
com.marklogic.client.FailedRetryException: Service unavailable and maximum retry period elapsed: 0 seconds after 0 retries
at com.marklogic.client.impl.OkHttpServices.sendRequestWithRetry(OkHttpServices.java:576)
at com.marklogic.client.impl.OkHttpServices.headImplExec(OkHttpServices.java:1054)
at com.marklogic.client.impl.OkHttpServices.headImpl(OkHttpServices.java:1016)
at com.marklogic.client.impl.OkHttpServices.head(OkHttpServices.java:972)
at com.marklogic.client.impl.DocumentManagerImpl.exists(DocumentManagerImpl.java:145)
The code leading into this trace is supposed to check, whether a document exists and looks like this:
final DocumentDescriptor documentDescriptor = manager.exists(docUri.toString(), transaction);
The transaction is non-null in the above statement. And as it turns out the OkHttpServices in line 1054:
return sendRequestWithRetry(requestBldr, (transaction == null), doHeadFunction, null);
renders a request using a transaction being "not retryable".
In a distributed system communication errors can happen, regardless of whether a transaction is being used or not. There should be a destinction being made depending on the type of error, whether it makes sense to repeat a request. The existence of a transaction should not make a difference here.
(We are currently using the marklogic-java-client in version 8.0.0 and the Markogic Server in 11.3.1)
- Vorherrschende Sprache
- Java
- Sterne
- 61
- Forks
- 74
- Ø Merge
- 47 Min.
- Gemergte PRs (30 T.)
- 2
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus marklogic/java-client-api
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
marklogic/java-client-api#1939 · 1 Kommentar ·
-
server-bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
marklogic/java-client-api#1643 · 7 Kommentare ·
Alle Issues in marklogic/java-client-api
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
objectionary/eo-graphs#85 ·
-
BoxAttachmentMulti parsing leaks IOException / ArrayIndexOutOfBoundsException on malformed content instead of IllegalArgumentExceptionEvtl. vergeben @Kshot3000 hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
ergoplatform/ergo-appkit#272 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
utopia-rise/godot-jvm#1004 ·
Maintainer antworten meist innerhalb von 1 Tag