Thanks Anil. This is how this started, trying to pop the timeout up from
a system property to a parameter in the Execution methods.
-Alberto G.
On 16/9/19 21:37, Anilkumar Gingade wrote:
> Alberto,
>
> Sorry for late responseCurrently geode (java client) does provide
> ability to set functio
Alberto,
Sorry for late responseCurrently geode (java client) does provide
ability to set function timeout; but its through internal system property
"gemfire.CLIENT_FUNCTION_TIMEOUT"Some of the tests using this property
are Tests extending "FunctionRetryTestBase".
Since this is through in
Thanks for following up on this!
-Dan
On Mon, Sep 16, 2019 at 3:07 AM Alberto Gomez
wrote:
> Thanks for the feedback. I also give a +1 to option a) including Dan's
> comments.
>
> I'll move the RFC to the Development state and will open a ticket to
> follow up on the implementation.
>
> -Albert
Thanks for the feedback. I also give a +1 to option a) including Dan's
comments.
I'll move the RFC to the Development state and will open a ticket to
follow up on the implementation.
-Alberto G.
On 12/9/19 8:15, Jacob Barrett wrote:
> +1
>
> I echo Dan’s comments as well.
>
> Thanks for tackli
+1
I echo Dan’s comments as well.
Thanks for tackling this.
-jake
> On Sep 11, 2019, at 2:36 PM, Dan Smith wrote:
>
> +1 - Ok, I think I've come around to option (a). We can go head and add a
> new execute(timeout, TimeUnit) method to the java API that is blocking. We
> can leave the exist
+1 - Ok, I think I've come around to option (a). We can go head and add a
new execute(timeout, TimeUnit) method to the java API that is blocking. We
can leave the existing execute() method alone, except for documenting what
it is doing.
I would like implement execute(timeout, TimeUnit) on the ser
Hi all,
First of all, thanks a lot Dan and Jacob for your feedback.
As we are getting close to the deadline I am adding here some conclusions and a
refined proposal in order to get some more feedback and if possible some voting
on the two alternatives proposed (or any other in between if you fe
Sorry, some corrections on my comments after revisiting the native
client code.
When I said that the timeout used in the execution() method (by means of
a system property) was to set a read timeout on the socket, I was only
talking about the Java client. In the case of the native clients, the
Hi Dan,
Discussing these matters by e-mail is getting tricky.
Let's see if I understand you correctly and also if I am being clear enough.
Please, see my comments inline.
On 29/8/19 0:49, Dan Smith wrote:
> Sorry for the slow response, I've been trying to decide what I think is the
> right appr
Sorry for the slow response, I've been trying to decide what I think is the
right approach here.
For (1) - conceptually, I don't have a problem with having both blocking
and non blocking methods on Execution. So adding blocking versions of
execute() with a timeout seems ok. But I do think if we ad
Hi Jake,
Please, see my answers below.
On 22/8/19 21:16, Jacob Barrett wrote:
>
>> On Aug 21, 2019, at 8:49 AM, Alberto Gomez wrote:
>> 2. Timeout in ResultCollector::getResult() and Execution::execute() blocking
>>
>> Regarding the timeout in the ResultCollector::getResult() method problem and
Hi Dan,
Please, see my answers below.
On 22/8/19 20:29, Dan Smith wrote:
> For the two new execute() methods you are proposing, are you also
> suggesting that they be implemented on the server?
I was only thinking about the client.
>
> I took a look at the C++ API. The C++ API also has a
> Result
> On Aug 21, 2019, at 8:49 AM, Alberto Gomez wrote:
> 2. Timeout in ResultCollector::getResult() and Execution::execute() blocking
>
> Regarding the timeout in the ResultCollector::getResult() method problem and
> the blocking/non-blocking confusion for Execution::execute() two alternatives
> On Aug 22, 2019, at 11:55 AM, Jacob Barrett wrote:
>> On Aug 22, 2019, at 11:29 AM, Dan Smith wrote:
>> I took a look at the C++ API. The C++ API also has a
>> ResultCollector.getResult(timeout) method. Does that timeout do anything,
>> given that execute(timeout) already waited for the give
> On Aug 22, 2019, at 11:29 AM, Dan Smith wrote:
> I took a look at the C++ API. The C++ API also has a
> ResultCollector.getResult(timeout) method. Does that timeout do anything,
> given that execute(timeout) already waited for the given timeout?
The C++ client will wait on getResult until al
For the two new execute() methods you are proposing, are you also
suggesting that they be implemented on the server?
I took a look at the C++ API. The C++ API also has a
ResultCollector.getResult(timeout) method. Does that timeout do anything,
given that execute(timeout) already waited for the giv
Hi,
Please, see my answers below.
- Alberto
On 21/8/19 20:30, Anilkumar Gingade wrote:
> Just to be clear between java and native-client api:
>
> - Read timeout in function execution Java client API - This is to change
> the java client behavior
Yes
>
> And following are the native client proble
Just to be clear between java and native-client api:
- Read timeout in function execution Java client API - This is to change
the java client behavior
And following are the native client problems and solution applies to
native-client?
- Timeout in ResultCollector::getResult() and Execution::execu
Hi,
I have just added the following proposal in the wiki for discussion and would
like to get feedback from the community.
https://cwiki.apache.org/confluence/display/GEODE/%5BDiscussion%5D+Improvements+on+client+Function+execution+API
Problem
The client API for function execution is inconsist
19 matches
Mail list logo
