[kepler-dev] Kepler/Ptolemy thread safe code

ian.brown@hsbcib.com ian.brown at hsbcib.com
Fri Mar 7 05:54:11 PST 2008

        have you tried putting a breakpoint in Manager._makeManagerOf() to 
see if it is ever called with null as an argument? It would appear to be 
the only place that _container is set.


Paul Allen <pea1 at cornell.edu> 
Sent by: kepler-dev-bounces at ecoinformatics.org
07/03/2008 13:27
Mail Size: 18786


Kepler-dev <Kepler-dev at ecoinformatics.org>
Re: [kepler-dev] Kepler/Ptolemy thread safe code
Investment Banking Europe - IBEU

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.addMoMLFilter(new RemoveGraphicalClasses());
        CompositeActor toplevel = (CompositeActor) parser.parse(null, 
                new File(workflowLocation).toURI().toURL());

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

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

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.


Edward wrote:

    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.
    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 
    >generic workflow engine service to run models (without GUI) and need 
    >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. 
    >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
    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, 
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org

Kepler-dev mailing list
Kepler-dev at ecoinformatics.org

Kepler-dev mailing list
Kepler-dev at ecoinformatics.org

HSBC Bank plc may be solicited in the course of its placement efforts for 
a new issue, by investment clients of the firm for whom the Bank as a firm 
already provides other services. It may equally decide to allocate to its 
own proprietary book or with an associate of HSBC Group. This represents a 
potential conflict of interest. HSBC Bank plc has internal arrangements 
designed to ensure that the firm would give unbiased and full advice to 
the corporate finance client about the valuation and pricing of the 
offering as well as internal systems, controls and procedures to identify 
and manage conflicts of interest.

HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.


This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080307/5c19cbe3/attachment.htm

More information about the Kepler-dev mailing list