Dmitriy,I don't believe it makes sense to have the action execute remotely. At
least I didn't think of it.In my mind, the action is always local (that's the
reason I suggested the Java's Callable in the API and not serializable
IgniteCallable, in the first place). What the action does is entirely up to the
user. One could fire off a remote compute if that's what one wants.I hope I
make myself clear.ThanksAndrey
_____________________________
From: Dmitriy Setrakyan <dsetrak...@apache.org>
Sent: Saturday, January 16, 2016 7:54 AM
Subject: Re: Semaphore action
To: <dev@ignite.apache.org>
Andrey,
In general this seems like a good addition. However, I do not understand
how you can specify an executor, given that execution could happen
remotely. Can you please clarify?
D.
On Fri, Jan 15, 2016 at 1:00 PM, Andrey Kornev <andrewkor...@hotmail.com>
wrote:
> Hi there,
>
> The Semaphore feature was a great addition to Ignite's synchronization
> primitive toolkit. I'd like to propose an enhancement to make Semaphore API
>
> even more useful.
>
> My biggest complaint about the current API is its blocking nature. For
> example, the only way to acquire a permit is by using the blocking
> acquire() method (tryAcquire() is not very useful in the cases when you
> MUST acquire before you can proceed). I believe that in the 21st century
> blocking APIs is anachronism. :))) It's a bit embarrassing even. I'm sure
> Ignite can do better than that! :)
>
> Usually a permit acquisition is followed by an action, followed by a
> release of the permit. I propose a simple enhancement to the Semaphore API
> that will reduce the boilerplate and make it possible to do all of that
> asynchronously! The new method might look like this:
>
> <T> IgniteFuture<T> acquireAndExecute(Callable<T> action);
> <T> IgniteFuture<T> acquireAndExecute(Callable<T> action, Executor
> executor);
>
> (The name could be improved, of course...) The first method would
> immediately return a future to be later completed by the action's result.
> The action will be executed on a thread from the Ignite's public thread
> pool once a permit has been acquired. Optionally, the user could specify a
> different executor using the second signature.
>
> Would the community be interested in such enhancement?
>
> Thanks
> Andrey
>
> PS. A subject for a separate discussion, but I believe that in the next
> major release Ignite should just drop the clumsy withAsync() API and make
> all blocking calls explicitly async by returning a future. In my opinion it
>
> would greatly simplify the API and make it more modern. Besides, I'm pretty
>
> sure that internally Ignite already creates futures for pretty much most of
>
> the API calls, so it should not cause any performance issue.
>
