just put a configurable wait seconds between handling each workflow so the thread doesn't run amuck... we really just need to add "dirty" workflow concept... never got a chance when working on wengine

-brian

On Oct 25, 2012, at 02:19 PM, "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov> wrote:

Hey Sean,

(CC'ing dev@oodt.a.o on my reply with your permission)

We are seeing this same issue in 0.5 wengine in the trunk for Apache OODT. I've also noticed
that though it eats up 99% of the CPU, it doesn't seem to hamper the machine at all. I think it
might have something to do with the thread spin waiting approach that we're taking in both.

I'll try and do some profiling of it over the next week. I have a few finish line tasks, but
workflow/task level and condition level expansion is fully working in Wengine right now and modulo
OODT-517 [1], OODT-518 [2], and OODT-519 [3], I think we're ready to go with an 0.5 initial release
of it in the next few weeks. I am integrating the system into our Snow Near-Real-Time processing
hopefully next week and should have some more numbers and information to report.

Cheers,
Chris

[1] https://issues.apache.org/jira/browse/OODT-517
[2] https://issues.apache.org/jira/browse/OODT-518
[3] https://issues.apache.org/jira/browse/OODT-519

On Oct 25, 2012, at 11:56 AM, Hardman, Sean H (388J) wrote:

> I figured I would put this out to the internal OODT community first. ACCE is still running off of the wengine-branch [1] of OODT and we have a situation where the Workflow Manager monopolizes a processor on the machine even when it is technically not doing anything. I assumed it has something to do with constant polling, but I can't seem to find a property that governs any timing issues. It doesn't appear to cause any performance issues but the SA for the host machine badgers me about it. Has anyone seen this situation or know of a fix for it?
>
> Thanks,
> Sean
>
> [1] https://svn.apache.org/repos/asf/oodt/branches/wengine-branch/

Reply via email to