[JBoss JIRA] (ISPN-4813) JMX returns wrong number of cache entries
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-4813?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-4813:
---------------------------------------
IIRC I put [AbstractRemoteCacheIT#assertCacheEmpty|https://github.com/infinispan/infi...] at the beginning of AbstractRemoteCacheIT#[testPutAsync|https://github.com/infinispan/infinis... to make sure that cache is clear, but latter on, when I put a break point into [DefaultDataContainer#clear|https://github.com/infinispan/infinispan/blob/...] it wan't called. Not sure if this is the right data container, but IIRC via JMX this method was called.
> 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-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.... ]
Work on ISPN-4813 started by Galder Zamarreño.
----------------------------------------------
> 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-2145) No descriptions for invalid jgroups configuration files
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2145?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2145:
-------------------------------------
Assignee: Tristan Tarrant
> No descriptions for invalid jgroups configuration files
> -------------------------------------------------------
>
> Key: ISPN-2145
> URL: https://issues.jboss.org/browse/ISPN-2145
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.2.FINAL, 7.0.0.CR1
> Environment: Any
> Reporter: Dmitry Udalov
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Final
>
>
> Can't find error's description for invalid jgroups configuration files. Shuffling elements of the file (why not!) makes it invalid, but log-files only report the existence of the error and you have to debug it to figure out the problem. It would be easier if the class JGroupsTransport also reports the exception, not just a generic message in blocks like
> } catch (Exception e) {
> log.errorCreatingChannelFromConfigFile(cfg);
> throw new CacheException(e);
> }
> As a result log-file contains a lot of generic messages without explaining the problem, which in my case was quite helpful:
> java.lang.Exception: events [GET_DIGEST SET_DIGEST FIND_INITIAL_MBRS FIND_ALL_VIEWS ] are required by GMS, but not provided by any of the protocols below it
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4826) X-Site State transfer values not propagated correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4826?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4826:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1151523|https://bugzilla.redhat.com/show_bug.cgi?id=1151523] from MODIFIED to ON_QA
> X-Site State transfer values not propagated correctly
> ------------------------------------------------------
>
> Key: ISPN-4826
> URL: https://issues.jboss.org/browse/ISPN-4826
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 7.0.0.CR1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.CR2
>
>
> Used configuration:
> a) SITE1: 2 nodes, cache testCacheSite1
> <backups>
> <backup site="SITE2"/>
> </backups>
> b) SITE2: 3 nodes, cache testCacheSite1_backup – backup cache for testCacheSite1
> <backup-for remote-cache="testCacheSite1" remote-site="SITE1"/>
> When using backup cache with name (testCacheSite1_backup) different from the name of the main cache in SITE1 (testCacheSite1), the data is not propagated to the backup cache completely. The issue seems to be fixed by using the same name for the backup cache (testCacheSite1).
> Scenario
> 1. Start site1 and write data into it (1000 entries)
> 2. Start site2 and invoke XsiteAdminOperations.pushState(“SITE2”)
> 3. Wait 2 minutes
> 4. Check whether the state was transferred to site2 (tested on dist & repl backup cache configs)
> a) distributed mode (numOwners=2) - expected 2000 entries in total, was 648 on site2 master & 0 on other nodes
> b) replicated mode – expected 3000 entries in total, was 1000 on site2 master & 0 on other nodes
>
> Trace log:
> 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined
> 04:14:39,375 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-10,edg-perf13-23152) Attempting to execute command: SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}} [sender=edg-perf14-31850]
> 04:14:39,376 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-10,edg-perf13-23152) Checking if transaction data was received for topology 4, current topology is 4
> 04:14:39,376 TRACE [org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl] (OOB-10,edg-perf13-23152) Added a new task: 0 task(s) are waiting
> 04:14:39,376 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread--p3-t2) Calling perform() on SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}}
> 04:14:39,378 TRACE [org.infinispan.commands.remote.BaseRpcInvokingCommand] (remote-thread--p3-t2) Invoking command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}, with originLocal flag set to false
> 04:14:39,378 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p3-t2) Invoked with command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@266883cb]
> 04:14:39,379 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] (remote-thread--p3-t2) handleNonTxWriteCommand for command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}
> 04:14:39,380 TRACE [org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor] (remote-thread--p3-t2) Are (edg-perf13-23152) we the lock owners for key 'key_0000000000000001'? false
> 04:14:39,380 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) Wrapping entry 'key_0000000000000001'? true
> 04:14:39,380 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Exists in context? null
> 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Retrieved from container null (isL1Enabled=false, isLocal=true)
> 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Creating new entry.
> 04:14:39,388 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Wrap key_0000000000000001 for put. Entry=ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=null, oldValue=null, isCreated=true, isChanged=false, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}}
> 04:14:39,390 TRACE [org.infinispan.interceptors.CallInterceptor] (remote-thread--p3-t2) Executing command: PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}.
> 04:14:39,391 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) About to commit entry ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, oldValue=null, isCreated=true, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}}
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Trying to commit. Key=key_0000000000000001. Operation Flag=PUT_FOR_X_SITE_STATE_TRANSFER, L1 invalidation=false
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled!
> 04:14:39,392 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) The return value is null
> Suspicious lines:
> 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled!
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4826) X-Site State transfer values not propagated correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4826?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4826:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1151523|https://bugzilla.redhat.com/show_bug.cgi?id=1151523] from POST to MODIFIED
> X-Site State transfer values not propagated correctly
> ------------------------------------------------------
>
> Key: ISPN-4826
> URL: https://issues.jboss.org/browse/ISPN-4826
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 7.0.0.CR1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.CR2
>
>
> Used configuration:
> a) SITE1: 2 nodes, cache testCacheSite1
> <backups>
> <backup site="SITE2"/>
> </backups>
> b) SITE2: 3 nodes, cache testCacheSite1_backup – backup cache for testCacheSite1
> <backup-for remote-cache="testCacheSite1" remote-site="SITE1"/>
> When using backup cache with name (testCacheSite1_backup) different from the name of the main cache in SITE1 (testCacheSite1), the data is not propagated to the backup cache completely. The issue seems to be fixed by using the same name for the backup cache (testCacheSite1).
> Scenario
> 1. Start site1 and write data into it (1000 entries)
> 2. Start site2 and invoke XsiteAdminOperations.pushState(“SITE2”)
> 3. Wait 2 minutes
> 4. Check whether the state was transferred to site2 (tested on dist & repl backup cache configs)
> a) distributed mode (numOwners=2) - expected 2000 entries in total, was 648 on site2 master & 0 on other nodes
> b) replicated mode – expected 3000 entries in total, was 1000 on site2 master & 0 on other nodes
>
> Trace log:
> 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined
> 04:14:39,375 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-10,edg-perf13-23152) Attempting to execute command: SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}} [sender=edg-perf14-31850]
> 04:14:39,376 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (OOB-10,edg-perf13-23152) Checking if transaction data was received for topology 4, current topology is 4
> 04:14:39,376 TRACE [org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl] (OOB-10,edg-perf13-23152) Added a new task: 0 task(s) are waiting
> 04:14:39,376 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread--p3-t2) Calling perform() on SingleRpcCommand{cacheName='testCacheSite1_backup', command=PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}}
> 04:14:39,378 TRACE [org.infinispan.commands.remote.BaseRpcInvokingCommand] (remote-thread--p3-t2) Invoking command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}, with originLocal flag set to false
> 04:14:39,378 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p3-t2) Invoked with command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@266883cb]
> 04:14:39,379 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] (remote-thread--p3-t2) handleNonTxWriteCommand for command PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}
> 04:14:39,380 TRACE [org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor] (remote-thread--p3-t2) Are (edg-perf13-23152) we the lock owners for key 'key_0000000000000001'? false
> 04:14:39,380 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) Wrapping entry 'key_0000000000000001'? true
> 04:14:39,380 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Exists in context? null
> 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Retrieved from container null (isL1Enabled=false, isLocal=true)
> 04:14:39,382 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Creating new entry.
> 04:14:39,388 TRACE [org.infinispan.container.EntryFactoryImpl] (remote-thread--p3-t2) Wrap key_0000000000000001 for put. Entry=ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=null, oldValue=null, isCreated=true, isChanged=false, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}}
> 04:14:39,390 TRACE [org.infinispan.interceptors.CallInterceptor] (remote-thread--p3-t2) Executing command: PutKeyValueCommand{key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, flags=[SKIP_REMOTE_LOOKUP, PUT_FOR_X_SITE_STATE_TRANSFER, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}.
> 04:14:39,391 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) About to commit entry ReadCommittedEntry(197b92bc){key=key_0000000000000001, value=value_key_0000000000000001_SITE1_ORIGINAL@testCacheSite1, oldValue=null, isCreated=true, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=false, metadata=EmbeddedMetadata{version=null}}
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Trying to commit. Key=key_0000000000000001. Operation Flag=PUT_FOR_X_SITE_STATE_TRANSFER, L1 invalidation=false
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled!
> 04:14:39,392 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread--p3-t2) The return value is null
> Suspicious lines:
> 04:14:39,116 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (OOB-10,edg-perf13-23152) Silently ignoring that testCacheSite1 cache is not defined
> 04:14:39,392 TRACE [org.infinispan.statetransfer.CommitManager] (remote-thread--p3-t2) Not committing key=key_0000000000000001. It is a state transfer key but no track is enabled!
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4873) Statetransfer thread pool deadlock
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4873?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-4873:
----------------------------------
Assignee: Dan Berindei
> Statetransfer thread pool deadlock
> ----------------------------------
>
> Key: ISPN-4873
> URL: https://issues.jboss.org/browse/ISPN-4873
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Takayoshi Kimura
> Assignee: Dan Berindei
>
> During massive state transfer with 300 nodes and 3000 caches, the OOB and/or infinispan thread pool gets deadlock, similar to ISPN-2808.
> The thread pool is configured with max 1400 threads now and increasing them is not a realistic workaround as the user is planning to add more caches.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4775) UberJar fixes
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4775?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4775:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.CR2
Resolution: Done
> UberJar fixes
> -------------
>
> Key: ISPN-4775
> URL: https://issues.jboss.org/browse/ISPN-4775
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Affects Versions: 7.0.0.Beta2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Final, 7.0.0.CR2
>
>
> - Make uberjars depend on a common parent
> - Generate source uberjars
> - Include the LevelDB cachestore in the embedded jar
> - Ensure that uberjars expose the correct remaining transitive deps
> - Combine any existing service files
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months