openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: How to pass size the max size of the request to the runtime?
Date Tue, 11 Sep 2018 18:15:22 GMT
It all depends on the details of the implementation , but eventually the proxy process needs
to parse the json string and pass down to the function, the function as user write them don’t
assume partial chunks 

But I general I tend to agree with Markus on no hard limits if possible and let surrounding
environment the limits if any. 

- Carlos Santana
@csantanapr

> On Sep 11, 2018, at 9:43 AM, Rodric Rabbah <rodric@gmail.com> wrote:
> 
> I assume Michele is referring to a buffer to eventually hold the function’s input (which
is limited to 1MB by default though some deployments use 6MB) - not a transient/intermediate
buffer. We’ll see...
> 
> -r
> 
>> On Sep 11, 2018, at 6:30 AM, Markus Thömmes <markusthoemmes@apache.org> wrote:
>> 
>> Heya,
>> 
>> I tend to agree with Felix. Buffers are usually just used as a transport
>> mechanism and they shouldn't need to fit the whole response at once (which
>> doesn't imply we don't load the response in memory, but at least that input
>> buffer doesn't need to be == content-length). Could you give a bit more
>> context on what the scan buffer does and why 64k isn't enough space to do
>> what we need?
>> 
>> Moreover, I'd rather not set any hard limits on the runtimes themselves.
>> The limits should be imposed by the surrounding system, the user-containers
>> could accept however much payload as they can fit. That reduces the amount
>> of configuration and testing needed. If we start imposing these limits on
>> every layer, we'll need to test every layer to correctly impose the limits.
>> 
>> Cheers,
>> Markus
>> 
>> Am Di., 11. Sep. 2018 um 15:08 Uhr schrieb Felix Meschberger
>> <fmeschbe@adobe.com.invalid>:
>> 
>>> Hi
>>> 
>>> Holding the complete input in memory ? Sounds like a good DoS surface -
>>> unless you limit the input size....
>>> 
>>> Regards
>>> Felix
>>> 
>>> --
>>> Creative typing support courtesy of my iPhone
>>> 
>>> Am 11.09.2018 um 15:02 schrieb Rodric Rabbah <rodric@gmail.com<mailto:
>>> rodric@gmail.com>>:
>>> 
>>> The http post will have a content length is that useful?
>>> 
>>> -r
>>> 
>>> On Sep 10, 2018, at 7:45 AM, Michele Sciabarra <michele@sciabarra.com
>>> <mailto:michele@sciabarra.com>> wrote:
>>> 
>>> Hello, I am in the process of running the mandatory tests against the Go
>>> Runtime.
>>> In the process, I fixed a lot of bugs, because those tests revealed a
>>> number of details about encoding, env variables and other things that were
>>> not obvious to me in the first place.
>>> 
>>> Now I have a problem: I am trying to pass the test that tried to send a
>>> one-megabyte big request to the runtime.
>>> Currently, it does not work because I discovered the "scan" buffer has in
>>> Golang a fixed size of 64k.
>>> 
>>> Of course, I can increase it but I need to know how big it must be. I know
>>> that you can set some parameters at OpenWhisk level but I am not aware how
>>> a runtime can know those parameters. Most notably I need to be able to read
>>> the maximum size of the requests because I need to allocate a buffer at
>>> init time. Any hints?
>>> 
>>> 
>>> --
>>> Michele Sciabarra
>>> michele@sciabarra.com<mailto:michele@sciabarra.com>
>>> 

Mime
View raw message