[Koha-bugs] [Bug 31074] Cached plugin code is used in Koha even after changes to plugin (install/upgrade/uninstall)

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31074

--- Comment #29 from David Cook <dcook at prosentient.com.au> ---
(In reply to Victor Grousset/tuxayo from comment #28)
> :( Too bad. Thanks for the real world knowledge. I was hopping the actual
> compile would happen on the 1st request.

The "plack.psgi" file gets processed each time a worker process is started. If
you restart/reload Starman for a large number of instances, you'll end up with
a lot of processes trying to use 100% CPU all at the same time (as the API is
slow/intensive to launch).

> Also, are there cases of a single main starman for all workers of a large
> shared hosting? Or would that be a bad setup and we don't have the duty to
> worry about instances that went out of their way to achieve this? And for
> such a setup, instance wide reload might not be a paralyzing load because
> *hopefully?* when spawning many workers at the same time from the *same*
> main starman process, it might not compile 100 times Koha's minimal base
> code but only once and they fork 100 time almost for free. (the last is
> suppositions, if not waiting for requests to do the compiling, then it would
> make sense to benefit for mutualising compiling work)

We'd need to "preload" the base code, which we don't currently do in Koha, in
order to get that benefit of compiling once and then forking many times for a
cheaper cost. (I have a mod_perl app where I preload my app into the master
process, and it makes the app workers start and run very fast.)

I think we make quite a few assumptions in the Koha code too which ties each
Starman worker to its particular instance.

Bug 20630 looks at doing multitenancy with Mojolicious but it stalled a while
ago.

I think a multi-tenanted Koha would be great, although there is a danger of
cross-contamination. You have to manage variable scope and caches very
carefully.

> It still happens on it's own every 100 queries by default (50 X the number
> of workers, 2 by default) on most Koha's right? And can be triggered by
> someone knowing that it existing like as a way to mitigate this very issue.
> install/upgrade/uninstall a plugin and spam F5 on a light page to make the
> operation effective ^^"
> 
> What bad stuff could happen if an end user (managing plugins) can trigger a
> worker reload?

It would make for a very very easy denial of service, but it's true that
someone can still do a DOS by just sending a high volume of high impact
requests anyway. 

This is another case where multi-tenancy would be a problem. If one end user
could trigger a worker reload on a multi-tenanted server, it would cut out for
everyone. At least in this case it's isolated to their own Koha instance.

-- 
You are receiving this mail because:
You are watching all bug changes.