[ https://issues.apache.org/jira/browse/OOZIE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623360#comment-16623360 ]
Peter Bacsko commented on OOZIE-3160: ------------------------------------- {{TestCallableQueueService#testQueueSizeWhenMaxConcurrencyIsReached()}} yeah I understand why it's flaky. It's a bit difficult to write this test to be super-stable. Basically we want to verify that after submitting 10000 elements, the queue size is close to this number. By the time we retrieve the number, a number of elements have already been removed, depending on how fast the computer is. It's not evident how to choose a good threshold. Looks like >9000 is too high. Maybe something like >5000? I can think of a better approach: use barriers or latches in the XCallables and let them run only after we examined the queue size. This would give us a stable result of queue size == 10000. > PriorityDelayQueue put()/take() can cause significant CPU load due to busy > waiting > ---------------------------------------------------------------------------------- > > Key: OOZIE-3160 > URL: https://issues.apache.org/jira/browse/OOZIE-3160 > Project: Oozie > Issue Type: Bug > Components: core > Affects Versions: trunk > Environment: all platforms > Reporter: jj > Assignee: Peter Bacsko > Priority: Major > Fix For: 5.1.0 > > Attachments: 11111111111111.png, 222222222222222222.png, > OOZIE-3160-001.patch, OOZIE-3160-002.patch, OOZIE-3160-003.patch, > OOZIE-3160-004.patch, OOZIE-3160-005.patch, OOZIE-3160-006.patch, > OOZIE-3160-007.patch, OOZIE-3160-POC01.patch, OOZIE-3160-POC02.patch, > OOZIE-3160-POC02.patch, OOZIE-3160-POC03.patch, OOZIE-3160-POC04.patch, > OOZIE-3160-POC05.patch, OOZIE-3160.amend.001.patch, PriorityDelayQueue > improvement - OOZIE-3160.pdf > > > oozie process always consume high cpu. in my mechine,around 10%. > I check the source code,find take() method in PriorityDelayQueue class。 > code: > {code:java} > public QueueElement<E> take() throws InterruptedException { > QueueElement<E> e = poll(); > while (e == null) { > Thread.sleep(10); > e = poll(); > } > return e; > } > {code} > i think it's the reason of this problem. it's keep while, not await. -- This message was sent by Atlassian JIRA (v7.6.3#76005)