[kepler-dev] Kepler won't start for me...
Shawn Bowers
sbowers at ucdavis.edu
Thu Sep 28 14:07:32 PDT 2006
Hi Jianting,
This is essentially what is happening, actually.
Currently, actor metadata is stored in the "object manager" -- using
hypersonic. The index is being built directly from the actors stored in
the object manager, then used to load/build (by resolving actor lsids) a
so-called visible tree model. I'm suggesting we skip the last step -- and
use the index directly.
-shawn
On Thu, 28 Sep 2006, Jianting Zhang wrote:
> Are there any specific reasons against using RDBMS (HSQLDB) to manage the
> actor library? A simple horizontal/vertical partition should suffice to
> decompose the XML doc into a few tables. Indexing is easier and query should
> be more efficient. Accessing to a single table should be enough to retrieve
> the proxy data and instantiations of Java classes can be optional or on
> demand based on query results... If people want to readable the XML codes of
> the library, click a button and generate it on the fly.
>
> Indeed, Protégé also has a database engine for large OWL files. While there
> are researches on native XML database, most likely people still use XML for
> data exchange and use RDBMS for query processing... if response time is
> critical.
>
> Jianting
>
>
>
> -----Original Message-----
> From: kepler-dev-bounces at ecoinformatics.org
> [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
> Sent: Thursday, September 28, 2006 1:38 PM
> To: Christopher Brooks
> Cc: Kepler-Dev
> Subject: Re: [kepler-dev] Kepler won't start for me...
>
>
> 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
> > > >
> > > --------
> > >
> >
> _______________________________________________
> 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