You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2019/05/01 13:30:00 UTC

[jira] [Commented] (QPID-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor

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

ASF GitHub Bot commented on QPID-8304:
--------------------------------------

alex-rufous commented on pull request #29: QPID-8304: [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor
URL: https://github.com/apache/qpid-broker-j/pull/29#discussion_r280071020
 
 

 ##########
 File path: broker-plugins/jdbc-store/src/main/java/org/apache/qpid/server/store/jdbc/AbstractJDBCMessageStore.java
 ##########
 @@ -216,7 +216,7 @@ private void updateDbVersion(int newVersion) throws SQLException
     protected void initMessageStore(final ConfiguredObject<?> parent)
     {
         _parent = parent;
-        _executor = new ScheduledThreadPoolExecutor(4, new ThreadFactory()
+        _executor = new ScheduledThreadPoolExecutor(Runtime.getRuntime().availableProcessors(), new ThreadFactory()
 
 Review comment:
   Olivier,
   I am wandering whether it would be better to introduce a context variable for configuring the number of core threads in executor. Potentially, the default value can be set to 'availableProcessors' but I am a bit concerned about setting core threads number to 'availableProcessors'. On machines with hundreds of CPUs that might result in wasted system resources. Please note, that we are starting all core threads immediately after executor creation.  I think, that for this kind of tasks we need a special executor which can scale threads up and down when required.  Though, I do not want to spend time on such executor implementation.  
   
   I created a pull request #32 where I moved setting of "qpid.jdbcstore.inClauseMaxSize" into context variables. I think we need to do the same for the number of core threads for the pool executor.  For example, we can introduce context variable like "qpid.jdbcstore.commitExecutorThreads". As we do not have executor capable of scaling number of threads up and down, I suppose, we can set the default value to Runtime.getRuntime().availableProcessors().
   
   What do you think about suggested changes?
   
   I am planning to commit PR #32 tonight if you have no objection
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor
> ----------------------------------------------------------------------------------
>
>                 Key: QPID-8304
>                 URL: https://issues.apache.org/jira/browse/QPID-8304
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>    Affects Versions: qpid-java-broker-7.1.0
>            Reporter: Olivier VERMEULEN
>            Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org