xuzhenbao commented on issue #515: URL: https://github.com/apache/celix/issues/515#issuecomment-1685541427
> Will the technology used for remote be plug-able and how? Maybe something like a distribution provider (as is used in Apache Aries, see https://aries.apache.org/documentation/modules/rsa.html) to make adding a new transport and serialization more easy. The technology used to publish remote events should be plug-able. IMO, it might be an event handler proxy and register an event handler service that subscribes to all local events and then pushes events subscribed by remote subscribers to the remote distributor. When the remote distributor receives a remote event, it sends the event to the event admin(use `sendEvent/postEvent`), and event admin publish remote event to subscriber. > Will discovery of remote event admins be supported? Or do we only support broker-like solution (MQTT, NATS, etc) (which does not need a discovery only a broker address). We could consider using a broker-like solution and then reuse the discovery of remote service(discovery_zeroconf,etc.) to announce the broker's information. If we use the solution of discovering remote endpoints, we don't know which publisher service endpoints will be created until the `sendEvent/postEvent` interface is called, unless we can get the publisher information in advance by some other mechanism > Do we add a wire protocol (as is currently done in pubsub)? This can be used to identify a protocol version (and thus detect if we are remote compatible), add a sync word (and maybe even detect byte order) and optionally provide metadata and/or message fragmentation. Could it be based on the remote technology used? If the remote technology is TCP/UDP, we should add a reusable wire protocol. If the remote technology is websocket, since websocket already support message fragmentation, is it possible for the distributor to define its own wire protocol (like `pubsub_websocket`)? > Are all events remote? Or is this a opt-in per event (e.g. with something like a event.remote=true property) or maybe with a special interface (RemoteEventAdmin). And do event handlers always receive local and remote events? I think event handlers should receive all events that they subscribe to, whether remote or local. If there are no remote subscribers, the event admin should not push the event to the remote, otherwise, it should push the event to the remote. Additionally, to distinguish between remote and local events, we can add an event property, such as `celix.framework.uuid`. And the property should be set by the event admin. > Will the `sendEvent` block until all event local and remote are processed? Will it have a timeout? We can start with implementing `sendEvent` to wait until all events are processed. At the same time, according to the OSGI specification [113.8.2](https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.event.html#d0e47607), we can use a blacklist, blacklisted handlers should not be notified of events. If a timeout is really necessary, we can add the new interface `sendEventWithTimeOut`. > Will the thread or thread used by postEvent be configured / plugable? we can use threadpool, and the max thread number can be configured by the property of event admin bundle. For event handlers that require a order of events, it should be ensured that its `handleEvent` method is executed in a single thread > Will remote events, pushed to event handlers on a single thread or multiple threads and is this configurable/plug-able? To ensure order of events, a single thread maybe be used for the same remote address, but multiple threads maybe be supported for different remote addresses. > As mentioned by Peng, can event handler provide back pressure? If so is this a separate service interface? We can use a blacklisting mechanism to limit or disconnect event handlers that take too long in the `handleEvent` method. If an event handler has cached events, it should manage the cached events. > Also as Peng mentioned, do we want to support QoS (best effort, reliable, etc) Considering the different requirements for event reliability in different scenarios, we can first implement two QOS policies: at most once, at least once (like MQTT). And set QOS as a property of event. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
