Open torblerone opened 3 years ago
Same issue here.
$ fission version
client:
fission/core:
BuildDate: "2021-12-29T03:57:30Z"
GitCommit: 327275d1
Version: v1.15.1
server:
fission/core:
BuildDate: "2021-12-29T03:57:30Z"
GitCommit: 327275d1
Version: v1.15.1
We are using fission/php-env:1.31.1
as an environment image.
Same thing happening to us unfortunately.
Had the same issue. Found the solution!
Function works exactly once per pod started.
in server.php
change:
require_once $codePath;
to
require $codePath;
@sanketsudake
@sanketsudake please check the pull request https://github.com/fission/environments/pull/292
there is also a PHP8.2 environment which has this issue fixed https://github.com/checkin247/fission-environments/tree/php8-2
in case someone is interested, its a fork of the php7 environment.
Fission/Kubernetes version
Kubernetes platform (e.g. Google Kubernetes Engine) k3s Describe the bug
When I create a PHP environment like so:
and deploy a basic function to it:
and then try to run it multiple times:
You can see in the output that the function does not get called cleanly everytime and often does not respond with the "Hello from PHP" as expected:
To Reproduce
Install fission via Helm (without Prometheus) as provided in the Official Documentation. Then do above steps.
Expected result
I want to make sure that every function call gets answered in a proper way. Thus, every call from above should be responded with "Hello from PHP".
Actual result
Only sporadically, the function gets called and I get a correct response.
Screenshots/Dump file
If needed, please tell me if you need a dump for this issue and what exact files are needed. I need to make sure that sensitive company informations are omitted.
Additional context
I noticed that everytime I get a correct response
Hello from PHP
, a new poolmgr Pod is being created. Maybe it's an issue that the PHP environment never closes the request properly and is only capable of answering exactly one request?Edit: I've also tried it with your standard
python-env
and was not able to reproduce this issue there. It must have got to do something with that specific container image.