Re: Upgrade scenario: FunctionAttributes update

[Mario Salazar de Torres]

Hi Barry,
Many thanks for dedicating some time testing this.
As you confirmed the scenario also fails using the Java API, so I'll create the 
PRs with the solution for both Java and C++ API.

Thanks!
/Mario
________________________________
From: Barry Oglesby <bogle...@vmware.com>
Sent: Wednesday, January 26, 2022 10:28 PM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: Upgrade scenario: FunctionAttributes update

Mario,

I tried changing optimizeForWrite from true to false in java and the function 
execution breaks with this cause:

Caused by: org.apache.geode.cache.client.ServerOperationException: remote 
server on localhost: Function attributes at client and server don't match: 
UpdateTradeFunction
at 
org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:372)
at 
org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
  at ...
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:343)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:312)
at org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:848)
at 
org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:48)

There is an internal java API in AbstractExecution called 
removeFunctionAttributes that works-around this issue. I'm not sure I see the 
same API in NC, but I could be missing it.

} catch (FunctionException e) {
  if (e.getMessage().contains("Function attributes at client and server don't 
match")) {
    ((AbstractExecution) 
execution).removeFunctionAttributes("UpdateTradeFunction");
    // Retry function here or in loop
  } else {
    handleException(e);
  }
}

I'm not sure this was done on purpose. It seems like the product could clear 
the cached attributes and retry once internally before throwing the exception.

It looks like changing optimizeForWrite or isHA would be fine, but changing 
hasResult would require changing your client read the result (or not).

Barry
________________________________
From: Mario Salazar de Torres <mario.salazar.de.tor...@est.tech>
Sent: Wednesday, January 26, 2022 9:11 AM
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Upgrade scenario: FunctionAttributes update

Hi everyone,

During our testing, we have the following scenario:

  *   We start up a cluster and a geode-native client.
  *   Load a FunctionService jar into the cluster.
  *   Execute normal flow of operations (function execs, puts, gets, ...)
  *   After 5 mins, we update the FunctionService jar, which changes some of 
the function attributes.
  *   From this point on, geode-native client receives an error from the server 
stating that the function exec failed due to function attributes mismatch.

Obviously, this case is not supported by geode-native, as it would require 
updating the function attributes when this error is received.
I am not sure if this is supported in the Java client, I've been looking, and I 
haven't seen that this mechanism is supported in the Java client, but maybe I 
am wrong.
My questions are:

  *   Have you encountered a scenario like this?
  *   Do you know if function attributes update is not supported on purpose, to 
avoid an issue? Or it's just that nobody tried this upgrade scenario before?

Thanks for all!
/Mario.