[kepler-dev] Kepler won't start for me...
Shawn Bowers
sbowers at ucdavis.edu
Thu Sep 28 12:38:07 PDT 2006
I take back the statement I made below. In particular, after checking on
this (by chasing Ptolemy class code), it appears that I was mistaken and
exportMoML doesn't get called when an actor is added to the library model.
When an actor is added to an entity library, it looks as though eventually
that item is instead simply added to the Library's internal linked list.
However, I still think the best thing for Kepler would be to create a new
kind of TreeModel that can leverage our existing indexing mechanism, used
currently in Kepler to create the "VisibleTreeModel". The current index
essentially consists of "folder" names (actually, names plus ontology
class ids) and actor identifiers (LSIDs).
-shawn
On Fri, 22 Sep 2006, Shawn Bowers wrote:
>
> I believe the problem is that the same mechanism used to add an actor to
> Ptolemy's left-hand panel/model is the same mechanism used to add an actor
> to the workflow canvas (model). Both of these involve, again if I recall
> correctly, instead of simply adding the object to the model, literally
> inserting the result of calling exportMoML() of the actor/item to the
> desired model.
>
> I believe Ilkay a while back brought up a similar issue where they where
> trying to essentially parameterize exportMoML() to allow for it to return
> different information depending on the parameter.
>
> -shawn
>
>
>
> On Fri, 22 Sep 2006, Christopher Brooks wrote:
>
> > Sounds like we can work on Ptolemy so that it can handle proxies!
> >
> > What would need to happen?
> >
> > _C
> >
> > --------
> >
> >
> > > There are lots of things about Ptolemy that I don't like, but one
> > > thing I do like is that I can start up even if some package somewhere
> > > is not quite right. It would be nice to see this work in Kepler
> > > in a similar fashion.
> >
> > Sure -- but also its useful to know ahead of time if there is a problem. I
> > think both of these can be achieved, except ... .
> >
> > > I'm not sure I understand why the search mechanism can't be modified
> > > to search proxies, but then again, I don't understand much about the
> > > search mechanism :-)
> >
> > The search mechanism could easily be extended to support proxies -- it
> > would be trivial. The problem is that Ptolemy can't be easily extended to
> > support proxies ...
> >
> > -shawn
> >
> >
> > >
> > > _Christopher
> > >
> > > --------
> > >
> > > We've encountered this DB lock problem before. Its not related to th
> > e
> > > tree, but to the underlying database for data access. I think Jing
> > > might be able to clarify the details, but try killing all kepler
> > > processes and then deleting the hsqldb.lck file and starting up Keple
> > r.
> > >
> > > I agree the startup sequence is a problem. I'm hoping that we can
> > > eliminate the need to load every actor upon startup (or even upon
> > > opening a tree node) by using a proxy object in the tree that represe
> > nts
> > > just some metadata about the actor. Only upon DnD onto the canvas wo
> > uld
> > > the actor be instantiated. This should help tremendously with startu
> > p
> > > time and initial reliability (of course at the expense of not seeing
> > the
> > > errors until someone tries to use an actor).
> > >
> > > Matt
> > >
> > > Christopher Brooks wrote:
> > > > Yep, you probably have two keplers running.
> > > > There is an open bug for this problem.
> > > >
> > > > There is also an open bug for the start up speed issue.
> > > >
> > > > _C
> > > > --------
> > > >
> > > >
> > > > Kepler won't start for me... I get the following
> > > > exception (BTW, this sort of experience has convinced me that
> > > > this idea of loading all the actors at startup time was a reall
> > y
> > > > bad idea, and in fact could ultimately make Kepler unusable...
> > > > Can I talk you into going back to the Ptolemy II model of loadi
> > ng
> > > > actors only when the libraries are opened?).
> > > >
> > > > Any suggestions for starting Kepler? I tried deleting the lock
> > > > file, but the OS won't let me, telling me some other applicatio
> > n
> > > > is using it. I suspect the other application is Kepler, left
> > > > over from a previous failed attempt to start it...
> > > >
> > > > Edward
> > > >
> > > > Caused by: java.sql.SQLException: The database is already in us
> > e by
> > > > another process: org.hsqldb.NIOLockFile at c06705ff[file =C:\Docum
> > ents
> > > > and Settings\eal\.kepler\cache\cachedata\hsqldb.lck, exists=tru
> > e,
> > > > locked=false, valid=false, fl =null]: java.lang.Exception: The
> > > > process cannot access the file because another process has lock
> > ed a
> > > > portion of the file : C:\Documents and
> > > > Settings\eal\.kepler\cache\cachedata\hsqldb.lck
> > > > at org.hsqldb.jdbc.jdbcUtil.sqlException(Unknown Sourc
> > e)
> > > > at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Sourc
> > e)
> > > > at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
> > > > at org.hsqldb.jdbcDriver.connect(Unknown Source)
> > > > at java.sql.DriverManager.getConnection(DriverManager.
> > java:5
> > > 25)
> > > > at java.sql.DriverManager.getConnection(DriverManager.
> > java:1
> > > 71)
> > > > at
> > > > org.ecoinformatics.util.DBConnectionFactory.getDBConnection(DBC
> > onnect
> > > ionFac
> > > > tory.java:91)
> > > > at
> > > > org.ecoinformatics.util.DBConnectionFactory.getDBConnection(DBC
> > onnect
> > > ionFac
> > > > tory.java:73)
> > > > at org.kepler.gui.KeplerInitializer.initializeSyste
> > > > ....
> > > >
> > > > ------------
> > > > Edward A. Lee
> > > > Professor, Chair of EECS
> > > > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> > > > phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> > > > eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> > > >
> > > > _______________________________________________
> > > > Kepler-dev mailing list
> > > > Kepler-dev at ecoinformatics.org
> > > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/k
> > epler-
> > > dev
> > > > --------
> > > > _______________________________________________
> > > > Kepler-dev mailing list
> > > > Kepler-dev at ecoinformatics.org
> > > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/keple
> > r-dev
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Matthew B. Jones
> > > jones at nceas.ucsb.edu Ph: 805-617-4179
> > > National Center for Ecological Analysis and Synthesis (NCEAS)
> > > UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > --------
> > > _______________________________________________
> > > Kepler-dev mailing list
> > > Kepler-dev at ecoinformatics.org
> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > >
> > --------
> >
>
More information about the Kepler-dev
mailing list