Equivalent of ResetInterface from Symphony DI

[Marian-Kechlibar]

Hi! I am starting this discussion based on the following short exchange of messages on the Czech Nette Forum:

https://forum.nette.org/cs/36737-fungovani-nette-ve-worker-modelu-kompatibilita

Basically, @mabar explained to me that in order to use Nette Dependency Injection in a worker model, something like ResetInterface would have to be supported. This is likely a lot of work, but perhaps I could contribute with some observations; I already have some experience with partial resets of the DI from my own testing micro-framework based on Nette Tester, where I switch contexts between users rapidly, plus from some experiments with FrankenPHP / Caddy and behavior of Nette under it.

I put together an experimental Docker-based server with FrankenPHP and I can offer it as a sandbox for experiments, too.

[mabar]

From my perspective, this is a 3 step process on Nette side:

Introduce a repository with DI contracts, containing the interface (let's call it e.g. ResettableService). Repository separate from nette/di will allow:

• compatibility of packages with older nette/di and resettable without hacks
• easier cross-compatibility with identical interface from other frameworks (this would be the only part with optional dependency hacks)

Add support to nette/di:

• method reset() to the Container class
  • reset would go through all already instantiated services (unlike getByType()) that implement ResettableService
  • this should ideally work also for dynamically added services and without option di > export > types enabled
  • for easier debugging, returning list of reseted services would be nice
• include also known resetable interfaces from other frameworks (Symfony, Monolog) to make at least some stateful libs work out of the box. And/or add some way to include these interfaces by configuration.
• I am not sure what to do about indirectly created services (factories) - perhaps we could start with a simple warning (ignorable per-service?) and, if needed, add some interface to hook into them (factories are mostly used for components, which are likely not needed to support and the compatibility work may be done in nette/component-model)
• Call Container->initialize() after reset? Nette starts session here, sets http headers, initializes cookies. Third-party packages may have similar use-cases.

Add support to all Nette packages:

• nette/bootstrap
  • probably the most complicated, it builds DIC based on the current request parameters
  • there must be no chance to mix-up different containers (debug/production, cli/webserver, ...)
  • some way of listing active containers and/or garbage collector for long-inactive containers would be helpful
• tracy/tracy
  • shutdown handler would need some alternative
• nette/application
  • Application - reset requests and presenter
• nette/http
  • Request - is created through RequestFactory and both Request and RequestFactory are replaced in tests and for CLI usage (to support generating links) therefore this may prove to be quite complicated to solve
  • Response - is commonly overriden in tests, adding reset to the IResponse would be helpful for extra safety
  • Session
• nette/security
  • User
  • UserStorage
• nette/caching?
  • MemoryCache could fill server memory fast and currently does not support conditional invalidation and we just have no way to know if the data stored here are safe to store across requests
• nette/routing (and extending classes in nette/application)
  • pretty much everything
• nette/database
  • finishing all transactions
  • Explorer - lastQuery, transactionDepth

It seems doable, but the amount of work is huge. I probably missed half the stuff that needs reset in individual packages, extensive testing would be needed, identifying common pitfalls in Nette apps, support in third party packages... ouch.

Also for the third party packages it would be nice to notify the mostly used vendors and add some tag to packages that are ready for workers, so everyone does not have to do their own research. This feature is mostly beneficial for high throughput apps in which enabling such feature while blindly believing all packages are ready is just too large risk.