[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4027:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1152942|https://bugzilla.redhat.com/show_bug.cgi?id=1152942] from POST to MODIFIED
> TransactionTable.start() initialize the TxCleanupService 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: Takayoshi Kimura
> Labels: 630
> Fix For: 7.0.0.CR2
>
>
> 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 was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3830:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1155688|https://bugzilla.redhat.com/show_bug.cgi?id=1155688] from POST to MODIFIED
> Conditional Operation can fail erroneously during ST
> ----------------------------------------------------
>
> Key: ISPN-3830
> URL: https://issues.jboss.org/browse/ISPN-3830
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Reporter: William Burns
> Assignee: Dan Berindei
> Fix For: 7.0.0.CR2
>
>
> Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
> This however can have the following issue.
> k1 owned by N1, N2
> # N3 updates k1 sending conditional command to N1
> # N1 receives command and starts running it (passes topology block)
> # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
> # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
> # N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4693:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155692|https://bugzilla.redhat.com/show_bug.cgi?id=1155692] from NEW to POST
> Locks acquired before a partition will never be released
> --------------------------------------------------------
>
> Key: ISPN-4693
> URL: https://issues.jboss.org/browse/ISPN-4693
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Fix For: 7.0.0.CR2, 7.0.0.Final
>
>
> Consider the following case:
> 1. A prepares a transaction for key K on nodes B and C.
> 2. The primary owner B acquires and registers this lock.
> 3. The cluster partitions and A,C remain in partition one, and B in a separate partition.
> 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B.
> 5. B rejoins the cluster. It still has a lock acquired for key K.
> This can lead to a lock being acquired indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4027:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1152942|https://bugzilla.redhat.com/show_bug.cgi?id=1152942] from MODIFIED to POST
> TransactionTable.start() initialize the TxCleanupService 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: Takayoshi Kimura
> Labels: 630
> Fix For: 7.0.0.CR2
>
>
> 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 was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4027:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1152942|https://bugzilla.redhat.com/show_bug.cgi?id=1152942] from ASSIGNED to MODIFIED
> TransactionTable.start() initialize the TxCleanupService 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: Takayoshi Kimura
> Labels: 630
> Fix For: 7.0.0.CR2
>
>
> 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 was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4867) HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4867?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4867:
------------------------------------
Yep, I wanted to comment on ISPN-4866 :)
> HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
> -------------------------------------------------------------------
>
> Key: ISPN-4867
> URL: https://issues.jboss.org/browse/ISPN-4867
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 7.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> {noformat}
> org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: org/infinispan/server/test/client/hotrod/HotRodCustomMarshallerEventIT$Id
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:284)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:86)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:72)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testCustomEvents(AbstractRemoteCacheIT.java:855)
> {noformat}
> Tests {{testCustomEventsDynamic}}, {{testEventFilteringDynamic}}, {{testEventFilteringStatic}} fail with the same error message.
> Failing since http://ci.infinispan.org/viewLog.html?buildTypeId=bt8&buildId=12713
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4027:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1152942|https://bugzilla.redhat.com/show_bug.cgi?id=1152942] from NEW to ASSIGNED
> TransactionTable.start() initialize the TxCleanupService 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: Takayoshi Kimura
> Labels: 630
> Fix For: 7.0.0.CR2
>
>
> 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 was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4813) JMX returns wrong number of cache entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4813?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4813:
----------------------------------------
Vojtech, are you sure about clear? It appears to me that the issue are the result of how size is calculated for different use cases. According to CI, the failures were introduced by:
* HotRodRemoteCacheIT(distmode-udp).testPutAsync by ISPN-4736 and/or ISPN-4470 jiras.
* HotRodRemoteCacheIT(localmode-udp).testPutAsync and HotRodRemoteCacheIT(replmode-udp).testPutAsync by ISPN-4820
I'll update once I have more info.
> JMX returns wrong number of cache entries
> -----------------------------------------
>
> Key: ISPN-4813
> URL: https://issues.jboss.org/browse/ISPN-4813
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management, Remote Protocols, Server
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> Number of cache entries ({{numberOfEntries}}) provided by JMX is wrong. {{HotRodRemoteCacheIT#testPutAsyc}} fails with assert error (see bellow), because JMX returns wrong number of entries in the cache. When debugging the test, number of entries in the cache is correct (100 - obrained e.g. by {{cache.getBulk().size()}}), but JMX return wrong number (100). Even on cleared cache JMX return that it contains 3 entries. When the {{clear}} operation is called via JMX, JMX show correct number (0).
> {noformat}
> java.lang.AssertionError: expected:<100> but was:<103>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutAsync(AbstractRemoteCacheIT.java:574)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3830:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1155688|https://bugzilla.redhat.com/show_bug.cgi?id=1155688] from ASSIGNED to POST
> Conditional Operation can fail erroneously during ST
> ----------------------------------------------------
>
> Key: ISPN-3830
> URL: https://issues.jboss.org/browse/ISPN-3830
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Reporter: William Burns
> Assignee: Dan Berindei
> Fix For: 7.0.0.CR2
>
>
> Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
> This however can have the following issue.
> k1 owned by N1, N2
> # N3 updates k1 sending conditional command to N1
> # N1 receives command and starts running it (passes topology block)
> # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
> # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
> # N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months