Shoal Einstieg (Thema geändert zu Hazelcast)


#1

Ich habe noch nie mit JEE gearbeitet, wurde aber darauf aufmerksam gemacht dass das Projekt Shoal für die im anderen Thread angesprochene Simulation sehr interessant sein könnte.

Jetzt habe ich absolut keine Ahnung wo ich da anfangen sollte. Wenn ich das richtig verstanden habe ist Shoal Teil von Glassfish was Teil von JEE ist… ?
Dazu fehlt mir die Expertise, es wäre nett wenn mir jemand einen Jumpstart an Stichworten/Links geben könnte um mit Shoal arbeiten zu können.

Muss ich JEE können? Glassfish? Anderes? Gibt es gute Bücher oder Quellen dazu?

Vielen Dank


#2

Du möchtest also verteilt rechnen?

Ich habe mal bei Payara, einem Glassfish Fork reingeschaut, die sagen zu Shoal:

Due to some clustering and high availability issues in GlassFish 4.1 and low activity on the Shoal development repo, engineers have implemented Hazelcast into the core of Payara to provide robust session clustering.

Sie haben also die Shoal Implementierung aus der Codebase geworfen und durch Hazelcast ersetzt.

Was genau möchtest du denn tun? “die im anderen Thread angesprochene Simulation” sagt mir nichts.


#3

Vielen dank, genau solche Antworten habe ich gesucht. Solche Informationen liegen hinter meinem Horizont.

Im Moment läuft eine hoch parallellisierbare Simulation auf einem Zentralrechner, dem geht aber die Puste aus, und mehr Kerne geht nicht mehr, weil dann andere Overheadfaktoren in dieser Architektur Überhand nehmen.
Eine Alternative wäre die Simulation dezentral auf den selbigen low-end Maschinen laufen zu lassen von denen die Sensordaten als Input kommen und für die auch der Output berechnet wird.
Das könnte einige wichtige Overheadfaktoren eliminieren, aber das muss ein Prototyp zeigen.

Der Gedanke ging dann Richtung Java SE mit RMI oder EE REST Service.

An der Stelle wäre es nett wenn man keinen zentralen Server aufbaut, sondern die Maschinen untereinander ein dezentrales Netzwerk bilden, mit variabler Anzahl der Teilnehmer zur Laufzeit. <- Ganz ehrlich, das wäre der heilige Gral! Weil keine äußere Infrastruktur mehr nötig wäre.
Soweit ich weiß, war dass das Ziel von Shoal (dt. Schwarm).


#4

Eine andere Möglichkeit bei hoch parallelisierbaren Berechnungen ist über die GPU zu gehen. Da bräuchte es aber dann auch die entsprechenden Kenntnisse.


#5

Das Erste, was mir dazu einfällt, wäre spark.


#6

Das Problem während der Entwicklung ist, dass selbst kleinste Änderungen am Code eine Ausführung über die GPU sinnlos machen können. Das kann man sich am Ende der Forschungsarbeit überlegen, im produktiven Betrieb auf GPUs zu setzen hust was auch geplant ist hust.


#7

Klasse, schau ich mir näher an. Ist sogar gut dokumentiert! Top!

  • In-memory computing. Hört sich passend an :smiley:

#8

Wie schon erwähnt, da könnte Hazelcast das sein, was du suchst. Da könnte man vielleicht mal den @Noctarius antriggern, wenn er hier noch aktiv ist. Ich habe gehört, der kennt sich damit ein bisschen aus :stuck_out_tongue:


#9

Aktiv naja, ich lese hin und wieder mit und natürlich bekomme ich noch die Infomails wenn wer triggered :wink:

Klar kann ich versuchen aufkommende Fragen zu beantworten, ich bin seit Ende letzten Jahres aber selber nicht mehr bei Hazelcast, bzw helfe nur hier und da (z.B. jetzt JAX) mal aus.

Generell bei Fragen würde ich die (doch recht umfangreiche) Doku empfehlen oder über Google Groups bzw Stackoverflow oder den Gitter Channel direkt Fragen an das Team stellen :slight_smile:


#10

Ja, die Dokus, Beispiele und Demos sind vorallem echt klasse gemacht. Zeigt relativ schnell und einfach das Anwendungsszenario auf.

