Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362012-08-17T23:39:07ZEcoinformatics Redmine
Redmine Bug #5686 (New): datasets produced by archiveDataturbineDataToMetacat workflow show samples 'slid...https://projects.ecoinformatics.org/ecoinfo/issues/56862012-08-17T23:39:07ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Data sample times slowly increase, e.g. second by second, over time, instead of staying on expected markers. This makes for irregular, messy datasets. I would guess the problem lies with SPAN.</p>
<p>A dataset available here shows examples of this:<br /><a class="external" href="http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&sessionid=&docid=doc.1345243176506661893.1&displaymodule=entity&entitytype=dataTable&entityindex=1">http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&sessionid=&docid=doc.1345243176506661893.1&displaymodule=entity&entitytype=dataTable&entityindex=1</a></p>
<p>Some example problematic changes found within:</p>
<p>timestamps data<br />2012-08-16 00:10:09 13.302116394<br />2012-08-16 00:10:39 13.302242279<br />[SNIP]<br />2012-08-16 02:46:09 13.295635223<br />2012-08-16 02:46:39 13.295513153<br />2012-08-16 02:47:10 13.295863152 # <== slip<br />2012-08-16 02:47:40 13.296142578<br />[SNIP]<br />2012-08-16 08:09:10 13.290791512<br />2012-08-16 08:09:40 13.290988922<br />2012-08-16 08:10:11 13.290698051 # <== slip<br />2012-08-16 08:10:41 13.290913582<br />...</p> Bug #5685 (New): data isn't always chunked properlyhttps://projects.ecoinformatics.org/ecoinfo/issues/56852012-08-17T23:29:49ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Jing ran the workflow in Windows XP today, and it produced at least one datapackage with data from different sampling rates. See:<br /><a class="external" href="http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&sessionid=&docid=doc.1345243176506661893.1&displaymodule=entity&entitytype=dataTable&entityindex=1">http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&sessionid=&docid=doc.1345243176506661893.1&displaymodule=entity&entitytype=dataTable&entityindex=1</a></p>
<p>Example change section from data from above link:</p>
<p>2012-08-16 22:18:14 13.28463459<br />2012-08-16 22:18:44 13.284519196<br />2012-08-16 22:19:14 13.284427643<br />2012-08-16 22:19:44 13.284352303<br />2012-08-16 22:20:19 13.284294128<br />2012-08-16 22:38:14 13.28584671<br />2012-08-16 22:38:15 13.28584671<br />2012-08-16 22:38:16 13.291329384</p>
<p>These were the results Jing got from the workflow for this particular sensor:</p>
<p>Sensor Name: gpp-data/CR800_Batt_Volt<br />Document URL: <a class="external" href="http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243176506661893.1">http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243176506661893.1</a><br />Time Range: 2012-08-16 00:10:09 ~ 2012-08-16 22:38:32<br />Number of Records: 2680<br />Sensor Name: gpp-data/CR800_Batt_Volt<br />Document URL: <a class="external" href="http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243308947314582.1">http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243308947314582.1</a><br />Time Range: 2012-08-16 22:38:34 ~ 2012-08-16 22:39:54<br />Number of Records: 75<br />Sensor Name: gpp-data/CR800_Batt_Volt<br />Document URL: <a class="external" href="http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243447776683166.1">http://dev2.nceas.ucsb.edu/knb/metacat?action=read&qformat=default&docid=doc.1345243447776683166.1</a><br />Time Range: 2012-08-16 22:39:55 ~ 2012-08-17 22:37:21<br />Number of Records: 8186</p> Bug #5679 (In Progress): the workflows in sensor-view should be resaved beneath sensor-view-0.9.0...https://projects.ecoinformatics.org/ecoinfo/issues/56792012-08-16T01:28:36ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Now that sensor-view-0.9.0's suite list is finalized, the sensor-view demo workflows should be saved beneath it instead of trunk. Verify dataturbine addresses used therein.</p>
<p>Move the archive workflow into demos too. Check if any documentation refers to its current path.</p> Bug #5678 (New): growingDegreeDays workflow at kepler repository has type resolve errorhttps://projects.ecoinformatics.org/ecoinfo/issues/56782012-08-15T23:27:54Zjianwu jianwujianwu@sdsc.edu
<p>After talking to Derik, reconfiguring the DT actor to use nibbler.nceas.ucsb.edu works for me. Derik said maybe more workflows in kepler repository need to be updated.</p> Bug #5675 (New): new ProgressMeter demo workflows give errors when opening in sensor-view-0.9.0https://projects.ecoinformatics.org/ecoinfo/issues/56752012-08-11T02:03:33ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>There are a few errors when opening these xml workflows beneath sensor-view-0.9.0, despite working in trunk, e.g.:</p>
<p>ptolemy.kernel.util.NameDuplicationException: Attempt to insert object named "init" into a container that already contains an object with that name.</p>
<p>Even though the workflow only contains one "init" PortParameter.</p>
<p>After a kepler restart, I was able to save a copy of this workflow from beneath sensor-view-0.9.0, and can then re-open this copy without error.</p>
<p>I don't know the cause. Maybe these momls will have to be resaved using sensor-view-0.9.0, and the outreach test-patch release recreated.</p> Bug #5632 (New): Runtimemonitor token count idicator placement needs improvementhttps://projects.ecoinformatics.org/ecoinfo/issues/56322012-06-22T20:41:13ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>In the add-on runtimemonitor suite, if for some workflow you instantie a MonitorManager, configure it to Add counters for input and output ports, the input token counter on actors like the String Constant (which adjust their display size dynamically based on how much input there is) will not be to the left of the actor's input port as they should be, but instead over the actor.</p> Bug #5631 (New): PortParameters cannot be drag-instantiated from Outline/Items of Interest treeshttps://projects.ecoinformatics.org/ecoinfo/issues/56312012-06-19T20:23:27ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>You cannot drag out a PortParameter from the Outline/Items of Interest trees. The reason is ptolemy change r57732 to ParameterPort to avoid bug#4915:<br /> Parameter notDraggable = new Parameter(this, "_notDraggable");<br /> notDraggable.setPersistent(false);</p>
<p>This change should be removed and bug#4915 properly fixed. As part of this, we need to ensure proper behavior when dragged out from the Outline tab, and the Items of Interest panes in both Reporting and Plotting.</p> Bug #5630 (New): See about removing one set of ColorTableCellEditor and ColorTableCellRender classeshttps://projects.ecoinformatics.org/ecoinfo/issues/56302012-06-18T22:45:59ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>There are two versions of ColorTableCellEditor and ColorTableCellRenderer, one pair in Plotting, the other in Runtimemonitor. They're almost identical; there's basically one main difference, the ones in Plotting make use of an override of Color: org.kepler.sms.Color. There are 42 references to this version of Color in Plotting. Ideally we don't replicate code or override classes, so see about removing this Color class and let both modules use one set of the ColorTableCell* classes, moved into the Gui module.</p> Bug #5600 (New): Import Site Layout performance is poor for many connections at oncehttps://projects.ecoinformatics.org/ecoinfo/issues/56002012-05-07T23:11:48ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>During a recent workshop I had ~25 people at once try to Import Sensor Site from one SPAN host running on my macbook. I believe the Site Layout appeared eventually for everyone, but there was a very long wait until they began to appear -- I'd say it may have taken 5 minutes before everyone's layout appeared.</p> Bug #5583 (New): Sensor Simulator controllable through Keplerhttps://projects.ecoinformatics.org/ecoinfo/issues/55832012-03-30T03:32:16ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>To start the sensor simulator you must currently use ant to compile some classes and start it. This means a user would have to download source to use the simulator.</p>
<p>I propose creating a SensorSimulator actor that invokes the SpanSim (sensor simulator). I've tried this locally, and can get the simulator to start up from within Kepler using this actor. Stopping isn't working, and parameters (the usual simulator cmd line params) and actor documentation would have to be done too, but this seems like it could be a fairly easy solution.</p> Bug #5582 (New): DataTurbine server crashing the JREhttps://projects.ecoinformatics.org/ecoinfo/issues/55822012-03-29T03:19:05ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>I don't think this is a Kepler bug but I want to record my notes somewhere:</p>
<p>I was able to get the DataTurbine server to crash the JRE around 10 times today. Sometimes the JRE would leave a log file, I submitted one to Sun. I was using DT 3.2b5 but moved to 3.2b6, but this didn't seem to help. Likewise I moved the client (Kepler DT actor) from 3.2b5 to 3.2b6, to no avail. I was able to crash the server using both Ubuntu w/ java 1.6.0_26-b03 and osX 10.6 w/ java 1.6.0_29-b11-402-10M3527. I'm in the process of doing some cleanup on the DT actor, but I verified these crashes would occur with none of the new changes. Generally the procedure was I'd run the growingDegreeDays workflow requesting 1 day of data. After about 6-10 iterations of this workflow in succession the server would crash.</p>
<p>This hasn't been well vetted but what seems to have "fixed" it is starting the server with a larger archiveSize -- I bumped from 500000 to 1000000. Recently I loaded a lot more data to the reap02 channels, so perhaps that's why this has only recently cropped up. I've now run the GDD workflow requesting <strong>100</strong> days of data 10 times, and no crash w/ the 3.2b6 DT server on my mac. I'm going to run a long stress test over night and see what happens.</p> Bug #5400 (New): User can specify the interval of data chunk in the workflow archiving dataturbi...https://projects.ecoinformatics.org/ecoinfo/issues/54002011-05-12T21:05:06ZJing Taotao@nceas.ucsb.edu
<p>In the current workflow, it chops the data from the last archiving time to latest data stamp if there is no metadata change.</p>
<p>However, the workflow should have a feature that let user to specify the interval of dataset. For example, user can specify the interval to be month. So one dataset will have the all data generated in one month, such as March. The next dataset will contain the data in April.</p> Bug #5377 (New): DataTurbine actor fetch time outs (blockTimeout param not used?)https://projects.ecoinformatics.org/ecoinfo/issues/53772011-04-11T19:45:15ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Sometimes when attempting to connect to my gumstix DT server w/ the DT actor, I get a fetch timeout message, and no channels (i.e. no data output ports):</p>
<p>MC 12:33:02,094: [WARN]: WARNING: fetch timed out. Try increasing the blockTimeOut value [org.kepler.data.datasource.datasource.dataturbine.DataTurbine]<br />MC 12:33:02,095: [ERROR]: DataTurbine actor Error: only 0 channels were returned [org.kepler.data.datasource.datasource.dataturbine.DataTurbine]</p>
<p>The server does have channels and RDV 2.2.1 is sometimes able to show them in just 2-3 seconds. Increasing the blockTimeout actor parameter from 15s to higher doesn't seem to change anything - it still takes 15s before it times out. Either the actor is not using the parameter, or 15s is a max somewhere.</p> Bug #5364 (New): DataTurbine server memory errorhttps://projects.ecoinformatics.org/ecoinfo/issues/53642011-04-04T18:11:30ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Sometimes my gumstix DT server gives a memory error, and then stops working -- the process keeps running, but I cannot connect to it. The most recent time this happened i had been running span and spanToDT for a little under a day. I think for most of this period i sampled 1 sensor every 5s, and 2 every 30s.</p>
<p>Startup:<br />----------<br /><01-Apr-2011 Pacific Daylight Time 11:56:36.927> <dataturbine><br /> RBNB (Ring Buffered Network Bus) V3.2B5 build 2953 (built Tue Aug 31 05:47:41 Pacific Daylight Time 2010)<br /> Copyright 2006 Creare Inc.<br /> Started at address tcp://gpp.msi.ucsb.edu:3333.<br /> Archive home directory: "/var/rbnb_archive" <br /><01-Apr-2011 Pacific Daylight Time 12:50:54.179> <KeplerClient><br /> Started for sink running V3.2B5 build 2953 from Tue Aug 31 05:47:41 Pacific Daylight Time 2010.<br /><01-Apr-2011 Pacific Daylight Time 12:51:41.568> <gpp><br /> Started for source running V3.2B5 build 2953 from Tue Aug 31 05:47:41 Pacific Daylight Time 2010.<br /><01-Apr-2011 Pacific Daylight Time 12:51:41.622> <gpp><br /> Set up cache with 2 framesets of 1 frames/set (total frames = 2).<br /> Set up archive with 10 filesets of 100000 framesets/set (total frames = 1000000)<br />-----</p>
<p>Error, at the very end of log:<br />------<br />Exception in thread "gpp" java.lang.OutOfMemoryError<br /> <<No stacktrace available>><br /><02-Apr-2011 Pacific Daylight Time 10:53:49.549> <RCO com.rbnb.api.TCPRCO@40d55860><br /> java.lang.IllegalStateException: Cannot reconnect to existing client handler /dataturbine/gpp.<br /> at com.rbnb.api.RCO.login(RCO.java:1373)<br /> at com.rbnb.api.SerializingRCO.login(SerializingRCO.java:351)<br /> at com.rbnb.api.TCPRCO.login(TCPRCO.java:461)<br /> at com.rbnb.api.RCO.process(RCO.java:1653)<br /> at com.rbnb.api.RCO.run(RCO.java:2210)<br /> at java.lang.Thread.run(Thread.java:743)<br />--------</p> Bug #5363 (New): spanTodt performancehttps://projects.ecoinformatics.org/ecoinfo/issues/53632011-04-01T23:30:14ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>The spanTodt process is often hovering around 90% cpu usage on my gumstix (i'm currently sampling batt_volt every 5s, 2 other sensors every 30s, and we're still doing periodic (every 60s) metadata writes for each channel). I made logging pretty verbose, which probably isn't helping performance.<br />Would be good to improve this.</p>