Hi Roman,
On 14.05.20 11:31, Roman Iten wrote:
So far so easy. Now imagine that server is a child of server_init and client is a child of client_init. Both init's are siblings. I would expect that still client - and only client - has to pay for the server-side allocations. But the session creation fails when client_init and/or server_init assigned all of it's resources to it's children (RAM/CAP quota saturation).
your intuition is completely right. The client should pay. That's the way it should work. That being said, two heads-ups from my side:
First, the server_init approach is still rather sparsely used. In contrast to regular servers, the accounting of session resources has not been stressed much in this scenario. So maybe you're hitting a corner case not covered so far.
Second, the intermediate init instances need to maintain meta data about the sessions. The memory for this metadata is meant to be drawn from the client-provided session quota when forwarding the request towards the server. However, the calculation of quota is performed at a sub-page granularity whereas the allocations of meta-data objects always work on a multiple of pages. This is why the RAM preservation comes into play. It gives init some room to breath.
I'd be interested in knowing how exactly the session creation fails. Can you be more specific about what happens? Or can you share a minimally complex example scenario so that I can have a closer look?
Cheers Norman