[kepler-dev] Kepler won't start for me...

Jianting Zhang jzhang at lternet.edu
Thu Sep 28 14:02:45 PDT 2006


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