...
No Format |
---|
[fatal 2015/12/03 10:58:20.809 PST <Function Execution Processor1> tid=Function Execution Processor1id] Unexpected exception during function execution on local node Partitioned Region java.lang.ClassCastException: java.lang.Exception cannot be cast to com.gemstone.gemfire.cache.lucene.internal.distributed.TopEntriesCollector at com.gemstone.gemfire.cache.lucene.internal.distributed.TopEntriesFunctionCollector.addResult(TopEntriesFunctionCollector.java:1) at com.gemstone.gemfire.internal.cache.execute.LocalResultCollectorImpl.addResult(LocalResultCollectorImpl.java:85) at com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFunctionResultSender.java:216) at com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFunctionResultSender.java:174) at com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.sendException(PartitionedRegionFunctionResultSender.java:309) at com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction.execute(LuceneFunction.java:60) at com.gemstone.gemfire.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:367) at com.gemstone.gemfire.internal.cache. |
Function invoked with onMember
...
cannot be unit tested, because our API requires using a singleton cache
FunctionContext does not contain a cache. That means any function that you execute with onMember must contain code like this:
...
This makes it impossible to write pure unit tests for the function code that mock the cache.
Functions invoked with onRegion
...
always have to cast the FunctionContext to RegionFunctionContext
Any function that is executed on a region has to do a cast. This is not an intuitive API; the user has to know that there is such a thing as RegionFunctionContext. This can also lead to ClassCastExceptions if the user tries to cast the FunctionContext and it is not actually a REgionFunctionContext
...
Code Block |
---|
public void execute(FunctionContext context) { RegionFunctionContext ctx = (RegionFunctionContext) context; |
...
Getting the local data set of a function is not intuitive, uses static functions that expect concrete objects
If you want to operate on the local data set for a function, you have to do this
...
- It's not clear that ctx.getDataSet does not return the local data.
- The local data set is not mockable for unit tests, because this static function call extracts it using internal APIs on concrete classes. This also prevents this sort of function from being tested in a pure unit test.
- The user has to know that PartitionRegionHelper exists; the API is not obvious
- The various methods on PartitionRegionHelper are confusing, specifically it's unclear to a user why they should use getLocalDataFOrContext getLocalDataForContext instead of getLocalData
...
No way to get a spring data repository of the local data set of a function
...
FunctionService.onMembers doesn't take a Cache or DistributedSystem . This locks us in to having a as a parameter. That means we can't get rid of the singleton DistributedSystem, because FunctionService will always look up the singleton.
...
The function context has a ResultSender with methods like sendResult, lastResult, sendException, etc. HoweverUnfortunately, that makes the common case is that the user wants to send of a function that returns a single result , so we should provide a simpler function interface for this case that has a single return value. unnecessarily verbose and error prone. For example, if no result is sent that can cause issues:
Code Block |
---|
public void execute(FunctionContext context) {
if(someTest) {
context.getResultSender().lastResult("Done");
}
//Whoops I forgot to send a last result
} |
Function code must exist on the client
...