Kepler

This workflow will throw four errors on load and the EML 2 Dataset actor will be red with an ERROR label, but it will run.

What datapackage (id) are you downloading?

judithk.306.16

2001-2003 are public, 2004-2006 are private.

Both 1.0.0 and trunk will throw errors, but trunk seems to have more difficulty than 1.0.0. Under trunk, one of the actors will be labeled ERROR and the rest will be labeled BUSY. Right clicking the ERROR actor and selecting Preview will work and that EML 2 Dataset actor will subsequently look normal. However, right clicking any of the BUSY actors and selecting Preview seems to cause Kepler to freeze. Attempting to run the workflow will freeze at the Initializing step. I'm not 100% certain Kepler wouldn't receive a timeout, but there is no CPU, network, or disk activity.

I think this is related to Kepler getting stuck at the preinitializing step, but since I don't know what happens then, I can't say for sure.

Since workflows created under kepler-trunk don't always load smoothly under kepler-1.0, here is an equivalent workflow for kepler-1.0.0. Notice that when it loads, both actors are labeled as ERROR, instead of one having BUSY. This workflow will run and both actors can be previewed.

I recognize that the error messages are annoying, but I'm not sure what the alternative is.
If you are authenticated as someone who has access for all the data tables, then there is no error.
If you use the public data, the workflow runs.
If you select data that you don't have access to, you get an error.

I was unable to make the initialization/freezing error occur.

(BTW - i don't think we need to try this on Kepler 1.0.0.)

Well, it's more than just annoying error messages. The trunk workflow doesn't work at all for me. On XP, one actor says ERROR and the other says BUSY. The workflow will not run (gets stuck at initializing). The ERROR actor can be previewed, but previewing the BUSY one will freeze Kepler.

On linux, both actors are labeled BUSY, running the workflow gets stuck at initializing, and neither can be previewed.

The interesting thing is it seems to be smoother under 1.0.0, which was the only reason for bringing that up. I'm curious how you're getting it to run...

i'm now getting stuck on the initializing step of the workflow... (osx)

still display warning messages when there is mixed public/private data that prevents a perfect datapackage download, but don't throw an exception - if we do then we prevent the other EML actors from going from BUSY->ERROR state and then the workflow cannot get past the initialize() step and it never exectues even though the data has been downloaded (at least all the data that can be downloaded given the permission constraints)

Original Bugzilla ID was 4008