Als Java EE-Entwickler für lange Zeit habe ich den MDC-Ansatz (Maped Diagnostic Context) verwendet, um mit kontextbezogenen Daten umzugehen, die sich auf eine Anfrage beziehen, z. ein eindeutiges Anforderungstoken zum Verfolgen einer Anforderung über viele potenzielle Protokollereignisse hinweg, die während der Lebensdauer dieser Anforderung auftreten.
Wenn man sich auf ThreadLocal verlässt, ist es ziemlich klar, dass dieser Ansatz implodiert, wenn asynchrone Techniken verwendet werden.
Ich bin immer noch in den frühen Tagen des Lernens von Scala und, mehr relevant für diese Frage, Akka. Ich habe viele Beiträge in Foren gelesen, in denen die Unvereinbarkeit von Akka und MDC bestätigt wurde, aber ich habe noch keine konsistente Strategie für die Nachahmung des MDC-Ansatzes gefunden.
Ist es am besten, diese Art von Daten explizit als Teil der Nachrichten zu übergeben, die zwischen den Akteuren gesendet werden? Es fühlt sich irgendwie schmutzig an, ist aber gleichzeitig kompatibel mit der Fähigkeit, mühelos zu skalieren.
Gibt es eine andere Möglichkeit, den Kontext an einen Actor anders als direkt über Nachrichten weiterzugeben? Hat auch jemand diese gleiche Herausforderung bei der Verwendung von Play 2.0 Async-Blöcken?
Ich denke, Sie könnten ThreadLocal -s in einem statischen Kontext deklarieren, genauso wie der implizite Executor-Parameter in diesem Code:
Jedes Mal, wenn in Zukunft eine Aufgabe an einen Dispatcher übergeben wird, kopieren Sie ein threadsicheres Kontextobjekt von einem Thread in einen anderen. Also, Sie brauchen einen benutzerdefinierten Dispatcher - lesen Sie ThreadLocal , speichern Sie ihn intern irgendwo innerhalb des Executors (Dispatcher) und senden Sie dann die Aufgabe, die zuerst in ThreadLocal
Tags und Links scala asynchronous akka playframework