SkolemIriConverter isn't reset between requests in worker mode (missing kernel.reset tag)
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 1/5
- Tempo stimato
- Meno di un'ora
- Idoneità per principianti
- 85/100
Direzione di ricerca
Inizia dalla definizione del servizio api_platform.symfony.iri_converter.skolem nella configurazione del bundle Symfony, e da SkolemIriConverter, che implementa ResetInterface e contiene la proprietà objectHashMap. Verifica che al servizio manchi il tag kernel.reset, quindi conferma che la chiamata di reset sia collegata tramite services_resetter. È completato quando la mappa skolem della riproduzione è vuota dopo ogni reset.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
API Platform version(s) affected: 5.0.2 (also 4.4 and main)
Description
I've been upgrading one of our projects to API Platform 5 (Symfony 8.1, FrankenPHP in worker mode). One endpoint returns embedded objects that aren't resources themselves, so they get /.well-known/genid/... IRIs. With that endpoint, a single worker's memory kept growing until it hit our 128M memory_limit. It only took about five requests.
it seems the skolem IRI converter keeps an object → IRI map, and it is never cleared between requests.
I think the cause is that SkolemIriConverter already implements ResetInterface, but its service (api_platform.symfony.iri_converter.skolem) isn't tagged kernel.reset, so services_resetter never calls it. As far as I can see, it's the same in 4.4, 5.0 and main.
How to reproduce
- Create a resource that returns an embedded object which isn't itself a resource, so it gets a genid IRI. For example:
#[ApiResource(operations: [new Get(provider: [self::class, 'provide'])])]
final class Report
{
public string $id = '1';
/** @var Line[] */
public array $lines = [];
public static function provide(): self
{
$r = new self();
foreach (range(1, 500) as $i) {
$r->lines[] = new Line(str_repeat('x', 1000));
}
return $r;
}
}
final class Line
{
public function __construct(public string $text) {}
}
- Boot the kernel once and send several requests through it. Run the services resetter between them, as a FrankenPHP worker would:
$kernel = new Kernel('prod', false);
$kernel->boot();
$skolem = $kernel->getContainer()->get('api_platform.symfony.iri_converter.skolem');
$map = (new \ReflectionProperty($skolem, 'objectHashMap'));
for ($i = 1; $i <= 5; $i++) {
$response = $kernel->handle(Request::create('/reports/1', 'GET', server: ['HTTP_ACCEPT' => 'application/ld+json']));
$kernel->terminate($request ?? Request::create('/'), $response);
$kernel->getContainer()->get('services_resetter')->reset();
printf("request %d: %d skolem entries, %.1f MB\n", $i, count($map->getValue($skolem)), memory_get_usage() / 1048576);
}
- Expected: the skolem map is empty, or at least stays flat, after each reset. What happens: it grows by the number of embedded objects on every request (500, 1000, 1500, …), and memory grows with it. In our app it reached the 128M limit within about five requests.
- Add the kernel.reset tag (see the workaround below) and run it again. The map is cleared after each request, and memory stays flat.
Possible Solution
Add the tag where the service is registered:
->tag('kernel.reset', ['method' => 'reset'])
Additional Context
Workaround for now
override the service definition ourselves for api_platform.symfony.iri_converter.skolem to add the tag
With that in place, memory stays flat across requests.
I'll raise a short PR
- Lingua principale
- PHP
- Stelle
- 2.6k
- Fork
- 989
- Merge medio
- 1g 19h
- PR unite (30g)
- 87
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di api-platform/core
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 54/100
api-platform/core#8664 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[Metadata] Incorrect api schema for path variableForse già presa @bram123 l’ha presa 2 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
api-platform/core#8646 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
DenormalizationViolationFactory crash when GroupSequence is usedForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 64/100
api-platform/core#8639 ·
I maintainer di solito rispondono entro 1 giorno
-
HTTP cache purgers error handling and performance issuesForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
api-platform/core#8591 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
api-platform/core#8535 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di api-platform/core
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Automattic/blocks-engine#2803 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
hestiacp/hestiacp#5798 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
woocommerce/woocommerce-google-analytics-integration#699 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wp-media/imagify-plugin#1289 ·
I maintainer di solito rispondono entro 5 giorni
-
Sidebar highlights two items when plugin routes share a prefix (/plugin/foo and /plugin/foo-bar)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
getgrav/grav-plugin-admin2#195 ·