[kepler-dev] Kepler/Ptolemy thread safe code
ian.brown at hsbcib.com
ian.brown at hsbcib.com
Fri Mar 7 05:54:11 PST 2008
Paul,
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.
Ian
Paul Allen <pea1 at cornell.edu>
Sent by: kepler-dev-bounces at ecoinformatics.org
07/03/2008 13:27
Mail Size: 18786
To
cc
Kepler-dev <Kepler-dev at ecoinformatics.org>
Subject
Re: [kepler-dev] Kepler/Ptolemy thread safe code
Entity
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.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
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
************************************************************
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.
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!
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/kepler/pipermail/kepler-dev/attachments/20080307/5c19cbe3/attachment.html>
More information about the Kepler-dev
mailing list