You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Samarth Jain (JIRA)" <ji...@apache.org> on 2014/04/04 10:49:14 UTC

[jira] [Created] (PHOENIX-912) Creating a table with more than 8 salt buckets fails in tests.

Samarth Jain created PHOENIX-912:
------------------------------------

             Summary: 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)