Charm++ parallel programming system

[Esteban Meneses-Rojas <emenese2 AT illinois.edu>]

   Kelly,
   The mlogft version of Charm++ is in fact an experimental version
that we are trying to replace by a different message logging protocol.
However, this new message logging mechanism is not production-level
yet.
   Regarding your application, how tightly coupled are the containers?
Do they exchange lots of messages? How big are these messages?

On Fri, Aug 3, 2012 at 12:02 PM, 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
>
> _______________________________________________
> 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



-- 
Esteban Meneses
PhD Student
Parallel Programming Laboratory
Department of Computer Science
University of Illinois at Urbana-Champaign