Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-11-30T22:50:17ZEcoinformatics Redmine
Redmine Bug #5249 (In Progress): test kepler for memory leakshttps://projects.ecoinformatics.org/ecoinfo/issues/52492010-11-30T22:50:17Zjianwu jianwujianwu@sdsc.edu
<p>a separate bug only for memory leak fixing for Kepler suite. bug 5095 depends on it.</p> Bug #5095 (In Progress): test kepler and wrp for memory leakshttps://projects.ecoinformatics.org/ecoinfo/issues/50952010-07-14T22:56:35ZMatt Jonesjones@nceas.ucsb.edu
<p>Oliver Soong reported having difficulties with memory leaks. There are two specific bugs about this, which I have set to block this testing bug. In addition, testing may reveal additional leaks, which should be fixed before 2.1 is released. Here's Oliver's synopsis of the issues:</p>
<p>I think this is limited to the wrp suite, but Kepler’s performance degrades significantly over time. Provenance recording can become prohibitively slow, and there is no native in-Kepler fix. There is a large memory leak somewhere, and many components are quite memory-intensive regardless. Given the intention to record executions and the large number of analyses scientists perform, I suspect any dedicated user of Kepler will quickly encounter data management problems. In my case, I stopped using local repositories and began closing Kepler after running any large workflows.</p> Bug #4883 (New): Need more command line options for kar fileshttps://projects.ecoinformatics.org/ecoinfo/issues/48832010-03-15T20:51:05ZChad Berkleyberkley@nceas.ucsb.edu
<p>right now, we can execute a single workflow contained in a kar file with the -runwf command line switch. It would be nice to have more options for working with kar files on the command line. The minimal options I would like to see are:</p>
<p>1) allow the user to specify which workflow within a kar file to execute (if there is >1). <br />2) allow the user to specify the output location. Either a server or local directory.<br />3) allow the use of a remote kar file with an https url (i.e. for a kar file stored in a repository).</p>
<p>Please add more requirements as you see fit. We will add this to the queue of post-2.0 enhancements.</p> Bug #4785 (New): move cache object from 1.0 to 2.0https://projects.ecoinformatics.org/ecoinfo/issues/47852010-02-10T23:13:31ZChad Berkleyberkley@nceas.ucsb.edu
<p>Cache kar objects from 1.0 that contain customized actors (i.e. not those shipped with 1.0) need to be migrated to the 2.0 installation. Any kars that include jars must be made into modules (see bug 4702).</p> Bug #4764 (New): ProvenanceRecorder.changeExecuted slow after workflow runhttps://projects.ecoinformatics.org/ecoinfo/issues/47642010-02-06T02:19:48ZOliver Soongsoong@nceas.ucsb.edu
<p>If I run any of the tpc workflows (e.g., tpc09), any subsequent changes to Kepler (say changing workflow parameters) cause Java to peg one of my CPU cores. This includes canceling changes to RExpression. I've seen this behavior on Windows XP and 7. While I haven't seen it under linux or OS X, I haven't tested those as extensively. I have tried small test workflows, and haven't seen a particularly noticeable slowdown, so it may be related to the size of the workflow run. I have to restart Kepler to get things back up to speed, and it's bad enough that I'm actually restarting Kepler after every run.</p>
<p>I'm not sure it's a memory thing. java.exe is about maxed out on memory (~0.5 GB) in the Task Manager, but the Check System Settings window says I have 46% free. I was watching jstat, and changes don't seem to trigger a flurry of garbage collection.</p> Bug #4735 (New): Allow params to be passed to ConfigurationManager from the command linehttps://projects.ecoinformatics.org/ecoinfo/issues/47352010-02-04T20:48:06ZChad Berkleyberkley@nceas.ucsb.edu
<p>Need a mechanism for passing params to CM from the command line. This is a post 2.0 feature.</p> Bug #4341 (New): rearrange the actors module into smaller moduleshttps://projects.ecoinformatics.org/ecoinfo/issues/43412009-08-26T22:54:57ZChad Berkleyberkley@nceas.ucsb.edu
<p>I'll create a list of proposed modules for the actors currently all lumped together in the actors module. The new module names should have a naming convention of "actors-xxx" so that they all sort together and so that it's evident that the module is primarily an actor module. Once I'm done with this list, I'll post it to the wiki and we can have an email discussion about how others think the actors should be re-modularized.</p> Bug #4328 (New): change-to command checks out across brancheshttps://projects.ecoinformatics.org/ecoinfo/issues/43282009-08-21T18:54:18ZChad Berkleyberkley@nceas.ucsb.edu
<p>If kepler is currently in a branch, the change-to command should not update from the trunk. Once a branch is selected with the -Dbranch=xxx param, the build system should keep the current workspace in the branch until the user updated to another branch or the trunk. The build system should also print a banner alerting the user that he/she is working in a branch to avoid confusion.</p>
<p>this bug arose when we added several modules to the trunk. Matt was working in a branch (unknowingly) and when he ran 'ant change-to -Dsuite=kepler' it updated the kepler/module-info/modules.txt file from the trunk, but did not update the rest of the modules to the trunk so the build failed. The build-area was also running from the branch so the excludes file was not updated and would not allow him to build ptolemy.</p> Bug #4310 (New): ValueListeners receive valueChanged events when values have not changedhttps://projects.ecoinformatics.org/ecoinfo/issues/43102009-08-13T18:34:29ZDaniel Crawldanielcrawl@gmail.com
<p>A ValueListener sometimes receives events for a Settable when the Settable's value has not changed. This can lead to a stack overflow since reading the value of the Settable may generate another valueChanged event.</p>
<p>To fix this, valueChanged not be called unless the value has actually changed.</p> Bug #4290 (In Progress): Separate the GUI from the execution engine.https://projects.ecoinformatics.org/ecoinfo/issues/42902009-08-07T21:49:07ZDavid Welkerwelker4kepler@gmail.com
<p>The GUI needs to be separated from the execution engine so that it is easy to develop specialized GUIs for a particular domain. The path for developing a new GUI that uses the execution engine should be well defined. For example, if one wanted to develop a new GUI with a different technology (i.e. Flex) or for a very specialized domain there should be a well-defined path for proceeding.</p>
<p>This is a Kepler/CORE grant requirement.</p> Bug #4287 (In Progress): Separate user error messages from developer error messages.https://projects.ecoinformatics.org/ecoinfo/issues/42872009-08-07T21:40:03ZDavid Welkerwelker4kepler@gmail.com
<p>An error in the GUI should never display a nonsensical stack trace to the user. All stack traces involving the GUI and other errors made to be read by the developer should be logged to file (and optionally standard out).</p> Bug #4260 (New): Add a test suite for the build systemhttps://projects.ecoinformatics.org/ecoinfo/issues/42602009-07-22T18:25:27ZChad Berkleyberkley@nceas.ucsb.edu
<p>Need to create a testing harness for the build system to ensure that all functionality remains working as new features are added. This should be run with the nightly build.</p> Bug #4246 (In Progress): Reorganize code in util, core and gui moduleshttps://projects.ecoinformatics.org/ecoinfo/issues/42462009-07-14T18:33:12ZChad Berkleyberkley@nceas.ucsb.edu
<p>The code in the main modules still needs to be reorganized a bit. There is gui code in core that needs to be moved to gui or util. The util module itself should be disassembled into other modules that are more fitting of the nature of the code. Not sure if this should be done for 2.0 or post 2.0. will target to 2.0 for now.</p> Bug #4153 (In Progress): report-overrideshttps://projects.ecoinformatics.org/ecoinfo/issues/41532009-06-12T21:04:56ZAaron Aaronaschultz@nceas.ucsb.edu
<p>"ant report-overrides" build target does not include xml files (such as config.xml or configuration.xml).</p> Bug #3210 (New): add netCDF support to Keplerhttps://projects.ecoinformatics.org/ecoinfo/issues/32102008-04-04T17:05:47ZMatt Jonesjones@nceas.ucsb.edu
<p>Many scientific data sets are represented in netcdf format (<a class="external" href="http://www.unidata.ucar.edu/software/netcdf/">http://www.unidata.ucar.edu/software/netcdf/</a>). Kepler should be able to read and expose data from these formats via a DataSource actor similar in concept to the EML, DarwinCore, RBNB, and OpenDAP actors.</p>
<p>Common libraries for parsing netcdf are available, including a Java library (<a class="external" href="http://www.unidata.ucar.edu/software/netcdf-java/">http://www.unidata.ucar.edu/software/netcdf-java/</a>).</p>