[JBoss JIRA] (ISPN-6096) Cache container page does not show any containers when more hotrod-connectors are defined
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6096?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6096:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Alpha2
Resolution: Done
> Cache container page does not show any containers when more hotrod-connectors are defined
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-6096
> URL: https://issues.jboss.org/browse/ISPN-6096
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Martin Gencur
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Alpha2
>
>
> When there's more than one <hotrod-connector> defined in domain.xml configuration, the cache container page does not show any containers. Tested many times.
> The server should be able to provide multiple HotRod endpoints bound to different cache containers.
> More specifically, this bug appears whenever I add "name" attribut to <hotrod-connector> tag. This attribute is required to differentiate hotrod connectors when there are more than one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-6563:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1332936
Bugzilla Update: Perform
> If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6563
> URL: https://issues.jboss.org/browse/ISPN-6563
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults.
> But it is expected that the hotrod-client.properties are used to configure the remote connection.
> The code is like this:
> {
> import javax.cache.*;
> ...
> CachingProvider jcacheProvider = Caching.getCachingProvider();
> CacheManager cacheManager = jcacheProvider.getCacheManager();
> }
> The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties.
> Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-6580:
-------------------------------------
The second regression is due to ISPN-5342, due to creating a new CacheDecodeContext. The problem is that each time this is created it creates a new log instance, which unfortunately creates a ClassNotFoundException every time. This can easily be fixed by making the logger static in Java. I am still investigating the first regression as it is more ingrained in the recent changes it seems.
> Hotrod performance regressions after ISPN-5342 ISPN-6545
> --------------------------------------------------------
>
> Key: ISPN-6580
> URL: https://issues.jboss.org/browse/ISPN-6580
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Reporter: Jakub Markos
> Assignee: William Burns
> Attachments: jfr_recordings.zip, pom.xml, Reproducer.java
>
>
> There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact...
> It is easily reproducable locally with a single server instance, reproducer attached.
> The numbers on my machine:
> ||Build commit||Puts time||Gets time||
> |dd5501c5e|21|74|
> |628819461|26|102|
> |db0890270|48|224|
> The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPRK-22) InfinispanRDD is not fault tolerant
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPRK-22?page=com.atlassian.jira.plugin.s... ]
Vojtech Juranek updated ISPRK-22:
---------------------------------
Description:
When primary ISPN server fails during processing InfinispanRDD, Spark is not able to overcome this failure.
This is caused by re-creating {{RemoteCachManager}} with pre-configured ISPN server address (for read [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...], for writes [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...]), so when this server fails during RDD processing and Spark calls some function, which under the hood creates {{RemoteCacheManager}}, it will fail with connection refused exception.
[Here|https://github.com/vjuranek/infinispan-spark/commit/c4a3101624e76d61...] are some basic tests and example of exception thrown by HR client:
{noformat}
org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:395)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:241)
at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:26)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:53)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:490)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:551)
at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:341)
at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:222)
at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:217)
at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
at scala.Option.map(Option.scala:146)
at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:52)
at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:66)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:89)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:11222
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:78)
at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:35)
at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:390)
... 21 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:68)
... 25 more
{noformat}
was:
When primary ISPN server fails during processing InfinispanRDD, Spark is not able to overcome this failure.
This is caused by re-creating {{RemoteCachManager}} with pre-configured ISPN server address (for read [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...], for writes [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...]), so when this server fails during RDD processing and Spark calls some function, which under the hood creates {{RemoteCacheManager}}, it will fail with connection refused exception.
[Here|https://github.com/vjuranek/infinispan-spark/commit/9aef6b7269feadb9...] are some basic tests (requires some more work, but should be fine for reproducing the issue) and example of exception thrown by HR client:
{noformat}
org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:395)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:241)
at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:26)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:53)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:490)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:551)
at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:341)
at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:222)
at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:217)
at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
at scala.Option.map(Option.scala:146)
at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:52)
at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:66)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:89)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:11222
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:78)
at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:35)
at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:390)
... 21 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:68)
... 25 more
{noformat}
Steps to Reproduce: Some basic tests: https://github.com/vjuranek/infinispan-spark/commit/c4a3101624e76d61097c4... (was: Some basic tests: https://github.com/vjuranek/infinispan-spark/commit/9aef6b7269feadb9c8543...
)
> InfinispanRDD is not fault tolerant
> -----------------------------------
>
> Key: ISPRK-22
> URL: https://issues.jboss.org/browse/ISPRK-22
> Project: Infinispan Spark
> Issue Type: Bug
> Components: RDD
> Affects Versions: 0.3
> Reporter: Vojtech Juranek
> Assignee: Gustavo Fernandes
>
> When primary ISPN server fails during processing InfinispanRDD, Spark is not able to overcome this failure.
> This is caused by re-creating {{RemoteCachManager}} with pre-configured ISPN server address (for read [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...], for writes [here|https://github.com/infinispan/infinispan-spark/blob/master/src/main/...]), so when this server fails during RDD processing and Spark calls some function, which under the hood creates {{RemoteCacheManager}}, it will fail with connection refused exception.
> [Here|https://github.com/vjuranek/infinispan-spark/commit/c4a3101624e76d61...] are some basic tests and example of exception thrown by HR client:
> {noformat}
> org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:395)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:241)
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:26)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:53)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:490)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:551)
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:341)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:222)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:217)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD$$anonfun$1.apply(InfinispanRDD.scala:52)
> at scala.Option.map(Option.scala:146)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:52)
> at org.infinispan.spark.rdd.InfinispanRDD.compute(InfinispanRDD.scala:66)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:11222
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:78)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:35)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:390)
> ... 21 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:68)
> ... 25 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6130) # Activations shows incorrect value
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6130?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-6130:
-----------------------------------
update: I've run a small test locally (2 nodes, dist, file-store, passivation, eviction=1) and it seems to work fine.
> # Activations shows incorrect value
> ------------------------------------
>
> Key: ISPN-6130
> URL: https://issues.jboss.org/browse/ISPN-6130
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.0.Beta1
> Reporter: Martin Vrabel
> Assignee: Pedro Ruivo
>
> Page: Caches -> select cache container -> select cache.
> Configuration of the cache: replicated cache, 2 nodes in the domain evictions size=10
> In the Entries lifecycle" tab, there is a field "# Activations" which should show number of Activations . When I put 10 entries in the cache and read 10, this field #Activations show 0 as is should. But when I insert another 10 entries (so the first 10 entries will evict and be stored in the cache store) and read the first 10 entries the #Activations field will show 0, but it should be 10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3702:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4308
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Alpha2
>
>
> When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following.
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000]
> ...
> Looking at the source code for
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> 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);
> This code can benefit from drawing the threads from a dedicated pool which is bounded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3702:
------------------------------
Fix Version/s: 9.0.0.Alpha2
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Alpha2
>
>
> When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following.
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000]
> ...
> Looking at the source code for
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> 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);
> This code can benefit from drawing the threads from a dedicated pool which is bounded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months