Wie implementiere ich Schauspielermodelle ohne Akka?

8

Wie implementiert man einfache Schauspieler ohne Akka? Ich brauche keine hohe Leistung für viele (nicht feste Anzahl) Actor-Instanzen, Green-Threads, IoC (Lifecycle, Props-basierte Fabriken, ActorRef's), Überwachung, Gegendruck usw. Benötigt nur Sequentialität (Warteschlange) + Handler + Status + Nachrichtenübergabe

Als Nebeneffekt brauche ich eine kleine akteurbasierte Pipeline (mit rekursiven Links) und einige parallele Akteure, um den DSP Algorithmusberechnung. Es wird innerhalb der Bibliothek ohne transitive Abhängigkeiten sein, also will ich (und kann nicht, da es ein jar-plugin ist) den Benutzer dazu bringen, akkaSystem zu erstellen und weiterzuleiten, die Bibliothek sollte eine so einfache und leichtgewichtige Schnittstelle wie möglich haben. Ich brauche IoC nicht, da es nur eine Bibliothek (Menge von Funktionen) ist, kein Framework - also hat es mehr algorithmische Komplexität als strukturelle. Ich betrachte Akteure jedoch als ein gutes Instrument zur Beschreibung von Protokollen und kann den Algorithmus tatsächlich in kleine Mengen asynchron interagierender Entitäten zerlegen, so dass er zu meinen Bedürfnissen passt.

Warum nicht Akka

Akka ist schwer, was bedeutet:

  • es ist eine externe Abhängigkeit;
  • hat komplexe Schnittstelle und Implementierung;
  • nicht transparent für Benutzer der Bibliothek, zum Beispiel - alle Instanzen werden von akkas IoC verwaltet, so dass es keine Garantie gibt, dass ein logischer Akteur immer von derselben Instanz verwaltet wird, Neustart wird einen neuen erstellen;
  • erfordert zusätzliche Unterstützung für die Migration, die mit der Migrationsunterstützung von scala vergleichbar ist.
  • Es kann auch schwieriger sein, die grünen Threads von akka mit jstack / jconsole / jvisualvm zu debuggen, da ein Akteur auf einen beliebigen Thread reagieren kann.

Sicher, Akkas Glas (1,9 MB) und Speicherverbrauch (2,5 Millionen Darsteller pro GB) sind überhaupt nicht schwer, so dass Sie es sogar auf Android ausführen können. Aber es ist auch bekannt, dass Sie spezialisierte Werkzeuge verwenden sollten, um Akteure (wie Typesafe Activator / Console) zu beobachten und zu analysieren, mit denen der Benutzer nicht vertraut ist (und ich würde sie nicht dazu bringen, es zu lernen). Es ist alles in Ordnung für Enterprise-Projekt, da es fast immer IoC, einige spezialisierte Tools und kontinuierliche Migration hat, aber das ist keine gute Ansatz für eine einfache Bibliothek.

P.S. Über Abhängigkeiten. Ich habe sie nicht und möchte auch keine hinzufügen (ich meide sogar den Scalaz, der hier eigentlich ein bisschen passt), da dies zu einer hohen Wartung führen wird - ich muss meine einfache Bibliothek behalten up-to-date mit Akka.

    
dk14 26.12.2014, 13:43
quelle

2 Antworten

9

Hier ist der minimalste und effizienteste Schauspieler in der JVM-Welt mit API basierend auf Minimalist Scala von Viktor Klang: Zypern

Es ist praktisch und sicher in der Verwendung, aber es ist nicht typsicher beim Nachrichtenempfang und kann keine Nachrichten zwischen Prozessen oder Hosts senden.

Hauptmerkmale:

  • einfachste FSM-ähnliche API mit nur drei Zuständen ( Stay , Become und Die ): Ссылка

  • minimalistische Fehlerbehandlung - einfach passend zum Standard-Exception-Handler von Executor-Threads: Ссылка

  • schnelle asynchrone Initialisierung, die ~ 200 ns benötigt, um abgeschlossen zu werden, so dass keine zusätzlichen Futures / Aktoren für zeitaufwendige Aktor-Initialisierung benötigt werden: Ссылка

  • kleinster Speicherbedarf, dh ~ 40 Bytes in passivem Zustand (BT% new String() gibt die gleiche Menge an Bytes im JVM-Heap aus): Ссылка

  • sehr effizient in der Nachrichtenverarbeitung mit Durchsatz ~ 90M msg / sec für 4-Kern-CPU: Ссылка

  • sehr effizient beim Senden / Empfangen von Nachrichten mit Latenz ~ 100 ns: Ссылка

  • pro Schauspieler Tuning der Fairness durch den Batch-Parameter: Ссылка

Beispiel für Stateful Counter:

%Vor%

Ergebnisse:

%Vor%     
Andriy Plokhotnyuk 26.12.2014, 19:59
quelle
4

Dies wird FixedThreadPool (und damit seine interne Task-Warteschlange) verwenden:

%Vor%

FixedThreadPool mit der Größe 1 garantiert hier die Sequentialität. Natürlich ist es nicht der beste Weg, um Ihre Threads zu verwalten, wenn Sie 100500 dynamisch erstellte Akteure benötigen, aber es ist in Ordnung, wenn Sie eine bestimmte Anzahl an Akteuren pro Anwendung benötigen, um Ihr Protokoll zu implementieren.

Verwendung:

%Vor%

Ergebnisse:

%Vor%

Diese Implementierung verwendet zwei Java-Threads und ist daher "doppelt" schneller als das Zählen ohne Parallelisierung.

    
dk14 26.12.2014 13:44
quelle

Tags und Links