Oh yeah that definitely wouldn’t work.

On Sun, Mar 29, 2020 at 10:29 Carlos Santana <csantan...@gmail.com> wrote:

> -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>
>
-- 
Matt Sicker <boa...@gmail.com>

Reply via email to