Olympia and freeing up EventData and EventUserData

delphi

(estebanp) #1

Hello there,

Delphi Tokyo, latest RODA. Olympia Server Session and Event repository running on MSSQL 2016.

We are finding an interesting behaviour with Olympia not freeing up the EventData and EventUserData table.

The situation goes like these, one service starts up and does an invoke AsyncEx to another service to subscribe to receive event sinks every 30 seconds or so. If the service being called is down, the message goes nowhere and because it is an invoke AsyncEx we will not get an error message or a return message on the call back method. That is fine.

Now, If the service that does the publishing of sinks is started (the one that was originally down), it will start sending the required sink to any other service that registers after but somehow everytime it sends the message out there is also adding a line to the eventuser and eventuserdata table with the same guid everytime.

The pattern will be on EventData table it will put a different guid on EventId but on Origin it will put the guid of the publishing service (itself). There will also be a line on the EventUserData table, but this one will be the guid of the originally started service (the one that started while the publisher was down) guid on event user and the eventid of event data.

It will continue to add a line on every sink until the session that originated the async call is terminated (which it doesnt happen because is a 24x7 service) so we end up with thousands of rows never cleaned up.

It could be that the async call finally reaches, or something, no idea what to suggest or say on that one. We had to remove the async calls in the meanwhile.

Thank you.


(estebanp) #2

Additional data: The call back request never returns. (some extra testing I just did).

More details, both services have assigned an Olympia Server and event repository component (they have their own events). Dont think it has anything to do with it, but more details.


(antonk) #3

Well, that’s interesting.

Correct me if I am wrong:

  1. Given that everything works with sync calls it is not a bug in the logic of your service(s)
  2. Given that everything works with sync calls it is not a bug in the Olympia. In that case the same behavior would be seen regardless of the sync or async calls on the Delphi side, as Olympia is completely separated from the Delphi code and is managed by calls from it
  3. So the issue is somewhere around the place that performs the initial call and depends on different behavior of sync and async calls

Am I right?

The 1st question is which exactly channel is used to perform the initial inter-service call? Is it a Super- or Simple- channel?