[JBoss JIRA] (ISPN-5416) Grouping and aggregations with DSL based queries
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-5416:
-----------------------------------
Summary: Grouping and aggregations with DSL based queries
Key: ISPN-5416
URL: https://issues.jboss.org/browse/ISPN-5416
Project: Infinispan
Issue Type: Feature Request
Components: Remote Querying
Affects Versions: 8.0.0.Final
Reporter: Adrian Nistor
Fix For: 8.0.0.Final
Implement the 'group by' statement and the aggregate functions: count, sum, average, min, max.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5415) Expose protobuf entries to scripting
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-5415:
-----------------------------------
Summary: Expose protobuf entries to scripting
Key: ISPN-5415
URL: https://issues.jboss.org/browse/ISPN-5415
Project: Infinispan
Issue Type: Feature Request
Components: Remote Querying
Affects Versions: 8.0.0.Final
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 8.0.0.Final
We need an alternative API for Protostream marshalling that is easy to consume from scripting languages. The messages need to be unmarshalled into a map-like object that can be accessed easily from scripting languages. No marshaller implementation code should be provided by users, also no annotations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5019:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1195565|https://bugzilla.redhat.com/show_bug.cgi?id=1195565] from ON_QA to VERIFIED
> After coordinator change, cache topologies should be installed in parallel
> --------------------------------------------------------------------------
>
> Key: ISPN-5019
> URL: https://issues.jboss.org/browse/ISPN-5019
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches.
> We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-3691) Make client side Connection refused error TRACE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3691?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3691:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1028411|https://bugzilla.redhat.com/show_bug.cgi?id=1028411] from ASSIGNED to MODIFIED
> Make client side Connection refused error TRACE
> -----------------------------------------------
>
> Key: ISPN-3691
> URL: https://issues.jboss.org/browse/ISPN-3691
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Affects Versions: 6.0.0.CR1, 6.0.0.Final
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 7.0.0.Final
>
>
> After solving ISPN-3454, it seems that only remaining client-side error during node crashes is "Connection refused":
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
> This has been reported before as ISPN-1794 or ISPN-1119, but actually it seems like it reappeared in different place.
> Sorry for not reporting sooner, I got used to ignoring some of the long-open cosmetic low-prio log message issues, that I forgot about this one...
> The issue here is that these "Connection refused" problems are retry-able, so the client log shouldn't contain error.
> Maybe only some info level message about failing over to different node. But that's actually already reported by the INFO level messages about the topology changes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5403) NullPointerException on starting CacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5403?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5403:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1196139|https://bugzilla.redhat.com/show_bug.cgi?id=1196139] from ASSIGNED to MODIFIED
> NullPointerException on starting CacheStore
> -------------------------------------------
>
> Key: ISPN-5403
> URL: https://issues.jboss.org/browse/ISPN-5403
> Project: Infinispan
> Issue Type: Bug
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Minor
>
> Relevant stacktrace:
> {code}
> boss.infinispan.clustered.default: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1936) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:171)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> at org.infinispan.CacheImpl.start(CacheImpl.java:779)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:587)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:542)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:104)
> at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:101)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:48)
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:109)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> ... 3 more
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_31]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_31]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_31]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_31]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 23 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.factory.CacheStoreFactoryRegistry.processStoreConfiguration(CacheStoreFactoryRegistry.java:48)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:529)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:114)
> ... 28 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5345) Allow eviction for based on approximation of size compared to element count
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5345?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-5345:
-----------------------------------
Assignee: William Burns
> Allow eviction for based on approximation of size compared to element count
> ---------------------------------------------------------------------------
>
> Key: ISPN-5345
> URL: https://issues.jboss.org/browse/ISPN-5345
> Project: Infinispan
> Issue Type: Enhancement
> Components: Eviction
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 8.0.0.Final
>
>
> It would be nice to have a bounded container that allows for eviction based on how much memory approximately the various arrays would take up.
> If possible we may even to enhance the data container to have a callback to provide a user specified way of calculating size for non byte[] values.
> This implementation would not know anything about duplicate references in the container and would count it double.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years