Community
Participate
Working Groups
We currently have one event bus / OSGi-Instance which makes e4 unusable in a multi-user/multi-instance deployment (e.g. RAP comes to my mind). We should discuss if and how we can address this problem.
The general answer to singleton problems in e4 is to put service in a context and then consume it from a context. All event services use contextual information. The e4-level code finds event bus implementation from the context. Should you put a different implementation of EventAdmin in the child context, that one will be used by objects injected with the child context. (This is the picture of how it should be; the whole area needs some attention and I would not be surpirsed if the statement above would not not 100% describe what the code is doing today). So, at least conceptually, there is no restriction for the event bus to be a singleton. If anything, the problem is the opposite: if you have multiple event buses, how do you organize event sharing between them.
(In reply to comment #1) > The general answer to singleton problems in e4 is to put service in a context > and then consume it from a context. > > All event services use contextual information. The e4-level code finds event > bus implementation from the context. Should you put a different implementation > of EventAdmin in the child context, that one will be used by objects injected > with the child context. I would have expected that the default e4 would bring up an EventBus / Workbench-instance but currently there's only one for the complete OSGi-Instance which != the number of Workbench-Instances if I read the code appropriately. > > (This is the picture of how it should be; the whole area needs some attention > and I would not be surpirsed if the statement above would not not 100% describe > what the code is doing today). > > So, at least conceptually, there is no restriction for the event bus to be a > singleton. > > If anything, the problem is the opposite: if you have multiple event buses, how > do you organize event sharing between them. I don't see a reason why workbench W1 should get events from W2. Leaving the performance impact aside (think about 100 Workbench Instance which is nothing strange for things like RAP) how would W1 know that the event is coming from W1 or W2?
Created attachment 218732 [details] Make EventBroker App-Instance aware This is an idea that just came to my mind. If we publish an instance id in our E4Application we can isolate events in the evenbroker so it can be used directly in a multi-user event.
(In reply to comment #3) > This is an idea that just came to my mind. If we publish an instance id in our > E4Application we can isolate events in the evenbroker so it can be used > directly in a multi-user event. Great - this should solve the problem for RAP. As soon as I find the time, I will try your patch with RAP and give feedback. I wonder if the String concatenation and filtering could have a performance impact, but I don't know how frequently events are being sent over the event broker... I guess it is used for things like selection service, part activation, etc, right?
(In reply to comment #4) > (In reply to comment #3) > > This is an idea that just came to my mind. If we publish an instance id in our > > E4Application we can isolate events in the evenbroker so it can be used > > directly in a multi-user event. > > Great - this should solve the problem for RAP. As soon as I find the time, I > will try your patch with RAP and give feedback. > > I wonder if the String concatenation and filtering could have a performance > impact, but I don't know how frequently events are being sent over the event > broker... I guess it is used for things like selection service, part > activation, etc, right? My hope is that the EventAdmin does build an intelligent internal structure of the topics and so the overhead should not be noticeable. I'll try to do some peformance testing to see if this change impact performance We are sending all model changes, ... through the event bus (e.g. part changes). Selection change in contrast are directly done through the IEclipseContext because they are isolated to a certain context (e.g. the perspective or window)
I guess the patch only solves half of the problem and the same has to be done to the @EventTopic/@UIEventTopic stuff but before we need to solve #390346
What is the status here? Bug 390346 has been fixed in the meantime. I'm not sure if the problem still exists because of the fix of bug 374534 where IEventBroker instances are being created per context.
Tom, I saw your comment that M6 solved all RAP issues. Can this be marked as fixed?
no i'd like to keep it open - we have a solution by overloading the EventBroker but in the ideal case I'd like the platform event-broker work appropriately by default
Please reopen if you plan to provide a Gerrit.
