Fair enough. Keep it simple.
On 18 Apr 2011, at 14:12, Vladimir Blagojevic wrote:
> On 11-04-18 7:58 AM, Manik Surtani wrote:
>> I still think Mircea's suggestion is very valid. Try cloning first. If
>> cloning is not supported then serialize/deserialize. And in any case you
>> only need 1
On 11-04-18 7:58 AM, Manik Surtani wrote:
> I still think Mircea's suggestion is very valid. Try cloning first. If
> cloning is not supported then serialize/deserialize. And in any case you
> only need 1 copy of the callable to send across to all other nodes, and the
> original copy for local
I still think Mircea's suggestion is very valid. Try cloning first. If
cloning is not supported then serialize/deserialize. And in any case you only
need 1 copy of the callable to send across to all other nodes, and the original
copy for local execution, right?
On 18 Apr 2011, at 11:24, Gal
On Apr 15, 2011, at 3:23 PM, Vladimir Blagojevic wrote:
> On 11-04-15 4:34 AM, Galder Zamarreño wrote:
>> On Apr 12, 2011, at 7:45 PM, Vladimir Blagojevic wrote:
>>
>>> Yeah, it would be too strict to require Callable to be Cloneable so I
>>> would opt out to serialization/deserialization as a c
On 11-04-15 4:34 AM, Galder Zamarreño wrote:
> On Apr 12, 2011, at 7:45 PM, Vladimir Blagojevic wrote:
>
>> Yeah, it would be too strict to require Callable to be Cloneable so I
>> would opt out to serialization/deserialization as a clone method.
>>
>> Galder, do out have a recommended mechanism fo
On Apr 12, 2011, at 7:45 PM, Vladimir Blagojevic wrote:
> Yeah, it would be too strict to require Callable to be Cloneable so I
> would opt out to serialization/deserialization as a clone method.
>
> Galder, do out have a recommended mechanism for this in your marshalers?
Not really. I think y
On 12 Apr 2011, at 18:45, Vladimir Blagojevic wrote:
> Yeah, it would be too strict to require Callable to be Cloneable so I would
> opt out to serialization/deserialization as a clone method.
yes, but you can still check to see if the Callable is Clonable first. Only if
it is not use serializa
Yeah, it would be too strict to require Callable to be Cloneable so I
would opt out to serialization/deserialization as a clone method.
Galder, do out have a recommended mechanism for this in your marshalers?
Thanks Mircea
On 11-04-12 12:59 PM, Mircea Markus wrote:
> can't you run the Callable
can't you run the Callable locally on a clone of it? If Callable is Clonable
then clone it in an orthodox manner, otherwise clone it by
serializing/deseralizing it.
On 11 Apr 2011, at 19:58, Vladimir Blagojevic wrote:
> Sanne,
>
> I thought about that as well but I do not see a way to ensure t
Sanne,
I thought about that as well but I do not see a way to ensure that all
other commands have been sent to other nodes other than waiting for
corresponding futures to return from get and then invoke locally in a
serial fashion.
I do not see a hook anywhere that will tell me when a command
2011/4/11 Vladimir Blagojevic :
> Hi,
>
> I discovered a problem with distributed framework in cases where
> Callables submitted for distributed execution contain mutable instance
> fields. Just before Callable is dispersed across cluster it gets invoked
> locally where instance fields of a submitt
Hi,
I discovered a problem with distributed framework in cases where
Callables submitted for distributed execution contain mutable instance
fields. Just before Callable is dispersed across cluster it gets invoked
locally where instance fields of a submitted Callable can be possibly
mutated; Ca
12 matches
Mail list logo
