[kepler-dev] Kepler won't start for me...
Shawn Bowers
sbowers at ucdavis.edu
Fri Sep 22 16:36:32 PDT 2006
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