Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-02-06T02:19:48ZEcoinformatics Redmine
Redmine Kepler - 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> Kepler - Bug #4655 (Resolved): data packages are suddenly unusablehttps://projects.ecoinformatics.org/ecoinfo/issues/46552010-01-08T02:23:01ZOliver Soongsoong@nceas.ucsb.edu
<p>For some reason, EML 2 Dataset actors are not outputting any tokens for most output formats. The data exists at .kepler/cache/cachedata, as expected. If I set the EML 2 Dataset Data Output Format to As ColumnBased Record, then I get an error message, "The data cloumn (sic) didn't match head column". If I set the EML 2 Dataset Data Output Format to "As All Cache File Names", then things seem to work as expected. All other output formats don't seem to work.</p>
<p>Things were definitely working as of Dec. 8 and possibly Dec. 10.</p> Metacat - Bug #4651 (Resolved): data packages losing data tables (and then finding them again)https://projects.ecoinformatics.org/ecoinfo/issues/46512010-01-07T21:46:52ZOliver Soongsoong@nceas.ucsb.edu
<p>This is on the dev server. I created soong.4 for the Kruger TPCs. soong.4.14 references four data tables containing zipped spatial data, soong.3.1, soong.5.1, soong.10.1, and soong.12.1. A month or so ago, those four data tables seemed to have been lost, and attempts to access them through both Kepler and the web returned file not found XML errors. I left soong.4 alone for daigle to take a look at and created a copy soong.28.5 for me to use. Today, soong.28.5 had the same problem, and the four tables it references, soong.29.2, soong.30.2, soong.31.2, and soong.33.2, are all missing and return file not found XML errors. At the same time, soong.4.14 works again, and soong.3.1, soong.5.1, soong.10.1, and soong.12.1 all exist again.</p> Kepler - Bug #4633 (Resolved): LSID conflictshttps://projects.ecoinformatics.org/ecoinfo/issues/46332009-12-15T01:04:31ZOliver Soongsoong@nceas.ucsb.edu
<p>Create a workflow and save a KAR (KAR1). Note the LSID. Change the workflow in some recognizable fashion and save a KAR (KAR2). The LSID bumps as expected. Close the workflow and open KAR1. Make a different change (so it's obviously not the workflow in KAR2) and save the KAR (KAR3). Notice that when the workflow reopens, it looks like KAR2 because it is KAR2 down to the MOML in KAR3.</p>
<p>I'm observing this at r22183 right now.</p> Kepler - Bug #4632 (Resolved): problems when loading a KAR, changing the workflow, then re-saving...https://projects.ecoinformatics.org/ecoinfo/issues/46322009-12-14T23:07:12ZOliver Soongsoong@nceas.ucsb.edu
<p>Create a workflow and report and save the KAR. Next, change the workflow (i.e., bump the MOML LSID), save the KAR (overwrite or not doesn't seem to matter), and run it. The report should be blank. Sometimes, the ROML still exists in the KAR, so closing and re-opening works fine. In this case, the run archive contains the correct workflow_ROML.xml entry and a different ROML.#.xml that doesn't match the workflow_ROML.xml entry. Other times, the ROML seems to be lost from the KAR, in which case the run archive has no workflow_ROML.xml entry and a blank ROML.#.xml.</p> Morpho - Bug #4625 (Resolved): authenticate against KNB, switch source to DEV, and still have accesshttps://projects.ecoinformatics.org/ecoinfo/issues/46252009-12-11T02:07:26ZOliver Soongsoong@nceas.ucsb.edu
<p>I have packages that exist on DEV but not KNB. I start Morpho r4682 with KNB set as the metacat source and authenticate. I can confirm my packages are not on KNB. I then switch the metacat source to dev and open the package list and can see my packages. I can export the packages and extract the data. There was no re-authentication.</p> Morpho - Bug #4623 (Resolved): docid conflict box needs a button or somethinghttps://projects.ecoinformatics.org/ecoinfo/issues/46232009-12-11T01:26:10ZOliver Soongsoong@nceas.ucsb.edu
<p>I created a package (.1 revision), synced local->remote (.2 revision?), then edited the local EML to produce a docid conflict (another .2 revision). When trying to sync local->remote, a message pops up about a docid conflict and asks how I want to resolve this. There's a radio selector but no "Ok" button or anything like that. The only option is to close the dialog window with the X in the upper right corner, which isn't exactly intuitive. It seems to function properly, though.</p> Morpho - Bug #4622 (Resolved): local copies of zip "data tables" corrupthttps://projects.ecoinformatics.org/ecoinfo/issues/46222009-12-11T00:52:21ZOliver Soongsoong@nceas.ucsb.edu
<p>The example is soong.37.2 on the dev metacat (search for soong). The data package contains zip files as "data tables". The zip files are intact in the cache folder (can be expanded). After syncing remote->local, the zip files in the data folder are corrupt (contents can be listed but not expanded).</p> Kepler - Bug #4608 (Resolved): ROML in KAR files not being shown at allhttps://projects.ecoinformatics.org/ecoinfo/issues/46082009-12-08T20:10:55ZOliver Soongsoong@nceas.ucsb.edu
<p>ROML in KAR files is not being loaded. This happens regardless of the LSID in the workflow and ROML matching the InstanceAuthNamespace. This happens regardless of opening from a local repository or not.</p>
<p>This is happening at 22117, but I think I also saw it at 22111. I'm guessing it has something to do with 22083, although I can't be sure.</p> Kepler - Bug #4559 (Resolved): local repositories not showing up in components treehttps://projects.ecoinformatics.org/ecoinfo/issues/45592009-11-19T22:25:52ZOliver Soongsoong@nceas.ucsb.edu
<p>Summary says it all. I'm at r21772, and the default workflows repository isn't in the components tree. Adding repositories doesn't do anything. I'm not even getting prompts to sign into KNB or DEV to cache data.</p> Kepler - Bug #4527 (Resolved): reports cannot be loaded when InstanceAuthNamespace changeshttps://projects.ecoinformatics.org/ecoinfo/issues/45272009-11-04T03:39:51ZOliver Soongsoong@nceas.ucsb.edu
<p>Generate a report and save the KAR. Close Kepler, clean-all, delete the configuration folder, LastObjectID, and .ptolemy-compiled (I think that's almost everything that Kepler generates). Run Kepler again, and open the KAR. The report layout should be there. Now close Kepler and delete only InstanceAuthNamespace. Run Kepler again and open the KAR. The report should not be there.</p>
<p>This makes it hard to transport a KAR file to another computer or even another build of Kepler.</p> Kepler - Bug #4521 (Resolved): KNB data error checking is overly aggressivehttps://projects.ecoinformatics.org/ecoinfo/issues/45212009-11-04T01:03:36ZOliver Soongsoong@nceas.ucsb.edu
<p>On r21314, I can no longer access the Kruger data. I believe this is due to some overly aggressive error checking on the data. The data packages (which are not directly under my control) have thrown errors on the console. I think this is due to negative numbers and zeroes in columns that are nominally whole numbers. In the past, there were non-fatal, but this is now major problem.</p>
<p>This change happened somewhere between r21218 and r21310.</p>
<p>The error message is specifically "Unable to parse the MetaData: Error parsing the eml package: Exception in DataTypeResolver"</p> Kepler - Bug #4507 (Resolved): report designer losing content when there are too many itemshttps://projects.ecoinformatics.org/ecoinfo/issues/45072009-10-27T23:25:05ZOliver Soongsoong@nceas.ucsb.edu
<p>If I have a lot of items in the report designer, the scroll bar seems to be too short for the content. Eventually, there are figures that are above and below the scrollable area and are not accessible. They still show up in reports, though.</p> Morpho - Bug #4461 (New): delete local copy only deletes the most recent stored revision, but thi...https://projects.ecoinformatics.org/ecoinfo/issues/44612009-10-15T18:48:02ZOliver Soongsoong@nceas.ucsb.edu
<p>When deleting a package in the package listing, the current behavior is to delete only the most recent stored copy. However, it just says "Delete". This is particularly confusing when compounded with the fact that after deleting, the entry disappears from the package listing entirely even though earlier copies exist. Only after closing the package listing and reopening it can the user see the previous revision.</p>
<p>A relatively simple fix would be to change Delete to Delete Most Recent Copy. It might also help for users who do want to get rid of an entire package to have a Delete Package entry. It might also help to have the package list refresh after the delete.</p> Morpho - Bug #4460 (New): morpho package listing can be confusing when out of synchttps://projects.ecoinformatics.org/ecoinfo/issues/44602009-10-15T18:43:32ZOliver Soongsoong@nceas.ucsb.edu
<p>This is a UI and clarity issue. Morpho's handling of versions is fine.</p>
<p>In the case of an old local copy and updated online copies, there is no indication in the package listing that there are old copies sitting around (the package listing shows an icon only for the remote copy and no local data). From the perspective of a sometimes offline user, it can appear that work on that old local copy has disappeared.</p>
<p>Similarly, a user who has an old local copy, but signs in and looks at the package listing might be led to believe there is no local data. When that user looks at the package listing offline, it might be surprising to see a local copy. There is also no indication that the data is out of date, even though the (possibly stale) cache might actually contain enough information to flag the local copy as out of date.</p>
<p>Adding something simple like a "stale local copies" icon would help clear this up, instead of using the same blank indication for no local data and local data out of date.</p>