[JBoss JIRA] (ISPN-3983) Remove some performance bottlenecks from ProtoStream
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3983?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3983:
-------------------------------------
Many perf issue are due to extensive use of HashMap-like data structures in the implementation. Improvements were done by replacing those with some simpler data structures where it was possible. There is still one such data structure that cannot be removed. It is used for buffering all fields that are 'seen' in the data stream until they are actually read by the user code (implemetations of MessageMarshaller). The problem is simillar to DOM vs SAX when it comes to xml parsing. The current implementation uses internal data structures to represent and buffer the incomming stream of fields, much like DOM. A better alternative would be to immediatelly inject the incoming fields directly into the user entity (think SAX).
The new annotation based marshallers do exactly that and no longer have this perf problem.
I think performance is decent now for MessageMarshaller implementations and maximal for the annotation based barshallers, so we can close this.
> Remove some performance bottlenecks from ProtoStream
> ----------------------------------------------------
>
> Key: ISPN-3983
> URL: https://issues.jboss.org/browse/ISPN-3983
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 6.3remotequeries, 630, 64QueryBlockers
> Fix For: 7.1.0.CR1
>
>
> Profiling has shown that there are many HashMaps created in MessageContext to help field lookup by name.
> Normally this is a static piece of information that should be computed only once when a marshaller is registered and then it should become immutable and be reused.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4175) Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4175?page=com.atlassian.jira.plugin.... ]
Adrian Nistor resolved ISPN-4175.
---------------------------------
Fix Version/s: 7.0.0.Final
Resolution: Out of Date
> Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-4175
> URL: https://issues.jboss.org/browse/ISPN-4175
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 64QueryBlockers
> Fix For: 7.0.0.Final
>
>
> {code}
> 11:47:01,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.infinispan.clustered.memcachedCache: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.memcachedCache: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:546)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:517)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:399)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:413)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> ... 3 more
> Caused by: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true
> at org.infinispan.factories.AbstractComponentRegistry.throwStackAwareConfigurationException(AbstractComponentRegistry.java:884)
> at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:299)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:270)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148)
> at org.infinispan.query.remote.LifecycleManager.initProtobufMetadataManager(LifecycleManager.java:56)
> at org.infinispan.query.remote.LifecycleManager.cacheManagerStarted(LifecycleManager.java:70)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3695) Atomic Object Factory
by Pierre Sutra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3695?page=com.atlassian.jira.plugin.... ]
Pierre Sutra updated ISPN-3695:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/2188)
> Atomic Object Factory
> ---------------------
>
> Key: ISPN-3695
> URL: https://issues.jboss.org/browse/ISPN-3695
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Pierre Sutra
> Priority: Optional
> Labels: atomic
> Original Estimate: 1 week, 2 days
> Remaining Estimate: 1 week, 2 days
>
> This feature implements a factory of atomic objects. The factory is universal in the sense that it can instanciate an object of any class. Below, we illusrate the usage of such a factory.
> AtomicObjectFactory factory = new AtomicObjectFactory(c1); // c1 is both synchronous and transactional
> Set set = (Set) factory.getOrCreateInstanceOf(HashSet.class, "k"); // k is the key to store set inside c1
> set.add("smthing"); // some call examples
> System.out.println(set.toString())
> set.addAll(set);
> factory.disposeInstanceOf(HashSet.class, "set", true); // to store in a persistent way the object
> The implementation requires that all the arguments of the methods of the object are Serializable, as well as the object itself. The factory is built on top of the transactional facility of Infinispan. When an object is created, it stores both a local copy and a proxy registered as a cache listener. Then, it serializes every call in a transaction consisting of a single put operation. When the call is de-serialized its applied to the local copy and, in case the calling process was local, the return value is returned (this mechanism is implemented via a future object).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4175) Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4175?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-4175:
-------------------------------------
In 7.0 ProtobufMetadataManager component no longer depends on ClusterRegistry component hence the issue has become obsolete.
> Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-4175
> URL: https://issues.jboss.org/browse/ISPN-4175
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 64QueryBlockers
>
> {code}
> 11:47:01,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.infinispan.clustered.memcachedCache: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.memcachedCache: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:546)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:517)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:399)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:413)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> ... 3 more
> Caused by: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true
> at org.infinispan.factories.AbstractComponentRegistry.throwStackAwareConfigurationException(AbstractComponentRegistry.java:884)
> at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:299)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:270)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148)
> at org.infinispan.query.remote.LifecycleManager.initProtobufMetadataManager(LifecycleManager.java:56)
> at org.infinispan.query.remote.LifecycleManager.cacheManagerStarted(LifecycleManager.java:70)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-1543) Split CacheImpl into TransactionalCache and NonTransactionalCache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1543?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-1543:
-------------------------------------
Assignee: (was: Mircea Markus)
> Split CacheImpl into TransactionalCache and NonTransactionalCache
> ------------------------------------------------------------------
>
> Key: ISPN-1543
> URL: https://issues.jboss.org/browse/ISPN-1543
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.1.0.BETA4
> Reporter: Mircea Markus
> Priority: Minor
> Labels: refactor
>
> There is a lot of unnecessary complexity in CacheImpl caused by handling two types of caches: transactional and non-transactional.
> This code (and potentially InvocationContextContainer) can be simplified a lot by splitting the logic into two cache implementations: TransactionalCache and NonTransactionalCache. The common logic would be moved in an AbstractCache.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3788) Cross site replication TCP connection does not get re-established, and no error reported
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3788?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3788:
-------------------------------------
Assignee: (was: Mircea Markus)
> Cross site replication TCP connection does not get re-established, and no error reported
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3788
> URL: https://issues.jboss.org/browse/ISPN-3788
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 5.2.5.Final
> Environment: ISPN 5.2.5 final with 2 site in xsite replication (sync) configuration
> Reporter: dex chen
>
> The xsite replication TCP connection does not get reestablished after the cache started.
> To reproduce the issue:
> 0) block the tcp port between the 2 sites (such as 7800) which is configured for xsite replication
> 1) start both clusters
> 2) the 2 clusters are all up (no errors), but the xsite tcp connection is not established (e.g., by checking the netstat output)
> 4) now unblock the tcp port
> 5) check the xsite connection. It is not established. Hence, the xsite replication will still not work.
> The expected behaviour would be, at minimal, it should show the xsite replication in error state. The better one is to ispn will try to re-establish the connection.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-2244) Transparently hold serialized representations of keys and values
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2244?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2244:
-------------------------------------
Assignee: (was: Mircea Markus)
> Transparently hold serialized representations of keys and values
> ----------------------------------------------------------------
>
> Key: ISPN-2244
> URL: https://issues.jboss.org/browse/ISPN-2244
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Robert Stupp
>
> Serialization/deserialization might become very expensive when working with cached large java objects that are created and used on many different nodes.
> At the moment, the setting storeAsBinary() allows you to "die" either one:
> * serialize/deserialize when the cache is accessed
> * serialize/deserialize when L1 is filled or invalidated, object fetched from other node, object is replicated on put
> It might be a good solution to add a third mode:
> * At a put() operation, the Java object is put into the cache
> * When the serialized representation is required first, it is created from the Java object (or during the put() operation)
> * The serialized representation is reused every time when needed.
> Means: cache the serialized representation of keys and values.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months