Behaviour when trying to access the payload after responding

[MaryamZi]

Description:
$title.

Steps to reproduce:

import ballerina/http;
import ballerina/io;

service foo on new http:Listener(8080) {

    @http:ResourceConfig {
        methods: ["POST"]
    }
    resource function bar(http:Caller caller, http:Request req) {
        var result = caller->respond("Accepted!");
        io:println("BAR");
        io:println(req.getJsonPayload());
        io:println("BAR2");
    }
}

When invoking the service, execution seems to hang at req.getJsonPayload() eventually resulting in a timeout error.

$ curl -v http://localhost:8080/foo/bar -d '{ "name": "Anne", "age": 25 }' -H "Content-Type:application/json"

$ ballerina run foo.bal 
[ballerina/http] started HTTP/WS listener 0.0.0.0:8080
BAR
error {ballerina/http}GenericClientError message=Error occurred while retrieving the json payload from the request cause=error {ballerina/mime}ParsingEntityBodyFailed message=Error occurred while extracting json data from entity: No entity was added to the queue before the timeout
BAR2

As pointed out by @arukshani, this works if we've accessed the payload prior to responding.

Is this the correct behaviour?

• don't we allow accessing the payload for the first time after responding?
• if we don't do we still need the timeout?

Affected Versions:

$ ballerina -v
Ballerina 1.0.0
Language specification 2019R3

[arukshani]

Since we are clearing out the leftover HTTP content once the request-response transaction is over, to avoid memory leaks, if the user tries to access the request payload for the first time after respond, at least we should send an error instead of letting it to hang.

If we move the clearing out part of the HTTP content at the end of resource execution, this might work. But prior to doing that we need to investigate all the consequences.

There's a 'dirty' flag we maintained for the outbound request (when the outbound request is used more than once by a client/clients). May be we could use the same mechanism for inbound request as well.

[chamil321]

The reason for releasing content at the final state of response path is to avoid potential memory leak ( ballerina-platform/ballerina-lang#12815 ) which can occur when the request is not dispatched to a particular resource.

One thing we can do is moving that content release to all possible inbound request failure paths.

[chamil321]

The reason for releasing content at the final state of response path is to avoid potential memory leak ( ballerina-platform/ballerina-lang#12815 ) which can occur when the request is not dispatched to a particular resource.

One thing we can do is moving that content release to all possible inbound request failure paths.

And do a load test by monitoring memory behaviour in following cases

1. Successful return value from resource flow
2. checkpanic from resource flow
3. Dispatching/data binding response flow
4. OPTIONS call response flow

[ayeshLK]

Following are the load test profiling results for above scenarios after proposed changed. (Load test concurrency 50)

1. Successful return value from resource flow
   

2. checkpanic from resource flow
   

3. Dispatching/data binding response flow
   

4. OPTIONS call response flow
   

As per the load testing results no memory leak was found hence the proposed implementation will be added to code base.

[chamil321]

Reopen due to #1731