Closed g-ra closed 3 months ago
I did a bit of research, and I'm not sure this module is compatible with frankenphp. The souin cache is meant for reverse proxies, and there isn't any reverse proxy in frankenphp.
+1
So, what is the cache option with a frankenphp
+ apiplatform
+ vulcain
default implementation?
I was following this doc: https://api-platform.com/docs/core/performance/#built-in-caddy-http-cache
But I got the same seg violations after getting it to build at all. It turns out the Caddy Cache-Handler is the culprit.
i have same issue, I tried to install without the souin module, what are the currently possible installations of caching from apiplatform?
Souin can be used with FrankenPHP/API Platform.
This issue looks related to Souin, not to FrankenPHP. Maybe @darkweak knows what's going on. Otherwise I'll try to take a look when I'll have some time.
Hello there.
I did a bit of research, and I'm not sure this module is compatible with frankenphp. The souin cache is meant for reverse proxies, and there isn't any reverse proxy in frankenphp.
Souin is a caddy module, so, it should be compatible with frankenphp.
I don't see any Souin related content in the stacktrace/logs you posted @g-ra.
TBH I didn't try the stack frankenphp + souin + api invalidation.
Can you give me more details about the error above? Does it occur on the first request or after a while?
@darkweak I apologize, but I have dropped all the errors that I had
the error is repeated with each request, but it allows, for example, to execute basic cache reset commands in the console php bin/console ca:clear
here is repo for demonstration error https://github.com/g-ra/ISSUE-944-apiplatform
use not ARM proccessor
docker compose up -d --build
just try http://localhost/docs
open php logs
Seen together with @g-ra and it seems to be working. We can probably close this @dunglas.
Thanks! Would you mind explaining what you've done for next readers?
The storage refactoring solved that (so actually only available on the master branch in the Souin repository).
I saw in the logs a reference to otter
that is a supported backend storage and IMHO that library don't like CGO.
2024-07-29 13:50:48 /usr/local/go/src/sync/cond.go:70 +0x85 fp=0xc0000a3d00 sp=0xc0000a3cc0 pc=0x56511507f645
2024-07-29 13:50:48 github.com/maypok86/otter/internal/queue.(*Growable[...]).Pop(0x565117c5ec60)
2024-07-29 13:50:48 /root/go/pkg/mod/github.com/maypok86/otter@v1.2.1/internal/queue/growable.go:71 +0x74 fp=0xc0000a3d98 sp=0xc0000a3d00 pc=0x56511649a894
2024-07-29 13:50:48 github.com/maypok86/otter/internal/core.(*Cache[...]).process(0x565117c849c0)
2024-07-29 13:50:48 /root/go/pkg/mod/github.com/maypok86/otter@v1.2.1/internal/core/cache.go:386 +0xe8 fp=0xc0000a3fc0 sp=0xc0000a3d98 pc=0x565116498728
2024-07-29 13:50:48 github.com/maypok86/otter/internal/core.NewCache[...].gowrap2()
2024-07-29 13:50:48 /root/go/pkg/mod/github.com/maypok86/otter@v1.2.1/internal/core/cache.go:167 +0x25 fp=0xc0000a3fe0 sp=0xc0000a3fc0 pc=0x56511648f585
2024-07-29 13:50:48 runtime.goexit({})
2024-07-29 13:50:48 /usr/local/go/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000a3fe8 sp=0xc0000a3fe0 pc=0x56511505e781
2024-07-29 13:50:48 created by github.com/maypok86/otter/internal/core.NewCache[...] in goroutine 1
2024-07-29 13:50:48 /root/go/pkg/mod/github.com/maypok86/otter@v1.2.1/internal/core/cache.go:167 +0x6b3
That's not verified but that's the only thing related to souin and the fact switching to the refactored storages that only embed needed backend storages solved this, so this seems to confirm my idea.
For those who want to use the working version (while awaiting the next release), you have to use the following modules:
--with github.com/darkweak/souin/plugins/caddy@8afe9436a62d51f1d403a0896be83db535ccc49c \
--with github.com/darkweak/souin@8afe9436a62d51f1d403a0896be83db535ccc49c
and read the documentation here (https://docs.souin.io/docs/middlewares/caddy/#storages) to learn more about the storages.
@darkweak thanks! For the record, FrankenPHP also uses otter internally (which plays well with cgo). Maybe there was a version conflict or something?
What happened?
i got errors from default Dockerfile from docs perfomance cache-handler
stacktrace.txt
here is my Dockerfile
Build Type
Docker (Debian Bookworm)
Worker Mode
Yes
Operating System
macOS
CPU Architecture
x86_64
PHP configuration
Relevant log output
External changes