Hi Jake,
I think this thread has moved a bit off-topic, but I appreciate you
pointing out that scenario. We'll have to consider that when re-working
this PR.
- Aaron
On Tue, Sep 17, 2019 at 9:42 AM Jacob Barrett wrote:
>
> > On Sep 17, 2019, at 9:36 AM, Aaron Lindsey wrote:
> >
> >>
> >>
> On Sep 17, 2019, at 9:36 AM, Aaron Lindsey wrote:
>
>>
>> Not all functions are registered. I can invoke a function with
>> Execution.execute(Function) from the client, the Function is serialized and
>> executed on the server, the class need only exist on the server for
>> deserialization.
>
> Not all functions are registered. I can invoke a function with
> Execution.execute(Function) from the client, the Function is serialized and
> executed on the server, the class need only exist on the server for
> deserialization. Must a function be registered now to get metrics?
>
For this
> On Sep 16, 2019, at 7:54 PM, Jacob Barrett wrote:
>
> The current implementation has statistics without decoration.
For our meters, we want to make a distinction that the current stats
implementation does not: We want to measure only non-internal functions. It
isn’t clear (yet) how we can
Not all functions are registered. I can invoke a function with
Execution.execute(Function) from the client, the Function is serialized and
executed on the server, the class need only exist on the server for
deserialization. Must a function be registered now to get metrics?
> On Sep 17, 2019,
Jake — We're not constructing a new object each time a function is invoked
because the "decorated" functions are only created when a function is
registered, but we'll keep your concern in mind.
Thanks for all of the feedback from everyone. I think we have the
information we need to move forward.
Sorry I am entering this late in the game but why do we need to decorate the
function at all for metrics. The current implementation has statistics without
decoration. All the concerns raised in this thread concern me as well as the
cost of constructing yet another object every time a function
As far as I can tell, the things that execute functions use the public API to
find the function to execute. So if we unwrap the functions in the public API,
only the un-instrumented functions will be executed.
—
Dale Emery
dem...@pivotal.io
> On Sep 11, 2019, at 1:38 PM, Dan Smith wrote:
>
The stats use the ID of the function, and each TimingFunction reports the same
ID as the function it wraps. So I think the stats would look like they always
did.
Dale
—
Dale Emery
dem...@pivotal.io
> On Sep 11, 2019, at 12:14 PM, Anthony Baker wrote:
>
> I think the Decorator approach you
I think you could still use your decorator approach if you also unwrap the
Functions when returning them from the public APIs like getFunction etc. In
that case your TimingFunction could probably safely by added to
excludedClasses.txt.
You will miss collecting metrics about functions that aren't
They would be the specific functions, but this doesn’t get us around they other
problem. I think this approach is not going to work and we are about to start
looking into other ways.
Thanks,
Mark
> On Sep 11, 2019, at 12:14 PM, Anthony Baker wrote:
>
> I think the Decorator approach you
I think the Decorator approach you outlined could have other impacts as well.
Would I still be able to see specific function executions in statistics or
would they all become “TImingFunction”?
Anthony
> On Sep 11, 2019, at 12:00 PM, Aaron Lindsey wrote:
>
> Thanks for your response, Dan.
>
Yeah, I would expect that FunctionService.getFunction() would return the
same function object I registered with FunctionService.registerFunction.
-Dan
On Wed, Sep 11, 2019 at 12:01 PM Aaron Lindsey wrote:
> Thanks for your response, Dan.
>
> The second scenario you mentioned (i.e. users
Thanks for your response, Dan.
The second scenario you mentioned (i.e. users calling
FunctionService.getFunction(String)) worries me because our PR changes the
FunctionService so they would now get back an instance of the decorator
function instead of the specific instance they registered by
Functions are serialized when you call Execution.execute(Function) instead
of Execution.execute(String). Invoking execute on a function object
serializes the function and executes it on the remote side. Functions
executed this way don't have be registered.
Users can also get registered function
15 matches
Mail list logo
