[
https://issues.apache.org/jira/browse/YARN-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177616#comment-16177616
]
Daniel Templeton commented on YARN-7135:
----------------------------------------
I looked through the source, and it throws Error, but I didn't see any
unchecked exceptions explicitly created. That doesn't mean one can't happen in
an unexpected way. There's a good bit of code in there... In any case, just
because the current choice of RW lock implementation doesn't throw an
exception, that doesn't mean we'll never switch to one that does. Better to be
safe.
> Clean up lock-try order in common scheduler code
> ------------------------------------------------
>
> Key: YARN-7135
> URL: https://issues.apache.org/jira/browse/YARN-7135
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: scheduler
> Affects Versions: 3.0.0-alpha4
> Reporter: Daniel Templeton
> Assignee: weiyuan
> Labels: newbie
> Attachments: YARN-7135.001.patch, YARN-7135.002.patch,
> YARN-7135.003.patch, YARN-7135.004.patch
>
>
> There are many places that follow the pattern:{code}try {
> lock.lock();
> ...
> } finally {
> lock.unlock();
> }{code}
> There are a couple of reasons that's a bad idea. The correct pattern
> is:{code}lock.lock();
> try {
> ...
> } finally {
> lock.unlock();
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
