Use waitset in pub-sub pattern

[strawberry-peanut-butter]

Hi folks-

I had a question about using WaitSet in the pub-sub pattern other than event. From what I understand,, Waitset can only be used with event pattern in the design.

Use case: I'm building an introspection service that continuously performs service discovery (assuming the message type is known). For each newly discovered service, a corresponding service instance and subscriber are created to receive and print the data. A naive approach would be to loop through all subscribers in a busy loop, calling receive() to poll for data. Ideally, I'd prefer a reactor-based approach where subscribers are woken up only when new data is available.

Assuming the publishers do not emit events upon publishing, is there a way to attach subscribers to a WaitSet to get notified when data arrives? Thanks!

[elBoberido]

@strawberry-peanut-butter what you try to build sounds quite like what @orecham is currently working on -> #674

It is basically a CLI tool that which offers a service with all the offered services in the system.

The service is required for gateways, which I assume is also what you want to build.

With iceoryx2, all messaging pattern, except the event messaging patter, are polling base. That means if you want to get notified about updates, you have to combine the publisher with a notifier and the subscriber with a listener. This gives you as a user the flexibility to mix and match the behavior to your needs.

Btw, if you want to create an introspection client instead of a gateway, that's also something we are currently working on.
Here is a sneak peak:

It's still in heavy development, but ekxide customer can already get privileged access to the tool.

[strawberry-peanut-butter]

Thanks @elBoberido for the explanation.
IIUC, achieving true event-based service discovery and message introspection requires the publisher to implement a notifier that emits an event whenever a message is published. This would allow the introspection or gateway service to be notified in real time instead of polling.
The gateway service is outside my scope but I am also building a basic recorder service on top of the introspection layer. The service should work with services w/o event.

My current design is:

1. Run service discovery on an async thread
   • add new service name to a shared container.
   • add schema info from service attribute associated with the service.
2. Main thread loop
   • create subscribers if there is new service added.
   • loop through all subscribers, receive data, and save to storage.

Do you see any opportunities to improve the design from a perf standpoint?

The introspection client looks interesting. I'll need to check on our side if we have access to it.

[elBoberido]

@strawberry-peanut-butter record-replay is also on our todo list :)

Depending on the publishing frequency, the queue sizes and how important latency is, it might be more performant to poll all subscriber, e.g. every 10ms. Alternatively, you can use the events with a waitset. Here, you also have to option to reduce context switches on the producer side, by triggering the events only every N transmissions, e.g. if your queue size is 10, send a notification with every 5th sample.

@elfenpiff @orecham you can probably provide more insight into these topics.

[elfenpiff]

Record & Replay using the iceoryx2 public API is problematic but fine for a first shot. The main issue is that the record influences the runtime, CPU load, and memory usage. Also, it is not possible to handle determinism at that level.
With the record and replay extension we are implementing we are addressing all of this.

[orecham]

Hi @strawberry-peanut-butter !

Such an "introspection service" (or something similar) has been on our radar since we require it to implement Gateways (as mentioned by @elBoberido). Coincidentally I had started to look into it last week and should have a first draft ready pretty soon.

Would be great to know your full requirements so I can ensure that they are covered - might save you the effort of implementation/maintenance. From your posts, I have understood the following:

1. Threads should be able to wait on waitsets and be woken up on new "introspection events"
2. The "introspection events" should include the following information:
   1. Service Name
   2. Service Attributes

Is there anything missing ? If you could specify the exact data your application requires about discovered services I can make sure it is included.

[strawberry-peanut-butter]

hi @orecham - I don’t have a comprehensive set of requirements for the introspection tool at this point. Right now, I’m working on a lightweight impl to support basic service discovery and data recording for our internal tools and applications using Iceoryx 2.

My main question in this thread was about enabling notifications on message arrival & service creation without relying on events, though I realize the discussion has broadened quite a bit since then 😄. I'll be happy to check out your first draft once it's available.