[ 
https://issues.apache.org/jira/browse/MAPREDUCE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459966#comment-13459966
 ] 

Kihwal Lee commented on MAPREDUCE-4662:
---------------------------------------

Manually ran test-patch against branch-1.

{noformat}
-1 overall.  

    +1 @author.  The patch does not contain any @author tags.

    -1 tests included.  The patch doesn't appear to include any new or modified 
tests.
                        Please justify why no tests are needed for this patch.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    +1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

    -1 findbugs.  The patch appears to introduce 8 new Findbugs (version 1.3.9) 
warnings.
{noformat}

* test not included since it is hard to get to the private variables for 
JobHistoryFilesManager and the ThreadPoolExecutor inside it.
* findbugs warnings : there is actually no new warning. The numbers before and 
after patch are identical.
                
> JobHistoryFilesManager thread pool never expands
> ------------------------------------------------
>
>                 Key: MAPREDUCE-4662
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-4662
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: jobhistoryserver
>    Affects Versions: 1.0.2
>            Reporter: Thomas Graves
>            Assignee: Kihwal Lee
>         Attachments: mapreduce-4662.branch-1.patch, 
> mapreduce-4662.branch-1.patch
>
>
> The job history file manager creates a threadpool with core size 1 thread, 
> max pool size 3.   It never goes beyond 1 thread though because its using a 
> LinkedBlockingQueue which doesn't have a max size. 
>     void start() {
>       executor = new ThreadPoolExecutor(1, 3, 1,
>           TimeUnit.HOURS, new LinkedBlockingQueue<Runnable>());
>     }
> According to the ThreadPoolExecutor java doc page it only increases the 
> number of threads when the queue is full. Since the queue we are using has no 
> max size it never fills up and we never get more then 1 thread. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to