[ 
https://issues.apache.org/jira/browse/PHOENIX-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Samarth Jain resolved PHOENIX-912.
----------------------------------

    Resolution: Not a Problem

> Creating a table with more than 8 salt buckets fails in tests.
> --------------------------------------------------------------
>
>                 Key: PHOENIX-912
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-912
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 3.0.0, 4.0.0
>            Reporter: Samarth Jain
>            Assignee: Samarth Jain
>
> In tests, the main thread pool in JobManager uses a SynchronousQueue with max 
> thread pool size set to 8. As a result, trying to create a salted table with 
> more than 8 salt buckets in tests fails. 
> Sample test:
> {code}
> Connection conn = DriverManager.getConnection(getUrl());
> String ddl = "CREATE TABLE IF NOT EXISTS ABC("
>                   + "PK1 CHAR(15) NOT NULL, "
>                   + "PK2 CHAR(3) NOT NULL, "
>                   + "PK3 CHAR(15) NOT NULL "
>                   + "CONSTRAINT PK PRIMARY KEY ("
>                   + "PK1, "
>                   + "PK2, "
>                   + "PK3)"
>                   + ") MULTI_TENANT=true, SALT_BUCKETS=64";
>         conn.createStatement().execute(ddl);
> Exception stacktrace:
> Caused by: java.util.concurrent.RejectedExecutionException
>       at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
>       at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
>       at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
>       at 
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
>       at 
> org.apache.phoenix.iterate.ParallelIterators.getIterators(ParallelIterators.java:245)
>       ... 38 more
> {code}
> One way to handle this would be is to use a CallerRunsPolicy as 
> RejectedExecutionHandler when using a SynchronousQueue. This way the caller 
> thread itself can take over doing the work itself when the pool is saturated. 
> This at the same time provides us a way to avoid the need of creating 
> large/unbounded sized thread pools or queues (which really is wasteful 
> considering tests spin up and tear down this pool frequently)  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to