Listable vs. Java 8 Stream API
Author: bIT_sosswald
Publication Date: 12/7/2018 7:28
Hallo zusammen,
so wie ich es sehe gibt es keine native Möglichkeit die Java 8 Stream API auf FirstSpirit Objekten / Bäumen zu nutzen. - Oder etwa doch?
Hintergrund meiner Frage: Ich möchte in einem Modul z.B. alle PageRefs oder PageRefFolder, etc. durchlaufen und aus ihnen Daten extrahieren (reiner Lesezugriff, keine Schreiboperation) Um die Laufzeit zu optimieren würde ich dies gerne in einem ParallelStream machen um die einzelnen PageRefs etc. parallel auszulesen.
Über folgenden Aufruf bekomme ich alle PageRefs, allerdings nur in Form eines Listables.
Listable<PageRef> children = siteStoreRoot.getChildren(PageRef.class, true);
Listable implementiert allerdings die Stream API nicht, so dass ich nur über den alten Weg mit einem Itearor und einer while-Schleife über die Elemente iterieren kann.
Man könnte zwar ".toList()" aufrufen und dann per Stream API auf der Liste arbeiten, dies resultiert aber in einem Warning im Logfile und soll laut JavaDoc vermieden werden.
Gibt es eine saubere Möglichkeit eine große Menge an Leseoperationen auf einzelnen Objekten performant und parallel auszuführen? ParallelStreams wären dazu IMHO die beste Option.
Gibt es Pläne, dass die FirstSpirit API die Java 8 Stream API unterstützen wird?
Grüße
Sandro
Tags: access-api, api, listable, stream
-
Author: mbergmann - 12/10/2018 21:47
Hallo Sandro,
grundsätzlich kann man hier StreamSupport.stream(...) nutzen.
Stream<PageRef> parallelStream = StreamSupport.stream(children.spliterator(),true);Ohne hier selber in den Details zu stecken wäre ich aber eher skeptisch ob man hier Performancevorteile hat. Der Hauptanteil werden hier wohl eh IO-Operationen sein. Es muss letztlich eine bestimmte Menge an Daten gelesen werden, ob man das durch Parallelisierung schneller bekommt weiß ich nicht. Man müsste sich auch mal die Charakteristik des Spliterators ansehen - das Thema hat so seine Tücken, hier gibts da als Beispiel eine Diskussion dazu. D.h. es kann sein, dass da erst bei sehr vielen Objekten überhaupt erst mehrere Teil-Streams entstehen.
Interessanter wäre, was Du mit den Infos machst und vor allem von wo aus der Code aufgerufen wird (aus dem Client oder auf dem Server). Für den letzteren Fall würde es wahrscheinlich mehr bringen, diese Operation auf dem Server laufen zu lassen und dann nur das Ergebnis zu übertragen, z.B. durch Nutzung eines Auftrages oder auch eines ServerService.
Viele Grüße
Michael
0 -
Author: bIT_sosswald - 12/11/2018 7:20
Hallo Michael,
danke für die Antwort. An den StreamSupport habe ich gar nicht gedacht. :-)
Den höchsten Performanceeinfluss werden sicherlich die IO Operationen haben, aber wenn man diese parallelisieren kann, bringt das sicherlich was.
Prinzipiell geht es um das auslesen der gesamten Navigation inkl. Daten für Header und Footer für ein Integrationsszenario. (Andere Systeme sollen Header, Footer und Navigation aus FirstSpirit übernehmen.)
Wenn die Umsetzung über ein FS-Modul realisiert wird, dann sicherlich als Server-Service der über einen Auftrag getriggert wird. Clientseitig macht dass definitiv keinen Sinn. ;-)
Danke dir und Beste Grüße
Sandro
0 -
Author: mbergmann - 12/11/2018 7:39
Hallo Sandro,
ich kenne jetzt euer Szenario natürlich nicht, aber hast Du mal daran gedacht, das eher über einen Generierungsansatz zu machen, d.h. über ein spezielles Seitentemplate über die Navigationsfunktion? Je nach Szenario kann man das ggf. sogar parallel zur normalen (Voll-) Generierung machen indem man sich „nebenbei“ Infos in den ScheduleContext schreibt. Kommt natürlich auf die Datenmenge an.
Nur als Idee, muss in eurem Fall nicht unbedingt besser sein, wäre aber vielleicht flexibler weil man mehr über Templates arbeitet.
Viele Grüße
Michael
0 -
Author: bIT_sosswald - 12/11/2018 8:35
Hallo Michael,
Details zum Szenario gerne privat. :smileywink:
Aber ja, das ist eine andere Alternative an die ich gerade denke. Genau gesagt denke ich an eine Generierung über einen eigenen Ausgabekanal per UxB und dann eine Weiterverarbeitung / Speicherung der einzelnen Einträge per Adapter.
Ein einziges Seitentemplate für die gesamte Navigation und Heder/Footer Informationen würde ich eher nicht machen.
Prinzipiell werden die Datenmengen durchaus groß. Schon alleine wenn man an Contentprojektionen von News und Events und teilweise sehr viel statischen Content etc. denkt. Außerdem muss das ganze Konstrukt skalieren bzw. auf viele Projekte (gleicher Templatesatz) ausgerollt werden können.
In der Vergangenheit gab es bei dem Kunden schon einmal eine ähnliche Integration bei der die gesamte Navigationsstruktur über Templates generiert wurde. Das hat zu deutlich mehr Fehlern und Frust als Freude geführt. Schon allein dadurch, dass bei der Entwicklung von neuen / geänderten Templates darauf Rücksicht genommen werden musste. Damals haben wir das durch eine Modullösung abgelöst, die mit UnitTests und sauberem Errorhandling ausgestattet war und an der nicht jeder "normale Templateentwickler" einfach im Sitearchitect rumschrauben konnte. Daher ging mein erster Gedanke wieder in Richtung Modul... Damals gab es aber auch die UxB noch nicht...
Grüße
Sandro
0
Please sign in to leave a comment.
Comments
4 comments