oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: [oodt-dev] Workflow Manager in wengine-branch chews up CPU
Date Fri, 26 Oct 2012 00:43:49 GMT
Hey Brian,

Yep we have that in wengine in OODT 0.5 trunk right now too.

The dirty workflow concept sounds neat -- could you elaborate?


On Oct 25, 2012, at 2:31 PM, Brian Foster wrote:

> 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.mattmann@jpl.nasa.gov>
>> 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
>> 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
>> 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/

View raw message