geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <>
Subject Re: Question about excluding serialized classes
Date Wed, 11 Sep 2019 17:51:44 GMT
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 objects directly from the function
service using FunctionService.getFunction(String) and do whatever they want
with them, which I guess could include serializing them.

Hope that helps!

On Wed, Sep 11, 2019 at 10:27 AM Aaron Lindsey <> wrote:

> As part of a PR to add Micrometer timers for function executions
> <>, we implemented a decorator
> Function that wraps all registered non-internal functions and adds
> instrumentation. This PR is
> failing AnalyzeSerializablesJUnitTest.testSerializables because the
> decorator class is a new Serializable.
> I'm not sure if it would be OK to add this class to excludedClasses.txt
> because I don't know whether this function will ever be serialized. If it
> will be serialized, then I'm concerned that this might break backwards
> compatibility because we're changing the serialized form of registered
> functions. If this is the case, then we could implement custom logic for
> serializing the decorator class which would replace its serialized form
> with the serialized form of the inner class. Again, I'm not sure if that
> would be necessary because I don't know the conditions under which a
> function would be serialized.
> Could someone help me understand when functions would be persisted or sent
> over the wire so I can determine if this change would break compatibility?
> Thanks,
> Aaron

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message