Project

General

Profile

Bug #4008

EML 2 Dataset throws errors when accessing public data from mixed public/private datasets

Added by Oliver Soong over 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority:
Normal
Category:
actors
Target version:
Start date:
04/21/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4008

Description

When a dataset on KNB has some tables that are public and some tables that are private, EML 2 Dataset attempts to load and cache both the public and the private tables, even though only public tables are requested in the workflow. Because the actor cannot access the private data, it throws errors.

History

#1 Updated by Oliver Soong over 10 years ago

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.

#2 Updated by ben leinfelder over 10 years ago

What datapackage (id) are you downloading?

#3 Updated by Oliver Soong over 10 years ago

judithk.306.16

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

#4 Updated by Oliver Soong over 10 years ago

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.

#5 Updated by Oliver Soong over 10 years ago

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.

#6 Updated by ben leinfelder about 10 years ago

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.)

#7 Updated by Oliver Soong about 10 years ago

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...

#8 Updated by ben leinfelder about 10 years ago

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

#9 Updated by ben leinfelder almost 10 years ago

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)

#10 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 4008

Also available in: Atom PDF