Queue und (kein) Dataflow

(29.05.2015 12:03 )Trinitatis schrieb:  Der Vorteil bei der Verwendung der FGV liegt halt darin, dass es diese nur einmal gibt. Und darin kann ich ja auch mehrere Queuereferenzen verwalten.

Die Verwechslungssicherheit stelle ich über die Nutzung immer derselben FGV mit eindeutiger Namensgebung der Queue-Referenzenausgänge (wenn es denn mehrere sind)
Im übrigen muss ja auch der Datentyp passen - ich kann also nicht 2 verkehrte Queue-Referenzen miteinander verknoten, wenn deren DTyp nicht gleich ist.


Gruß, Marko

Bei der Frage ging es doch scheinbar um Skalierbarkeit auf sehr viele Queues mit unterschiedlichsten Namen. Wenn ich die in ner FGV mit ka 3 Ausgängen für die 3 Queues die ich möchte verwalten kann, dann kann ich auch gleich eindeutige Namen für die Zuordnung verwenden und mir darüber die Queues holen. Hab ich aber 100 Queues und bin mir deswegen nicht sicher ob es nicht doch mal bei der 101. zu ner Namenskollision kommt, dann ist meiner Meinung nach der FGV Ansatz genausogut / schlecht wie eindeutige Regeln zur Namensgebung. Schließlich kommt man bei so vielen Queues letztlich nicht umhin irgendwie anzugeben, welche genau man grade anfragen will. Und dann is man wieder dabei, dass man aus der FGV über nen Namen ne Queue Referenz holt - das kann LV numal auch schon mit Bordmitteln ohne FGV. Alternativ könnte man sicherlich auch nen Cluster bauen in den man alle Queue Referenzen reinpackt, dann dürfte sich LV vermutlich zumindest regen, wenn man eine Neue Queue identisch bezeichnen möchte. Allerdings wird auch das bei vielen Queues sicher schnell unübersichtlich.

Deswegen meiner Meinung nach: Wenn man durch sinnvolle Namensgebungsregelungen (Was weis ich; [Funktionsbeschreibung]_[VIName]_[Projekt]_[Out|In]) oder whatever sicherstellt, dass es eigentlich nicht zu Kollisionen kommen kann, dann fährt man genauso gut / schlecht wie mit der FGV. Will damit nicht sagen das die Idee schlecht ist; im Gegenteil, so kann man gut eine begrenzte Zahl an "Informationen" / Startparametern in den VIs verteilen bzw. zur Verfügung stellen. Nur löst die halt nicht wirklich das Problem Skalierbarkeit. Da würde man sich dann eher nen System anbieten, dass möglichst unabhängig von der Bezeichnung ist.
An sich (habe noch nicht damit gearbeitet) scheint da doch fast das Actor framework die passende Lösung für das Problem zu sein. Soweit ich das überblicke ist da doch grade die Idee, dass jedes Objekt als Akteur gehandhabt wird, mit dem man reden kann (intern über Queues). Die Verwaltung der entsprechenden Verbindungen ist da doch auch schon vereinfacht gehandhabt meines Wissens.

Tl; dr: Die FGV Lösung skaliert meiner Meinung nach genauso schlecht bei vielen Queues (und grad um Skalierbarkeit gings hier ja) wie das anfordern von Queues über einen eindeutigen Namen. Interessant für das eigentliche Problem könnte eventuell auch ein Blick auf das Actor Framework sein.