-1 on separate process, affects performance
- Carlos Santana
@csantanapr
> On Mar 29, 2020, at 5:17 AM, Michele Sciabarra <mich...@sciabarra.com> wrote:
>
> The subprocess is intialized with environment variables. That works.
>
> The problem is that after the process is launched, it starts the "action
> loop" of reading a line for each action activation, that includes some values
> that are always different and are passed as environment variables.
>
> Launching a process for each requests is what the older "docker support" was
> doing. And no, it is horribly inefficient even for fast C programs. And for
> java, that also has a long startup time, would be terrible.
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
>
> ----- Original message -----
> From: Matt Sicker <boa...@gmail.com>
> To: dev@openwhisk.apache.org
> Subject: Re: Discuss how to set environment variables in Java11 and more...
> Date: Saturday, March 28, 2020 5:36 PM
>
> I think Java broke up environment variables and system properties to allow
> for a more fine grained permission model of who is allowed to edit them and
> read them, hence the overly locked down API for it.
>
> Would it be feasible to launch a sub process with the environment variables
> initialized? Or would that be too much overhead for this use case?
>
>> On Sat, Mar 28, 2020 at 09:31 Rodric Rabbah <rod...@gmail.com> wrote:
>>
>> We should not change this for java8. For Java 11 since it’s new, it would
>> be ok to make the change but only for the activation context. Since init
>> time env vars can still be set by the proxy.
>>
>> Another approach since something will change for 11: introduce the context
>> object for java methods that want these variables (alternate signature)
>> which matches aws lambda.
>>
>> -r
>>
>>> On Mar 28, 2020, at 7:34 AM, Carlos Santana <csantan...@gmail.com>
>> wrote:
>>>
>>> Would this be for a new kind “java:11” not affecting existing java
>> kinds?
>>>
>>> Then will affect only someone migrating a java action from using java:8
>> or java:8a to use java:11? then it would be a good time to also clean up
>> how it access this variables/properties if for any chance is using them in
>> existing kind.
>>>
>>> there is no java sdk in openwhisk like the one from node.js
>>>
>>> Can’t think what other areas of openwhisk or use cases this will affect.
>>>
>>> - Carlos Santana
>>> @csantanapr
>>>
>>>> On Mar 28, 2020, at 7:13 AM, Michele Sciabarra <mich...@sciabarra.com>
>> wrote:
>>>>
>>>> Community,
>>>>
>>>> Let's make a long story short:
>>>>
>>>> In the openwhisk runtime for java, when you activate an action, you
>> have to pass some informatins. Most notably those:
>>>>
>>>> ---
>>>> {
>>>> "namespace": String,
>>>> "action_name": String,
>>>> "api_host": String,
>>>> "api_key": String,
>>>> "activation_id": String,
>>>> "transaction_id": String,
>>>> "deadline": Number
>>>> }
>>>> ---
>>>>
>>>> Now, the common way in all the programming languages is to set
>> environement variables:
>>>>
>>>> so action_name is passed as __OW_ACTION_NAME and so on.
>>>>
>>>> This is easy in every programming language except java. In Java "you
>> should not change environment variables". Because the concept of
>> environemnt variables is actually to use "system properties". Generally all
>> the environment variables are used to set system properties, read only.
>>>>
>>>> In che java8 runtime however the environment variables has been set.
>> Following this stack overlflow "horrible and unacceptable' (my opinion)
>> hack
>>>>
>>>>
>> https://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java
>>>>
>>>> Note this "vomit causing" (still my opinion) thing:
>>>>
>>>> Field field = cl.getDeclaredField("m");
>>>> field.setAccessible(true);
>>>>
>>>> Yep, you hack an in-memory undocumented hash map marked read only with
>> reflection to say "no, I want to write in it anyway" and then proceed your
>> surgery.
>>>>
>>>> I very very very very unwillingly applied this hack in the actionloop
>> runtime for java 8 for the sake of keeping compatibility and pass all the
>> existing tests.
>>>>
>>>> For java 11 however, this hack also requires you mark the runtime as
>> using "unsafe code"
>>>>
>>>> I thing this thing now it is a bit ... too much. So we should instead
>> change the way we pass the values and use system properties instead.
>>>>
>>>> Yes, user code for Java11 need to be changed. No more
>> System.getenv(...) but System.getProperties.
>>>>
>>>> Your thoughts?
>>>>
>>>>
>>>> --
>>>> Michele Sciabarra
>>>> mich...@sciabarra.com
>>
> --
> Matt Sicker <boa...@gmail.com>