Soweit ich das verstehe findet der Shared-Memory über die mitgelieferten Maps und Queues statt. Einen eigenen Container über Hazelcast zu synchronisieren wird wohl nicht so einfach sein?
Es geht vorallem um ein Objektgrid, ähnlich einer mehrdimensionalen LinkedList, wenn man so will. Oder anders gesagt, ein n-dimensionales Array.

Desweiteren unterstützt Hazelcast leider keine Mesh-Netzwerke (ZigBee, Bluetooth, usw.), sondern läuft über TCP/IP. Eventuell liese sich das umgehen wenn die Geräte im Mesh-Netzwerk erst einen zentralen TCP/IP Router aushandeln, aber da bin ich noch unschlüssig. Vielleicht lasse ich sie auch erstmal über das lokale Netzwerk miteinander reden.


#11

Ich bin mir nicht ganz sicher was du machen willst, aber das hört sich nicht einem Hazelcast Use Case an. Hazelcast (wie alle IMDG) ist für Server entwickelt und verteilt die Daten gleichmäßig auf allen Cluster-Nodes. Ergo sind Remote Requests notwendig um an die Daten zu kommen (außer dem lokalen Anteil). Zusätzlich sollte das Cluster möglichst stabil sein, da sonst eine Datenmigration angestoßen wird um den fehlenden Knoten auszugleichen (ergo neue Backups erstellen und evtl wieder Gleichverteilung erreichen).


#12

Mag sein, auf der anderen Seite steht die Entwicklung eines proprietären In-Memory Mesh-Netzwerks, oder einer kruden Umsetzung mit rohen Sockets. Letztere haben vielleicht nicht einmal einen annähernd so hohen Netzwerkoverhead aber dafür ist Hazelcast verdammt einfach aufzusetzen, liefert die benötigten Funktionalitäten und unterstützt diverse Netzwerkstandards und Programmiersprachen. Ich werde es auf jedenfall vorschlagen.

Das ist in der Tat ein Problem. Das muss ich noch austesten wie sich Hazelcast in einem realen stresstest schlägt. Aber auf einem lokalen Rechner habe ich es bis jetzt noch nicht geschafft mehr als 2 Knoten miteinander zu verbinden. 4 Instanzen bilden immer 2 Cluster, 6 3, 8 4.

*Nebenbei ich weiß nicht ob ich eine zu utopische Vorstellung von IMDG hatte, aber ein automatisch serializiertes Objekt ist wohl nicht möglich, oder? Sprich, wenn ich ein Parameter eines Objektes (über Map geteilt) verändere, dass die Paramter auf den anderen Nodes entsprechend automatisch geupdated werden.


#13

Machbar ist das schon, mir Java Serializable, aber das willst du nicht einsetzen. Ansonsten kann ich Kryo (https://github.com/EsotericSoftware/kryo) empfehlen. Einfach, ohne viel manuelle Arbeit und durch einen ehemaligen Kollegen (Jaromir) auch schon voll integriert (https://github.com/jerrinot/subzero).

Trotzdem würde ich mir noch mal genau überlegen ob du wirklich ein IMDG wie Hazelcast nutzen willst. Also die Aussage wie Zigbee oder Bluetooth Netzwerke sind schauderlich, wenn ich an ein System denke, dass auf maximalen Speed (z.B. für Caches) ausgelegt ist.

Vielleicht willst du deinen Usecase mal ein wenig ausführen? Ich bin sicher, dass Hazelcast nicht das ist, nach dem du suchst. Aber wir finden bestimmt etwas für dich :slight_smile:


#14

Führen wir das mal aus:
Mehrere bewegliche wie stationäre Roboter-Systeme sollen mit ihrem Sensordaten-Input eine Echtzeitbewegungsimulation distributed berechnen.

Der Plan ist die Simulation räumlich auf die Teilnehmer aufzuteilen und an den Raum"nähten" die Ergebnisse auszutauschen.

Die Systeme sollen dynamisch hinzufügbar und entfernbar sein. Da wird keiner am Knopf sitzen und die Systeme wild an und abschalten.

Dafür ist die automatische Clusterbildung von Hazelcast sehr hilfreich und das Topic-System zum austauschen von Nachrichten.