Asynchrone Sammlungs-API-Aufrufe in Solr

Seit der Einführung von langlaufenden Sammel-API-Aufrufen ist häufig zu beobachten, dass die Aufrufe hin und wieder TIMEOUT gehen. Aufrufe wie ShardSplit nehmen eine Zeitüberschreitung, ohne dass viel über den Status der Anfrage bekannt ist. Obwohl die meisten Aufrufe praktisch idempotent sind, wäre es für die Benutzer dennoch viel besser zu wissen, ob eine Anfrage gerade in Bearbeitung ist, fehlgeschlagen ist oder nach der Timeout-Dauer tatsächlich abgeschlossen wurde.

Dies brachte mich dazu, mit der Arbeit an asynchronen Aufrufen für OverseerCollectionProcessor(SOLR-5477) zu beginnen. Der Code befindet sich bereits in den beiden Zweigen trunk und branch_4x von Apache Lucene/SOLR und sollte mit 4.8 veröffentlicht werden.

Der Entwurf

Die Unterstützung von asynchronen Aufrufen der Sammel-API ist nicht so trivial, wie es klingt. Die Absicht bei der Entwicklung dieser Funktion war, dass kein Aufruf irgendwo dazwischen verloren geht. Der allgemeine Ablauf eines CollectionAPI-Aufrufs umfasst auch mehrere CoreAdmin-Aufrufe. Würden diese nicht behandelt, d.h. nicht asynchron, würde dies zu einer Zeitüberschreitung für die internen CoreAdmin-Aufrufe führen, was den Zweck ziemlich zunichte macht.

Das Gesamtdesign von asynchronen Aufrufen der Sammel-API umfasst die folgenden API-Komponenten:

• Asynchroner Aufruf API: Zusätzlicher Parameter ‚async=xx‘ für Collection API-Aufrufe, der die Aufrufe asynchron macht,
• Fordern Sie die API für die Statussammlung an, um den Status eines vorab eingereichten asynchronen Aufrufs zu überprüfen,
• CoreAdmin unterstützt asynchrone Aufrufe,
• CoreAdmin Anfrage Status API.

Der ‚async‘-Aufruf der Collection API:

Hier sehen Sie, wie ein asynchroner SPLITSHARD-Aufruf aussieht:

http://localhost:8983/solr/admin/collections?action=SPLITSHARD&collection=collection1&shard=shard1&async=5

<response>
  <lst name=“responseHeader">
    <int name=“status">0</int>
    <int name=“QTime">3</int>
  </lst>
  <str name="requestid">5</str>
</response>
  <!--lst>
  <str name="requestid">5
</response>

Hier wandelt async=5 diesen Aufruf in einen asynchronen Aufruf um.

Verfolgen Sie die Anfrage:

Sobald ein asynchroner Aufruf empfangen wird, wird die requestId von Solr de-dupliziert und der Aufruf zurückgegeben.

Der Status des Anrufs kann dann mit der REQUESTSTATUS API verfolgt werden.

http://localhost:8983/solr/admin/collections?action=REQUESTSTATUS&requestid=5

<response>
  <lst name=“responseHeader">
    <int name=“status">0</int>
    <int name=“QTime">93</int>
  </<!--lst>
  <lst name=“status">
    <str name=“state">completed</str>
    <str name="msg">found 5 in completed tasks</str>
  </lst>
</response>

Antwort für eine nicht existierende requestid:

<response>
  <lst name=“responseHeader">
    <int name=“status">400</int>
    <int name=“QTime">3</int>
  </lst>
  <lst name=“error">
    <str name="msg">Missing required parameter: requestid</str>
    <int name=“code">400</int>
  </lst>
</response>

Wie funktioniert das?

Sobald eine Sammlungs-API-Anfrage empfangen wird, wird sie auf den asynchronen Parameter geprüft. Wenn er gefunden wird, wird die requestId de-dupliziert und der Aufruf wird zur Verarbeitung an den OverseerCollectionProcessor übermittelt und der Aufruf kehrt zurück. Wenn nicht, enthält die Antwort einen Fehler.

