Charm++ parallel programming system

[Kelly Davis <kdavis AT alum.mit.edu>]

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