[kepler-dev] Kepler/Ptolemy thread safe code

[Paul Allen]

Thanks for the suggestions. One of the reasons that I ask I'm getting 
weird behavior (i.e. exceptions) in ptolemy.actor.Manager.

I built a class MOMLRunner (see below) that runs a model, but labels it 
with an ID by setting the top level name to that ID. When I use that 
class to run multiple models at the same time (one thread per model) in 
the same JVM, I frequently encounter an exception in ptolemy.actor.Manager.

I'm not sure how/who to pursue in debugging this. By adding log4j 
debugging to Manager, I've found that the Manager._container instance 
variable gets set to null in between the end of Manager.iterate() and 
the return of the call to Manager.iterate() inside Manager.execute() at 
line number 332 in Manager. It really makes no sense to me and I think 
can only be a issue of some non-thread-safe code in Manager or elsewhere 
Ptolemy. I can pretty consistently reproduce the problem.

I readily admit to being a mutlithread coding neophyte, but I don't 
really see how the simple code below could contribute to a 
non-thread-safe situation if the Manager code itself is thread-safe.

Any thoughts?


public class MoMLRunner {
   
    private String id = "unknown";
    private Manager _manager = null;   
    private String workflowLocation = "unknown";
   
    public MoMLRunner() throws Exception {
    }

    public MoMLRunner(String jobID, String xmlFileName) throws Throwable {
        id = jobID;
        workflowLocation = xmlFileName;
             
        MoMLParser parser = new MoMLParser();

        MoMLParser.setMoMLFilters(BackwardCompatibility.allFilters());
        MoMLParser.addMoMLFilter(new RemoveGraphicalClasses());
       
        CompositeActor toplevel = (CompositeActor) parser.parse(null,
                new File(workflowLocation).toURI().toURL());
        toplevel.setName(id);

        _manager = new Manager(toplevel.workspace(), "MoMLRunner");
        toplevel.setManager(_manager);
    }
   
    public void execute() throws Throwable {
        _manager.execute();
    }
}


Tristan King wrote:
> The 'one invocation of kepler per user' problem is only as issue with
> the kepler GUI. running multiple instances of kepler from the command
> line (i.e. using the class mentioned by Paul) works fine.
>
> Paul, i've been developing a web frontend for kepler, and i use one
> single JVM, and just execute each model in a separate thread. but i've
> not done any heavy load testing.
>
> It would probably be worth you building some tests for each method and
> testing to see which one is optimal for your conditions. And if you do,
> post the results :)
>
> good luck
> -Tristan
>
> On Wed, 2008-02-27 at 14:42 -0800, Christopher Brooks wrote:
>   
>> BTW - 
>>
>> My understanding is that currently kepler can only run one invocation
>> of Kepler per user because of issues with ~/.kepler and the database.
>> See
>>
>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2315
>>
>> _Christopher
>> Edward wrote:
>> --------
>>
>>     
>>     Paul,
>>     
>>     You may want to take a look at the contents of $PTII/demo.
>>     
>>     In that directory, there are some Ptolemy II models that execute other
>>     models, in their own threads, sequentially, or in their own JVM.
>>     
>>     Edward
>>     
>>     At 09:04 AM 2/27/2008, Paul Allen wrote:
>>     >I wanted to get some advice from the Kepler architects about the best 
>>     >approach for running multiple Kepler models programmatically, using 
>>     >something like ptolemy.actor.gui.MoMLSimpleApplication. I'm creating a 
>>     >generic workflow engine service to run models (without GUI) and need to 
>>     >know whether I should run each model in it's own JVM or whether I can 
>>     >just use a separate thread for each model, while using the same JVM. I 
>>     >think that the multiple thread approach would be easier to deal with, 
>>     >but I'm getting some indications that models running in the same JVM 
>>     >aren't entirely separate, even when I try to give them different 
>>     >workspaces to use.
>>     >
>>     >- Paul
>>     >
>>     >
>>     >_______________________________________________
>>     >Kepler-dev mailing list
>>     >Kepler-dev at ecoinformatics.org
>>     >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>     
>>     ------------ 
>>     Edward A. Lee
>>     Chair of EECS and Robert S. Pepper Distinguished Professor
>>     231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
>>     phone: 510-642-0253, fax: 510-642-2845
>>     eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.h
>>    tml  
>>     
>>     _______________________________________________
>>     Kepler-dev mailing list
>>     Kepler-dev at ecoinformatics.org
>>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>> --------
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>     
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080307/27b8913b/attachment.htm