Hmm very good points Sanne. Yeah I think we can have a contract that returns an Address were task was executed.
Cheers, Vladimir On 2/26/2014, 4:25 PM, Sanne Grinovero wrote: > I'm a bit skeptical. > It might sound a sensible request currently, but if you do so you > inherently "promise" that tasks are going to be executed on a specific > server; AFAIK we promise execution on data locality, but maintaining a > good level of flexibility you can evolve your system to smarter load > balancing of tasks, failover operations, etc.. > If you expose execution details, you won't be able to develop any of > that in future. > > To make an example from the database world - seems the analogy is > common these days - it's like you run a SELECT statement but want to > pick which CPU core is going to be used. That would be really odd, as > you would take away the option from the scheduler to make an effective > choice. > Still, this approach might be desirable for a database which doesn't > do any smart scheduling. > > Some of these concerns might be mitigated if you return the Address of > where the task *was* executed, after it's done. I still don't think it > should be of user's interest but at least you would be able to > implement rescheduling or failover policies in future. > > Sanne > > > On 26 February 2014 19:31, Vladimir Blagojevic <[email protected]> wrote: >> Hey, >> >> There is an interesting request from community to include an Address along >> with a Future returned for a subtask being executed [1]. >> >> 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. >> >> Any thoughts? >> >> Vladimir >> >> [1] https://community.jboss.org/thread/237442 >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
