Skip to content

Releases: signalpillar/nameko-injector

[bugfix] Prevent memory-leak in request scopes (#6)

20 Oct 13:59
8cd4bd7
Compare
Choose a tag to compare

Problem

corolocal.local keeps references to all the coroutines (green threads) and the
resources allocated in the scope for that thread. It prevents GC collecting used
injectables.

Solution

Manually clean scope storage in the end of each
request (NamekoInjectorProvider.worker_teardown)

Request as builtin dependency

04 Oct 06:15
58fefa0
Compare
Choose a tag to compare

Context

It's so common that other dependencies depend on HTTP request object that we
need to provide one by default. For instance other dependencies may take some
data from the headers of the request or arguments.

Solution

Bind the request instance to werkzeug's class that is used by nameko.
Do it right in the nameko provider - no need to build a provider that depends on
nameko worker context etc.

The only problem was that with my current approach using parent-child injector - it doesn't work. All the providers defined on parent that depend on request cannot access that request, because parent injector doesn't know about children.

Now we don't create child injector but instead put the current request directly in the scope, same happens with worker_context. Only when testing test_injector we use child injector.

Testing

Test case provided.

New scope to close resources in the end of request

27 Sep 21:51
0b54723
Compare
Choose a tag to compare

Problem

Some resources in request scope need to be closed (freed). It's not currently
supported.

Solution

Create a new type of scope that's aware about resources with 'close' method.
Name of this special method is hardcoded. Probably we could use protocol in this
case - Closable.

It's a separate type of scope to make the fact that resource will be closed more
explicit. When one of the resources cannot be closed, the failure will be logged
but teardown call is not failed so the rest can be closed.

Second change is that ServiceContainer is now in singleton scope as it
should be.

Testing

Added test cases.

Fix request scope (#3)

26 Sep 21:27
b2060d5
Compare
Choose a tag to compare

Fix request scope (#3)
Problem

Provider result in scope of the request is not cached therefored each time we try to
access an object we get a new instance of it when callable provider is used.
It's not a desired behaviour. Instead we should get the same object regardless
how many times it's injected.

Decision

Use eventlet.corolocal storage. It's like threadlocal but for coroutines.

Testing

Added test cases to ensure that we inject the same objet that is bound in
request-scope.

Use child injectors on each service call

24 Sep 20:26
9096430
Compare
Choose a tag to compare

Problem

It's not safe to bind WorkerContext to the injector used in the class of the
service as it will potentially conflict with different from other call.

Decisions

  • Do not use Mapping in the NamekoInjector init. It's not really useful. Take
    the same arguments as injector.Injector.
  • Use child injectors on each service call to bind WorkerContext and that child
    injector is used to resolve the dependencies for the entry point method.
    Document better code.
  • Improve pytest fixtures
  • Rename scope from request to request_scope, it's less ambiguous.

Docs

Readme updated with some details about the available fixtures.