[Swift-commit] r4133 - SwiftApps/SwiftR

[noreply at svn.ci.uchicago.edu]

Author: tga
Date: 2011-02-21 20:07:06 -0600 (Mon, 21 Feb 2011)
New Revision: 4133

Modified:
   SwiftApps/SwiftR/IMMEDIATE-TODO
Log:
aAdded a couple of changes to the TODO list.


Modified: SwiftApps/SwiftR/IMMEDIATE-TODO
===================================================================
--- SwiftApps/SwiftR/IMMEDIATE-TODO	2011-02-22 00:12:22 UTC (rev 4132)
+++ SwiftApps/SwiftR/IMMEDIATE-TODO	2011-02-22 02:07:06 UTC (rev 4133)
@@ -40,9 +40,13 @@
  -- micro studies on provider staging etc.
  
 HIGH:
-  - maybe needed for Bigger parallel bootstrp
- Look at all OmxNNN parallel calls - see if any are used that we dont yet handle.
 
+Coaster timeout problem:
+    He (Mihael) will also look at a better fix to the coaster timeout problem, but for now, you should integrate the timeout change from my trunk/cog/modules/provider-coaster/src/* into your test trunk/
+    Otherwise, you'll find that your coaster workers quit after a few minutes of inactivity and then start-swift needs to be killed, workers cleanup up, and start-swift restarted.
+
+
+
 MID:
 - saner approach to channels: channel per request to avoid the issue
     of what happens if a "done" is never read
@@ -80,6 +84,9 @@
 Investigate use of swift broadcase:
     swift bcast if exportAll files/data and/or xmit this via prov staging w/ caching of duplicates
 
+MID:
+Implement omxXXX parallel calls, update openmx code
+
 LOW: (unless needed by immediate OpenMx app or test)
 - complete sf compat functions (sapply, lapply -> for openMx, based on usage)
 
@@ -120,3 +127,7 @@
 
 HIGH:
 in swift.properties we should make sure we dont return info logs we should make sure that the amount of logging on both the worker side and the client side is as low as it can go
+
+HIGH:
+ Look at all OmxNNN parallel calls - see if any are used that we dont yet handle.
+ - It turns out that they are not currently needed