[
https://issues.apache.org/jira/browse/OOZIE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050850#comment-14050850
]
Purshotam Shah commented on OOZIE-1886:
---------------------------------------
+1
DelayQueue is thread safe, so we don't need use lock for offer(). Java use
ReentrantLock internally.
We can keep lock for peek(), since we also do antiStarvation() as part peek().
{code}
/* */ public boolean offer(E paramE)
/* */ {
/* 82 */ ReentrantLock localReentrantLock = this.lock;
/* 83 */ localReentrantLock.lock();
/* */ try {
/* 85 */ Delayed localDelayed = (Delayed)this.q.peek();
/* 86 */ this.q.offer(paramE);
/* 87 */ if ((localDelayed == null) || (paramE.compareTo(localDelayed) <
0))
/* 88 */ this.available.signalAll();
/* 89 */ return 1;
/* */ } finally {
/* 91 */ localReentrantLock.unlock();
/* */ }
/* */ }
{code}
> Queue operation talking longer time
> -----------------------------------
>
> Key: OOZIE-1886
> URL: https://issues.apache.org/jira/browse/OOZIE-1886
> Project: Oozie
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Shwetha G S
> Assignee: Shwetha G S
> Fix For: trunk
>
> Attachments: OOZIE-1886.patch
>
>
> Purshotam Shah added a comment - 24/May/14 00:36
> We noticed that this fix is causing congestion. Queue operation were talking
> longer time than expected.
> There are two lock being used for queuing commands, which is causing delay.
> First, all queue command function of CallableQueueService is synchronized.
> Second, add function of PriorityDelayQueue need to acquire ReentrantLock
> lock, which was added as part of this patch.
> Acquiring two lock for queueing a single command was slowing down the system.
> Server was taking more than 4 sec, just to queue a command.
> After we rollback this patch and server was back to normal.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
