You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2015/12/16 18:27:13 UTC
Function service usability improvements
Hi all,
Ashvin, Gester and I have gone over our function execution API, and we have
some proposals for how we should improve the function service API to make
it a little bit easier to use. Please take a look at the proposals on the
wiki and let us know what you think:
https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
-Dan
Re: Function service usability improvements
Posted by Barry Oglesby <bo...@pivotal.io>.
I'd rather have it spelled out with getArguments / setArguments.
Thanks,
Barry Oglesby
GemFire Advanced Customer Engineering (ACE)
For immediate support please contact Pivotal Support at
http://support.pivotal.io/
On Thu, Dec 17, 2015 at 2:46 PM, Dan Smith <ds...@pivotal.io> wrote:
> Hi Barry,
>
> That seems reasonable. What would you prefer - Args or Arguments?
>
> -Dan
>
> On Thu, Dec 17, 2015 at 9:32 AM, Barry Oglesby <bo...@pivotal.io>
> wrote:
>
> > These look good. One small change I would like to see:
> >
> > Can you make these consistent (either withArguments or getArgs)
> >
> > Execution:
> >
> > public Execution withArgs(Object args);
> >
> > FunctionContext:
> >
> > public Object getArguments();
> >
> >
> > Barry Oglesby
> > GemFire Advanced Customer Engineering (ACE)
> > For immediate support please contact Pivotal Support at
> > http://support.pivotal.io/
> >
> >
> > On Wed, Dec 16, 2015 at 9:27 AM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > > Hi all,
> > >
> > > Ashvin, Gester and I have gone over our function execution API, and we
> > have
> > > some proposals for how we should improve the function service API to
> make
> > > it a little bit easier to use. Please take a look at the proposals on
> the
> > > wiki and let us know what you think:
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
> > >
> > > -Dan
> > >
> >
>
Re: Function service usability improvements
Posted by Dan Smith <ds...@pivotal.io>.
Hi Barry,
That seems reasonable. What would you prefer - Args or Arguments?
-Dan
On Thu, Dec 17, 2015 at 9:32 AM, Barry Oglesby <bo...@pivotal.io> wrote:
> These look good. One small change I would like to see:
>
> Can you make these consistent (either withArguments or getArgs)
>
> Execution:
>
> public Execution withArgs(Object args);
>
> FunctionContext:
>
> public Object getArguments();
>
>
> Barry Oglesby
> GemFire Advanced Customer Engineering (ACE)
> For immediate support please contact Pivotal Support at
> http://support.pivotal.io/
>
>
> On Wed, Dec 16, 2015 at 9:27 AM, Dan Smith <ds...@pivotal.io> wrote:
>
> > Hi all,
> >
> > Ashvin, Gester and I have gone over our function execution API, and we
> have
> > some proposals for how we should improve the function service API to make
> > it a little bit easier to use. Please take a look at the proposals on the
> > wiki and let us know what you think:
> >
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
> >
> > -Dan
> >
>
Re: Function service usability improvements
Posted by Barry Oglesby <bo...@pivotal.io>.
These look good. One small change I would like to see:
Can you make these consistent (either withArguments or getArgs)
Execution:
public Execution withArgs(Object args);
FunctionContext:
public Object getArguments();
Barry Oglesby
GemFire Advanced Customer Engineering (ACE)
For immediate support please contact Pivotal Support at
http://support.pivotal.io/
On Wed, Dec 16, 2015 at 9:27 AM, Dan Smith <ds...@pivotal.io> wrote:
> Hi all,
>
> Ashvin, Gester and I have gone over our function execution API, and we have
> some proposals for how we should improve the function service API to make
> it a little bit easier to use. Please take a look at the proposals on the
> wiki and let us know what you think:
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
>
> -Dan
>
Re: Function service usability improvements
Posted by Rajiv Kumar <ra...@gmail.com>.
The suggested changes are good.
Regards,
Rajiv Kumar
On Thu, Dec 17, 2015 at 7:55 PM, pulkit chandra <pu...@gmail.com>
wrote:
> These changes look good.
>
> Might I suggest another improvement, since we are looking at the function
> code.
>
> Currently we execute the function code in the same thread as the request
> which has submitted the function to server. Customer have some times
> reached out with issues where we see issues when the function code is stuck
> and causes the distributed system to have issues.
>
> It might be a better design to have a concurrent function execution in its
> own thread pool per server which can be monitored. We can have a Java
> Future and Executor type behavior in that case.
>
> My $0.02.
>
> Cheers,
> *Pulkit Chandra*
>
>
> On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> > Hi all,
> >
> > Ashvin, Gester and I have gone over our function execution API, and we
> have
> > some proposals for how we should improve the function service API to make
> > it a little bit easier to use. Please take a look at the proposals on the
> > wiki and let us know what you think:
> >
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
> >
> > -Dan
> >
>
Re: Function service usability improvements
Posted by pulkit chandra <pu...@gmail.com>.
These changes look good.
Might I suggest another improvement, since we are looking at the function
code.
Currently we execute the function code in the same thread as the request
which has submitted the function to server. Customer have some times
reached out with issues where we see issues when the function code is stuck
and causes the distributed system to have issues.
It might be a better design to have a concurrent function execution in its
own thread pool per server which can be monitored. We can have a Java
Future and Executor type behavior in that case.
My $0.02.
Cheers,
*Pulkit Chandra*
On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <ds...@pivotal.io> wrote:
> Hi all,
>
> Ashvin, Gester and I have gone over our function execution API, and we have
> some proposals for how we should improve the function service API to make
> it a little bit easier to use. Please take a look at the proposals on the
> wiki and let us know what you think:
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
>
> -Dan
>
Re: Function service usability improvements
Posted by Wes Williams <ww...@pivotal.io>.
>>he way I'm thinking of it, our our existing function execution code is a
lower level API on top of which an annotation based API can be constructed.
Does that seem reasonable?<<
Exactly.
>>Or do you think we should drop the RegionFunction/MemberFunction
interfaces entirely in favor of an annotation based approach?<<
My preference is to do both. Here are my reasons: When I do GemFire POC's,
a top priority is to write code in such a way that it conveys simplicity
and understandability to the new customer. If I were to adopt an
opinionated style for POC's that I do, I opt for the @Annotation style.
However, some developers prefer writing code with a lower-level style
similar to writing compilers and stacks (e.g. an argument list). I wonder
if removing it creates trouble for the system-level function style already
in GemFire and possibly breaks backwards compatibility.
If an @Annotation style could pre-compile and cache the method metadata and
the function interface hands it to a statically-typed method, I would use
that style all day long when presenting to customers.
*Wes Williams | Pivotal Sr. **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire
On Thu, Dec 17, 2015 at 6:09 PM, Dan Smith <ds...@pivotal.io> wrote:
> Hi Wes,
>
> I really like what spring data gemfire has done. I like the fact that you
> get to create a client side interface for the function as well as defining
> the method on the server side as you've outlined.
>
> One thing that's slightly different about that approach is that you no
> longer have a Function interface - you have annotations on arbitrary
> methods. That meams you can't use a lambda for a function, but I'm not sure
> if anyone will do that anyway considering how complex the function code
> tends to be.
>
> The way I'm thinking of it, our our existing function execution code is a
> lower level API on top of which an annotation based API can be constructed.
> Does that seem reasonable? Or do you think we should drop the
> RegionFunction/MemberFunction interfaces entirely in favor of an annotation
> based approach?
>
> -Dan
>
> On Thu, Dec 17, 2015 at 9:51 AM, Wes Williams <ww...@pivotal.io>
> wrote:
>
>> These proposals are great. I find convenient the signature matching that
>> Spring GemFire provides. How difficult would it be to create a late-binding
>> call to a matching signature based on the argument types for developer
>> convenience?
>>
>> The following is from
>> http://docs.spring.io/spring-data-gemfire/docs/1.4.4.RELEASE/reference/html/function-annotations.html
>>
>> Object[] args = new Object[]{"hello", 123}
>>
>> Then the Spring container should be able to bind to any method signature
>> similar to the following. Let's ignore the return type for the moment:
>>
>> public Object method1(String s1, int i2) {...}public Object method2(Map<?,?> data, String s1, int i2) {...}public Object method3(String s1, Map<?,?>data, int i2) {...}public Object method4(String s1, Map<?,?> data, Set<?> filter, int i2) {...}public void method4(String s1, Set<?> filter, int i2, Region<?,?> data) {...}public void method5(String s1, ResultSender rs, int i2);public void method6(FunctionContest fc);
>>
>> The general rule is that once any additional arguments, i.e., region data
>> and filter, are resolved the remaining arguments must correspond exactly,
>> in order and type, to the expected calling parameters.
>>
>> *Wes Williams | Pivotal Sr. **Data Engineer*
>> 781.606.0325
>> http://pivotal.io/big-data/pivotal-gemfire
>>
>> On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>>> Hi all,
>>>
>>> Ashvin, Gester and I have gone over our function execution API, and we
>>> have
>>> some proposals for how we should improve the function service API to make
>>> it a little bit easier to use. Please take a look at the proposals on the
>>> wiki and let us know what you think:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
>>>
>>> -Dan
>>>
>>
>>
>
Re: Function service usability improvements
Posted by Dan Smith <ds...@pivotal.io>.
Hi Wes,
I really like what spring data gemfire has done. I like the fact that you
get to create a client side interface for the function as well as defining
the method on the server side as you've outlined.
One thing that's slightly different about that approach is that you no
longer have a Function interface - you have annotations on arbitrary
methods. That meams you can't use a lambda for a function, but I'm not sure
if anyone will do that anyway considering how complex the function code
tends to be.
The way I'm thinking of it, our our existing function execution code is a
lower level API on top of which an annotation based API can be constructed.
Does that seem reasonable? Or do you think we should drop the
RegionFunction/MemberFunction interfaces entirely in favor of an annotation
based approach?
-Dan
On Thu, Dec 17, 2015 at 9:51 AM, Wes Williams <ww...@pivotal.io> wrote:
> These proposals are great. I find convenient the signature matching that
> Spring GemFire provides. How difficult would it be to create a late-binding
> call to a matching signature based on the argument types for developer
> convenience?
>
> The following is from
> http://docs.spring.io/spring-data-gemfire/docs/1.4.4.RELEASE/reference/html/function-annotations.html
>
> Object[] args = new Object[]{"hello", 123}
>
> Then the Spring container should be able to bind to any method signature
> similar to the following. Let's ignore the return type for the moment:
>
> public Object method1(String s1, int i2) {...}public Object method2(Map<?,?> data, String s1, int i2) {...}public Object method3(String s1, Map<?,?>data, int i2) {...}public Object method4(String s1, Map<?,?> data, Set<?> filter, int i2) {...}public void method4(String s1, Set<?> filter, int i2, Region<?,?> data) {...}public void method5(String s1, ResultSender rs, int i2);public void method6(FunctionContest fc);
>
> The general rule is that once any additional arguments, i.e., region data
> and filter, are resolved the remaining arguments must correspond exactly,
> in order and type, to the expected calling parameters.
>
> *Wes Williams | Pivotal Sr. **Data Engineer*
> 781.606.0325
> http://pivotal.io/big-data/pivotal-gemfire
>
> On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <ds...@pivotal.io> wrote:
>
>> Hi all,
>>
>> Ashvin, Gester and I have gone over our function execution API, and we
>> have
>> some proposals for how we should improve the function service API to make
>> it a little bit easier to use. Please take a look at the proposals on the
>> wiki and let us know what you think:
>>
>>
>> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
>>
>> -Dan
>>
>
>
Re: Function service usability improvements
Posted by Wes Williams <ww...@pivotal.io>.
These proposals are great. I find convenient the signature matching that
Spring GemFire provides. How difficult would it be to create a late-binding
call to a matching signature based on the argument types for developer
convenience?
The following is from
http://docs.spring.io/spring-data-gemfire/docs/1.4.4.RELEASE/reference/html/function-annotations.html
Object[] args = new Object[]{"hello", 123}
Then the Spring container should be able to bind to any method signature
similar to the following. Let's ignore the return type for the moment:
public Object method1(String s1, int i2) {...}public Object
method2(Map<?,?> data, String s1, int i2) {...}public Object
method3(String s1, Map<?,?>data, int i2) {...}public Object
method4(String s1, Map<?,?> data, Set<?> filter, int i2) {...}public
void method4(String s1, Set<?> filter, int i2, Region<?,?> data)
{...}public void method5(String s1, ResultSender rs, int i2);public
void method6(FunctionContest fc);
The general rule is that once any additional arguments, i.e., region data
and filter, are resolved the remaining arguments must correspond exactly,
in order and type, to the expected calling parameters.
*Wes Williams | Pivotal Sr. **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire
On Wed, Dec 16, 2015 at 12:27 PM, Dan Smith <ds...@pivotal.io> wrote:
> Hi all,
>
> Ashvin, Gester and I have gone over our function execution API, and we have
> some proposals for how we should improve the function service API to make
> it a little bit easier to use. Please take a look at the proposals on the
> wiki and let us know what you think:
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments
>
> -Dan
>