<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 8:13 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 27 February 2014 16:58, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
><br>
> On Feb 27, 2014, at 3:28 PM, Vladimir Blagojevic <<a href="mailto:vblagoje@redhat.com">vblagoje@redhat.com</a>> wrote:<br>
><br>
>> Hmm very good points Sanne. Yeah I think we can have a contract that<br>
>> returns an Address were task was executed.<br>
>><br>
>><br>
>> Cheers,<br>
>> Vladimir<br>
>> On 2/26/2014, 4:25 PM, Sanne Grinovero wrote:<br>
>>> I'm a bit skeptical.<br>
>>> It might sound a sensible request currently, but if you do so you<br>
>>> inherently "promise" that tasks are going to be executed on a specific<br>
>>> server; AFAIK we promise execution on data locality,<br>
><br>
> We allow execution to be bound on a specific address: <a href="http://goo.gl/H5qTJZ" target="_blank">http://goo.gl/H5qTJZ</a><br>
<br>
</div>I know but I think that smells :)<br>
Stuff like _Address_ should be an implementation detail. Maybe one day<br>
you'll see why and we'll deprecate it ;-)<br>
<div class=""><br>
> I see your point with data locality vs. specific server.<br>
><br>
><br>
>>> but maintaining a<br>
>>> good level of flexibility you can evolve your system to smarter load<br>
>>> balancing of tasks, failover operations, etc..<br>
>>> If you expose execution details, you won't be able to develop any of<br>
>>> that in future.<br>
>>><br>
>>> To make an example from the database world - seems the analogy is<br>
>>> common these days - it's like you run a SELECT statement but want to<br>
>>> pick which CPU core is going to be used. That would be really odd, as<br>
>>> you would take away the option from the scheduler to make an effective<br>
>>> choice.<br>
>>> Still, this approach might be desirable for a database which doesn't<br>
>>> do any smart scheduling.<br>
>>><br>
>>> Some of these concerns might be mitigated if you return the Address of<br>
>>> where the task *was* executed, after it's done. I still don't think it<br>
>>> should be of user's interest but at least you would be able to<br>
>>> implement rescheduling or failover policies in future.<br>
><br>
> We already have failure policies in place, but the user only needs to audit the failure, not to failover. If users are interested on knowing the failures, another way of doing it is the current future, in the Future.get to throw a custom exception (subclass of ExecutionException) containing as information where the execution failed.<br>
<br>
</div>Right, but the question is if the user really wants to know the<br>
intermediate failures? I suspect that if someone asks for this, he's<br>
actually wishing to implement his own failower policy & monitoring.<br>
>From the point of view of someone running a database query, I think<br>
the user would love to ignore issues altogether, but the real world<br>
forces him to at least consider that the whole operation might fail.<br>
Sending him specific notifications or exceptions of something that was<br>
succesfull but was actually run on a different resource set than what<br>
was originally planned is I'd say an exotic request.<br></blockquote><div><br></div><div>I don't think the user was after the address of the "real" executing node, I believe he just wanted a way to map each Future to the target address doing a submitEverywhere(task).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I like the idea of providing additional information in a Future<br>
subtype, but I don't think you should throw it on a get() operation.<br>
You could simply add getters to the FutureExtended to retrieve like an<br>
execution plan history, a trace of intermediate failures, etc.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>That sounds good, but we shouldn't limit that to just the result of one distributed task execution. We could take the opportunity to return something other than List<Future> from submitEverywhere(task) as well, doing a foreach to get all the results is a bit tedious. And even if we'd like users to treat the results from different nodes as interchangeable, sometimes they're not, so a way of getting the result from one particular node would also be useful.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
Sanne<br>
</font></span><div class=""><div class="h5"><br>
><br>
>>><br>
>>> Sanne<br>
>>><br>
>>><br>
>>> On 26 February 2014 19:31, Vladimir Blagojevic <<a href="mailto:vblagoje@redhat.com">vblagoje@redhat.com</a>> wrote:<br>
>>>> Hey,<br>
>>>><br>
>>>> There is an interesting request from community to include an Address along with a Future returned for a subtask being executed [1].<br>
>>>><br>
>>>> I think it makes sense what this user wants. We might create Future sub interface that has getAddress method and we can return an object implementing that interface instead of plain Future. In some new major release we can officially change the signature of these DistributedExecutorService methods to return i.e TargetedFuture - it would not break existing clients. Maybe even make TargetedFuture extend NotifyingFuture.<br>
>>>><br>
>>>> Any thoughts?<br>
>>>><br>
>>>> Vladimir<br>
>>>><br>
>>>> [1] <a href="https://community.jboss.org/thread/237442" target="_blank">https://community.jboss.org/thread/237442</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> Cheers,<br>
> --<br>
> Mircea Markus<br>
> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>