[JBoss JIRA] (ISPN-4991) Implement clustered cache statistics
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4991?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4991:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1184647|https://bugzilla.redhat.com/show_bug.cgi?id=1184647] from NEW to ASSIGNED
> Implement clustered cache statistics
> ------------------------------------
>
> Key: ISPN-4991
> URL: https://issues.jboss.org/browse/ISPN-4991
> Project: Infinispan
> Issue Type: Sub-task
> Components: JMX, reporting and management
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> As of 7.0.0 release we implement cache statistics on a per node cache level. For Infinispan admin console we need to implement aggregate statistics for each cache across all nodes in the cluster. The implementing class should be a registered MBean and should implement similar cache statistics currently implemented by org.infinispan.interceptors.CacheMgmtInterceptor
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-5193) infinispan-embedded and infinispan-cli-interpreter don't work together
by Jakub Markos (JIRA)
Jakub Markos created ISPN-5193:
----------------------------------
Summary: infinispan-embedded and infinispan-cli-interpreter don't work together
Key: ISPN-5193
URL: https://issues.jboss.org/browse/ISPN-5193
Project: Infinispan
Issue Type: Bug
Components: CLI
Affects Versions: 7.1.0.CR2
Reporter: Jakub Markos
Creating a java application (no container) with both infinispan-embedded and infinispan-cli-interpreter dependencies results in this error when starting a cache manager:
{code}Exception in thread "main" java.util.ServiceConfigurationError: org.infinispan.lifecycle.ModuleLifecycle: Provider org.infinispan.cli.interpreter.LifecycleCallbacks could not be instantiated: java.lang.ExceptionInInitializerError
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at org.infinispan.commons.util.ServiceFinder.addServices(ServiceFinder.java:60)
at org.infinispan.commons.util.ServiceFinder.load(ServiceFinder.java:42)
at org.infinispan.util.ModuleProperties.resolveModuleLifecycles(ModuleProperties.java:41)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:94)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:292)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:271)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:244)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:231)
at Main64.main(Main64.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
... 15 more
Caused by: java.lang.IllegalArgumentException: Logger implementation class org.infinispan.cli.interpreter.logging.Log_$logger has no matching constructor
at infinispan.org.jboss.logging.Logger.getMessageLogger(Logger.java:2255)
at infinispan.org.jboss.logging.Logger.getMessageLogger(Logger.java:2211)
at org.infinispan.util.logging.LogFactory.getLog(LogFactory.java:21)
at org.infinispan.cli.interpreter.LifecycleCallbacks.<clinit>(LifecycleCallbacks.java:20)
... 21 more
{code}
Tried with 7.1.0.CR2, config:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:infinispan:config:7.1">
<cache-container default-cache="localcache">
<local-cache name="localcache"/>
</cache-container>
</infinispan>
{code}
application:
{code}
public static void main(String[] args) throws Exception {
EmbeddedCacheManager manager = new DefaultCacheManager("config.xml");
Cache defaultCache = manager.getCache("localcache");
for (int i = 0; i < 10; i++) {
defaultCache.put("key"+i, "value"+i);
}
Thread.sleep(5000000);
}
{code}
Using infinispan-core dependency instead of infinispan-embedded works.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-2342) Cross-Site Replication: State Transfer between sites
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2342:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1148378|https://bugzilla.redhat.com/show_bug.cgi?id=1148378] from VERIFIED to CLOSED
> Cross-Site Replication: State Transfer between sites
> ----------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 6.0.1.Final
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
> Labels: roadmap
> Fix For: 7.0.0.Final
>
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months