Es handelt sich um eine gemeinsame Warteschlange, die alle CollectionAPI-Anfragen enthält. Wenn diese Anfrage abgeholt wird, sorgt das Vorhandensein einer requestId dafür, dass alle Unteraufrufe (CoreAdmin-Anfragen), die der Overseer an andere Kerne richtet, ebenfalls asynchron sind (siehe unten). Dadurch wird sichergestellt, dass die abhängigen Aufrufe nie einfach eine Zeitüberschreitung verursachen. So wird beispielsweise ein Indexsplit, der für das Shard-Splitting erforderlich ist, vom Overseer im asynchronen Modus ausgelöst und dann bis zur Fertigstellung oder zum Scheitern verfolgt.

Sobald alle Unteraufrufe abgefeuert und abgeschlossen sind, wird die Aufgabe intern entweder in die Warteschlange für abgeschlossene oder fehlgeschlagene Aufgaben verschoben, je nach Status der Anfrage.

Die API für den Anfragestatus würde zu diesem Zeitpunkt beginnen, den aktualisierten Status für die Anfrage zurückzugeben.

Falls es Sie interessiert, die Anfragen werden über Knoten in ZooKeeper verfolgt.

Hier sehen Sie, wie die Pfade in Zk aussehen:

/overseer
 +  /collection-map-completed/
     + [mn-5]
 +  /collection-map-failure/..
 +  /collection-map-running/..

Bereinigung der ZK-Tracking-Karte

Derzeit verfügen die oben beschriebenen Tracking Maps nicht über einen Mechanismus zur automatischen Bereinigung. Die einzige manuelle Möglichkeit, dies zu tun, ist die Verwendung der REQUESTSTATUS API. Die Übergabe einer requestId von ‚-1‘ an den Aufruf erzwingt eine Bereinigung der Tracking Maps.

http://localhost:8983/solr/admin/collections?action=REQUESTSTATUS&requestid=-1

Wie nützlich wäre das?

Ich persönlich denke, dass dies für alle, die bei der Ausführung zeitaufwändiger Aufgaben (unter anderem) auf TIMEOUT-Probleme gestoßen sind, sehr nützlich wäre. Mit der Hinzufügung von umfangreichen APIs wie SplitShard und Migrate wären asynchrone Aufrufe sicherlich mehr als nützlich.

Kommen noch mehr?

Obwohl die Aufrufe der Collection API asynchron sind, werden sie nicht wirklich parallel verarbeitet. Der OverseerCollectionProcessor, der für die Verarbeitung der eingereichten Aufgaben zuständig ist, arbeitet mit einem einzigen Thread. Damit dies so funktioniert, wie es sich intuitiv anfühlt, müssten wir den OverseerCollectionProcessor mit mehreren Threads ausstatten. Die Arbeit daran sollte hoffentlich bald beginnen. Als Referenz finden Sie hier ein JIRA dazu: SOLR-5681.

CoreAdmin Async-Aufrufe:

Wie ich bereits erwähnt habe, können Collection API-Aufrufe nicht wirklich asynchron sein, ohne dass die zugrundeliegenden CoreAdmin-Aufrufe asynchron sind. Die Unterstützung für letztere wurde ebenfalls im Rahmen desselben Problems eingeführt. Die Details dazu sind, glaube ich, für einen anderen Beitrag gedacht, aber hier sehen Sie, wie die Aufrufe aussehen:

http://localhost:8983/solr/admin/cores?action=CREATE&name=a1&instanceDir=a1&dataDir=a1&config=solrconfig.xml
&schema=schema.xml&async=2003

Anfrageverfolgung:
http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=2003

P.S.: Weitere Informationen darüber, wie sich dies entwickelt hat, finden Sie in SOLR-5477.