mORMot Open Source

oz

Member

Registered: 2015-09-02

Posts: 98

SOA: ServiceUndefine/DeleteInterface

Hi Arnaud,

please have a look at my GitHub pull request at https://github.com/synopse/mORMot2/pull/72

Info:
I need the ability to switch Interface implementation factories at runtime.
TestCase is added.

King regards,
oz.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: SOA: ServiceUndefine/DeleteInterface

I have made comments on the pull request.

Nice work!

oz

Member

Registered: 2015-09-02

Posts: 98

Re: SOA: ServiceUndefine/DeleteInterface

All requested changes are done, commited and pushed for review.

Maybe *.lpi files should be added to git-ignore-files?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: SOA: ServiceUndefine/DeleteInterface

We supply a sample "official" .lpi file because it is easier to start with.
I suspect I could add it to the gitignore file, and force its update by hand.

oz

Member

Registered: 2015-09-02

Posts: 98

Re: SOA: ServiceUndefine/DeleteInterface

Would be handy. Otherwise everyone has to revert his local *.lpi file(s) before commiting. That's quite error-prone.

Edit:
Please also add to gitignore:
tests/data/*
tests/*.log
tests/*.res

Edit2:
I merged my cloned branch with mORMot2:master.
One of the last commits causes mormot2tests failing to compile (too many params)...
See pull request for fix: https://github.com/synopse/mORMot2/pull … 14c64369a4

Last edited by oz (2022-01-17 17:14:22)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: SOA: ServiceUndefine/DeleteInterface

I did revert your changes.
https://github.com/synopse/mORMot2/pull/73

Code added into TRestServerUriContext.ExecuteSoaByMethod slows down execution of regular methods, and I am not sure it is very stable about the actual methods process.
It is very unsafe to play with the method indexes once the server is initialized, because a lot of code rely on them to be stable enough.

I guess there are other means of dynamic registration of services.
The easiest (and safest) is to stop and restart the server.

oz

Member

Registered: 2015-09-02

Posts: 98

Re: SOA: ServiceUndefine/DeleteInterface

Code added into TRestServerUriContext.ExecuteSoaByMethod slows down execution of regular methods

I guess that's because of unnecessary MethodIndex recalculation after each callback.

Which testcase/benchmark did you use to come to that conclusion? I'll use that test for comparing my numbers and doing optimizations.

... and I am not sure it is very stable about the actual methods process.
It is very unsafe to play with the method indexes once the server is initialized, because a lot of code rely on them to be stable enough.

I just had a deeper dive into mORMot2 sources. You are right, current changes are not stable enough.
I'll try to do more modifications to make it stable and fast (including a heavy multi-threaded TestCase) just for curiosity, as soon as I'll find some time.
If everything will be stable without any performance penalties, then I'll do another pull request. If not, then i'll forget about dynamic service registration.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

Website

Re: SOA: ServiceUndefine/DeleteInterface

My guess is that the easiest is to be able to disable some methods once registered.
Not delete, but flag the method as disabled. So the indexes won't change, just the execution would be not allowed any more.