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

Edward A. Lee eal at eecs.berkeley.edu
Sat Sep 23 05:20:52 PDT 2006


Interestingly, I actually had to kill Eclipse to get Kepler to start up.
There was a hung, not-quite started Kepler process that wouldn't show up
on the task bar and that Eclipse seemed to be unaware of...

I'm puzzled by the argument that something (even proxies) have to be
loaded at start time for search to work.  I would have to conclude that
in order to use google, I have to load a copy of the internet on reboot :-)
Why can't search be done using index files and accessing them on demand?

On the proxies question, we've been doing some performance profiling
(for other purposes) and have significantly improved load times for
certain things... However, a large fraction of load times now is in
the XML parser. It would probably require substituting another XML
parser to make this better.  I don't really want to do this
since (1) it would be a lot of work, (2) it would give us no increment
in functionality, and (3) it could make things worse, and we wouldn't
know until we had done it.

Also, I actually doubt that loading proxies
instead of actors would help for most actors (clearly it would help
for actors that do things like accessing the net on construction, but
this is arguably problematic anyway).

As for whether the XML reading/writing/processing is excessive,
it's hard to know how to reduce this.  Most library entries for an
actor read like this:

   <entity name="Ramp" class="ptolemy.actor.lib.Ramp"/>

How could this be trimmed down? Note that the Entity ID
in Kepler more than doubles the amount of XML for each item...
As far as I know, there is no XML writing at startup...

I think is the flaw is in the concept that everything has to be
looked at on startup...

Edward


At 03:49 PM 9/22/2006, Shawn Bowers wrote:

>On Fri, 22 Sep 2006, Edward A. Lee wrote:
>
> > (BTW, this sort of experience has convinced me that this idea of loading
> > all the actors at startup time was a really bad idea, and in fact could
> > ultimately make Kepler unusable... Can I talk you into going back to the
> > Ptolemy II model of loading actors only when the libraries are opened?).
>
>The reason we are doing the "full load" is because we want to be able to
>search over the actors -- and Ptolemy provides no support for this without
>loading the actors.  In fact, it is even worse than this, since we also
>can't use the current Ptolemy infrastructure/classes to load "proxies" of
>actors ...  I think the main reason why it takes so long, and also the
>reason why we haven't implemented a better solution, has actually more to
>do with the excessive XML writing/reading/processing going on in how
>Ptolemy loads/processes actors.
>
>-shawn
>
> >
> > Any suggestions for starting Kepler?  I tried deleting the lock
> > file, but the OS won't let me, telling me some other application
> > 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 use by
> > another process: org.hsqldb.NIOLockFile at c06705ff[file =C:\Documents
> > and Settings\eal\.kepler\cache\cachedata\hsqldb.lck, exists=true,
> > locked=false, valid=false, fl =null]: java.lang.Exception: The
> > process cannot access the file because another process has locked a
> > portion of the file : C:\Documents and
> > Settings\eal\.kepler\cache\cachedata\hsqldb.lck
> >          at org.hsqldb.jdbc.jdbcUtil.sqlException(Unknown Source)
> >          at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
> >          at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
> >          at org.hsqldb.jdbcDriver.connect(Unknown Source)
> >          at java.sql.DriverManager.getConnection(DriverManager.java:525)
> >          at java.sql.DriverManager.getConnection(DriverManager.java:171)
> >          at
> > 
> org.ecoinformatics.util.DBConnectionFactory.getDBConnection(DBConnectionFactory.java:91)
> >          at
> > 
> org.ecoinformatics.util.DBConnectionFactory.getDBConnection(DBConnectionFactory.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/kepler-dev
> >

------------
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  



More information about the Kepler-dev mailing list