[infinispan-issues] [JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxServiceCleanup thread pool even when the cache is NON_TRANSACTIONAL

Guillermo GARCIA OCHOA (JIRA) issues at jboss.org
Thu Feb 20 03:07:47 EST 2014


     [ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillermo GARCIA OCHOA updated ISPN-4027:
-----------------------------------------

    Description: 
In the {{TransactionTable.start()}} each cache creates a thread pool and a job is scheduled to clean up completed transactions.
{code:java}
private void start() {
      ...
      totalOrder = configuration.transaction().transactionProtocol().isTotalOrder();
      if (!totalOrder) {
         // Periodically run a task to cleanup the transaction table from completed transactions.
         ThreadFactory tf = new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
               String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
               Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
               th.setDaemon(true);
               return th;
            }
         };

         executorService = Executors.newSingleThreadScheduledExecutor(tf);

         long interval = configuration.transaction().reaperWakeUpInterval();
         executorService.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
               cleanupCompletedTransactions();
            }
         }, interval, interval, TimeUnit.MILLISECONDS);
      }
}
{code}

As you can see in the code, even is the cache is {{NON_TRANSACTIONAL}} the job is scheduled, consuming resources to do nothing (the {{completedTransactions}} map is always empty)

Maybe I'm missing something, but our application profiling is showing us that these threads do nothing but they are consuming precious resources because we have more than 1000 {{NON_TRANSACTIONAL}} caches.

(i) This can be considered when solving ISPN-3702 too.

  was:
In the {{TransactionTable.start()}} each cache creates a thread pool and a job is scheduled to clean up completed transactions.
{code:java}
private void start() {
      ...
      totalOrder = configuration.transaction().transactionProtocol().isTotalOrder();
      if (!totalOrder) {
         // Periodically run a task to cleanup the transaction table from completed transactions.
         ThreadFactory tf = new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
               String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
               Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
               th.setDaemon(true);
               return th;
            }
         };

         executorService = Executors.newSingleThreadScheduledExecutor(tf);

         long interval = configuration.transaction().reaperWakeUpInterval();
         executorService.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
               cleanupCompletedTransactions();
            }
         }, interval, interval, TimeUnit.MILLISECONDS);
      }
}
{code}

As you can see in the code, even is the cache is {{NON_TRANSACTIONAL}} the job is scheduled, consuming resources to do nothing (the {{completedTransactions}} map is always empty)

Maybe I'm missing something, but our application profiling is showing us that these threads do nothing but they are consuming precious resources because we have more than 1000 {{NON_TRANSACTIONAL}} caches.


    
> TransactionTable.start() initialize the TxServiceCleanup thread pool even when the cache is NON_TRANSACTIONAL
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-4027
>                 URL: https://issues.jboss.org/browse/ISPN-4027
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 6.0.1.Final
>            Reporter: Guillermo GARCIA OCHOA
>            Assignee: Mircea Markus
>
> In the {{TransactionTable.start()}} each cache creates a thread pool and a job is scheduled to clean up completed transactions.
> {code:java}
> private void start() {
>       ...
>       totalOrder = configuration.transaction().transactionProtocol().isTotalOrder();
>       if (!totalOrder) {
>          // Periodically run a task to cleanup the transaction table from completed transactions.
>          ThreadFactory tf = new ThreadFactory() {
>             @Override
>             public Thread newThread(Runnable r) {
>                String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
>                Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
>                th.setDaemon(true);
>                return th;
>             }
>          };
>          executorService = Executors.newSingleThreadScheduledExecutor(tf);
>          long interval = configuration.transaction().reaperWakeUpInterval();
>          executorService.scheduleAtFixedRate(new Runnable() {
>             @Override
>             public void run() {
>                cleanupCompletedTransactions();
>             }
>          }, interval, interval, TimeUnit.MILLISECONDS);
>       }
> }
> {code}
> As you can see in the code, even is the cache is {{NON_TRANSACTIONAL}} the job is scheduled, consuming resources to do nothing (the {{completedTransactions}} map is always empty)
> Maybe I'm missing something, but our application profiling is showing us that these threads do nothing but they are consuming precious resources because we have more than 1000 {{NON_TRANSACTIONAL}} caches.
> (i) This can be considered when solving ISPN-3702 too.

--
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


More information about the infinispan-issues mailing list