Charm++ parallel programming system

["Kale, Laxmikant V" <kale AT illinois.edu>]

I think your application is simpler and can do with a simpler variant of
message logging..It appears to be some combination of
multiple-transactions and master-slave computing.  Mlogft is an overkill
for that. But we might not have the simpler variant in place. I will
communicate with you after I discuss with Esteban a bit.

Sanjay

-- 
Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
<http://charm.cs.uiuc.edu/>
Professor, Computer Science     
kale AT illinois.edu
201 N. Goodwin Avenue           Ph:  (217) 244-0094
Urbana, IL  61801-2302          FAX: (217) 265-6582






On 8/3/12 10:02 AM, "Kelly Davis" 
<kdavis AT alum.mit.edu>
 wrote:

>Hi Sanjay,
>
>I have built on charm++ a system like Java's JMS+Spring in which the
>containers
>are provided by charm++ constructs and the contained elements are
>subclasses
>of a given class and dynamically loaded from so's. This runs in the cloud
>on a
>cluster of servers.
>
>I want to process client requests in realtime. So, for me it is important
>that if a given
>server in the cluster goes down, the messages that would have been
>processed by
>that server not be lost, but are directed to another server in the
>cluster and processed.
>
>PS: Also, is mlogtft indeed in an experimental state?
>
>Best,
>Kelly
>
>
>----- Original Message -----
>From: "Kale, Laxmikant V" 
><kale AT illinois.edu>
>To: "Miller, Philip B" 
><mille121 AT illinois.edu>;
> Kelly Davis
><kdavis AT alum.mit.edu>
>Cc: 
>"charm AT cs.uiuc.edu"
> 
><charm AT cs.uiuc.edu>
>Sent: Friday, August 3, 2012 6:19 PM
>Subject: Re: [ppl] [charm]   Compiling the charm++ from git
>
>It does not make sense to use both synft and mlogtft together, since
>mlogft already combines them. (message logging can be thought of as an
>optimization on top of in-memory checkpoint restart).
>
>Kelly, it will help us help you if we understand your objective and
>viewpoint. It is from an CSE application developers viewpoint, then you
>should look at disk-based checkpoint, and in-memory double checkpoint.
>Message logging makes sense at a larger scale, and it avoids rolling back
>every processor.
>
>(apologies if I miss info in some other emails).
>
>Sanjay
>
>-- 
>Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
><http://charm.cs.uiuc.edu/>
>Professor, Computer Science    
>kale AT illinois.edu
>201 N. Goodwin Avenue           Ph:  (217) 244-0094
>Urbana, IL  61801-2302          FAX: (217) 265-6582
>
>
>
>
>
>
>On 8/3/12 8:37 AM, "Phil Miller" 
><mille121 AT illinois.edu>
> wrote:
>
>>On Fri, Aug 3, 2012 at 10:24 AM, Kelly Davis 
>><kdavis AT alum.mit.edu>
>> wrote:
>>>>This particular set of options is not expected to work. You've
>>>>requested that the runtime be built to support 2 different fault
>>>>tolerance protocols simultaneously, where the code is only written to
>>>>enable one at a time.
>>>
>>> So, I have to choose if I want "fault tolerance support" xor if I want
>>> "message logging fault tolerance support"?
>>>
>>> Also, could you elaborate a bit more on what...
>>>
>>>>In their current form, it doesn't really make sense to combine them
>>>
>>> means?
>>
>>It seems that the 'syncft' option was labeled poorly, then. That's
>>specifically the double in-memory checkpoint/restart fault tolerance
>>mechanism. The other mechanism, 'mlogft', is based on message logging.
>>Either one of syncft or mlogft enables fault tolerance support, but
>>only one mechanism or the other can work at a time.
>>_______________________________________________
>>charm mailing list
>>charm AT cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/charm
>>_______________________________________________
>>ppl mailing list
>>ppl AT cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/ppl