[JBoss JIRA] (ISPN-2399) CacheManager.startCaches very slow when multiple caches are passed in
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2399?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2399.
--------------------------------
Fix Version/s: 7.0.0.Final
Resolution: Out of Date
Fixed before 7.0.0.Final.
> CacheManager.startCaches very slow when multiple caches are passed in
> ---------------------------------------------------------------------
>
> Key: ISPN-2399
> URL: https://issues.jboss.org/browse/ISPN-2399
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.2.0.Beta1
> Reporter: Mircea Markus
> Priority: Minor
> Fix For: 7.0.0.Final
>
>
> the TransactionsSpanningReplicatedCachesTest uses the following code to start multiple caches:
> {code:java}
> cm1.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME);
> cm2.startCaches("c1", "c2", "cache1", "cache2", CacheContainer.DEFAULT_CACHE_NAME);
> waitForClusterToForm("c1", "c2", "cache1", "cache2");
> {code}
> On my machine(MBP) this executes in 12 mins.The functionally equivalent below executes in 15 secs:
> {code:java}
> private void startAllCaches() {
> startCache("c1");
> startCache("c2");
> startCache("cache1");
> startCache("cache2");
> startCache(CacheContainer.DEFAULT_CACHE_NAME);
> }
> private void startCache(String c1) {
> cm1.getCache(c1);
> cm2.getCache(c1);
> waitForClusterToForm(c1);
> }
> {code}
> We need to analyse why this takes so long and also updated the test to use the CacheManagers.startCaches..
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-6802) Micro-optimizations for read operations
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6802?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6802:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4732, https://github.com/infinispan/infinispan/pull/4746 (was: https://github.com/infinispan/infinispan/pull/4732)
> Micro-optimizations for read operations
> ---------------------------------------
>
> Key: ISPN-6802
> URL: https://issues.jboss.org/browse/ISPN-6802
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta2
>
>
> * L1 entries are written to the data container by L1TxInterceptor/L1NonTxInterceptor directly, so there is no reason to commit the context entries in EntryWrappingInterceptor or to clear the locks in the locking interceptors.
> * ClearCommands can no longer be wrapped in PrepareCommands, so we can stop the state transfer in {{EntryWrappingInterceptor.visitClearCommand()}} instead of checking the type for each command.
> * In transactional caches, a read operation without an explicit transaction triggers two queries for the current transaction to the transaction manager, which usually means 2 thread-local lookups.
> * IsMarshallerInterceptor shouldn't do anything unless there is an asynchronous store
> * Transactional remote get commands use NonTxInvocationInterceptor instead of SingleKeyNonTxInterceptor.
> * Configuration attributes should be cached, as reading them requires accessing multiple instances + a cast in Attribute.get()
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-4098) DataContainer Equivalence is not used properly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4098?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-4098.
--------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Out of Date
The DataContainer equivalence configuration is no longer used since the ISPN-6998 fix.
> DataContainer Equivalence is not used properly
> ----------------------------------------------
>
> Key: ISPN-4098
> URL: https://issues.jboss.org/browse/ISPN-4098
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.Alpha1
> Reporter: William Burns
> Fix For: 9.0.0.Beta1
>
>
> The DefaultDataContainer uses an EquivalentHashMap under the scenes. The values() method doesn't return a collection that obeys the value Equivalence however. Also to note the provided value equivalence would have to be wrapped with an Equivalence for ICE to be used properly as shown with the new typing changes in ISPN-4079.
> Also to note any users of DataContainer values, keySet methods would have to also use the proper equivalence. An example is the KeySetCommand, ValuesCommand and EntrySetCommand should obey these Equivalences.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7124) Create JDBC Binary/Mixed Store Migrator
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7124?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7124:
-------------------------------
Summary: Create JDBC Binary/Mixed Store Migrator (was: Port JDBC Migrator)
> Create JDBC Binary/Mixed Store Migrator
> ---------------------------------------
>
> Key: ISPN-7124
> URL: https://issues.jboss.org/browse/ISPN-7124
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha4
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store. This could be an opportunity to create a generic store migrator, with a JDBC specific implementation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months