July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5641) Reduce contention in JGroupsAddressCache

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5641: ---------------------------------- Summary: Reduce contention in JGroupsAddressCache Key: ISPN-5641 URL: https://issues.jboss.org/browse/ISPN-5641 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta3 Avoid computeIfAbsent for existent entries, because it synchronizes on the entry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5639) Avoid creating a Callable instance for RPC timeout handling

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5639: ---------------------------------- Summary: Avoid creating a Callable instance for RPC timeout handling Key: ISPN-5639 URL: https://issues.jboss.org/browse/ISPN-5639 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5640) Avoid a map lookup in SyncConfiguration.replTimeout()

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5640: ---------------------------------- Summary: Avoid a map lookup in SyncConfiguration.replTimeout() Key: ISPN-5640 URL: https://issues.jboss.org/browse/ISPN-5640 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 8.0.0.Beta3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5638) Remove the isOriginLocal from AbstractInvocationContext

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5638: ---------------------------------- Summary: Remove the isOriginLocal from AbstractInvocationContext Key: ISPN-5638 URL: https://issues.jboss.org/browse/ISPN-5638 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta3 We already have an origin field, we can use {{origin == null}} to check if the invocation is local. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5637) Use SingleKeyNonTxInvocationContext for remote non-tx writes

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5637?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5637: ------------------------------- Status: Open (was: New) > Use SingleKeyNonTxInvocationContext for remote non-tx writes > ------------------------------------------------------------ > > Key: ISPN-5637 > URL: https://issues.jboss.org/browse/ISPN-5637 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta3 > > > Remove commands always use a {{NonTxInvocationContext}}, even if they affect a single key. We should be able to use {{SingleKeyNonTxInvocationContext}} instead and avoid allocating a HashMap for the context entries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5637) Use SingleKeyNonTxInvocationContext for remote non-tx writes

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5637: ---------------------------------- Summary: Use SingleKeyNonTxInvocationContext for remote non-tx writes Key: ISPN-5637 URL: https://issues.jboss.org/browse/ISPN-5637 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta3 Remove commands always use a {{NonTxInvocationContext}}, even if they affect a single key. We should be able to use {{SingleKeyNonTxInvocationContext}} instead and avoid allocating a HashMap for the context entries. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5193) infinispan-embedded and infinispan-cli-interpreter don't work together

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-5193?page=com.atlassian.jira.plugin.... ] Jakub Markos updated ISPN-5193: ------------------------------- Affects Version/s: 8.0.0.Beta2 > 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, 8.0.0.Beta2 > 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.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5193) infinispan-embedded and infinispan-cli-interpreter don't work together

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-5193?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-5193: ------------------------------------ This is actually a problem when using any separate module, which is not a part of the uberjar (like infinispan-server-hotrod or infinispan-cli-interpreter), with uberjar. It happens because jboss logging is relocated to package infinispan.org.jboss.logging in uberjar, but other modules still use org.jboss.logging. When jboss logging then tries to instantiate the modules log, it looks for a constructor with a single parameter infinispan.org.jboss.logging.Logger, but cannot find it, because the modules log constructor signature has org.jboss.logging.Logger. > 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.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4810: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1202354|https://bugzilla.redhat.com/show_bug.cgi?id=1202354] from MODIFIED to ASSIGNED > Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-4810 > URL: https://issues.jboss.org/browse/ISPN-4810 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: Windows 7 x64 (NTFS) > Oracle JDK1.7.0_40 > Apache Maven 3.0.5 > Reporter: Horia Chiorean > Assignee: William Burns > Labels: modeshape > Fix For: 7.2.0.Beta1, 5.2.12.Final, 5.2.13.Final > > Attachments: ispn_concurrent.zip > > > Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario: > * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction > * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread > ** checks that the string entries were added into the cache and > ** checks that the entries were correctly appended to the List entry > * the above steps are repeated a number of times > On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario). > If we either: > * disable eviction or > * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3797) DataContainer should interact atomically with Persistence

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3797?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3797: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1202354|https://bugzilla.redhat.com/show_bug.cgi?id=1202354] from MODIFIED to ASSIGNED > DataContainer should interact atomically with Persistence > --------------------------------------------------------- > > Key: ISPN-3797 > URL: https://issues.jboss.org/browse/ISPN-3797 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction, Loaders and Stores > Affects Versions: 6.0.0.Final, 5.2.10.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha3, 7.0.0.Final, 5.2.11.Final > > > DataContainer should handle atomically all the interactions with the Persistence. This includes all the eviction/passivation. > Main points: > * In DataContainer load/store will avoid any lose of data during concurrent operations > * Take advantage of CHMv8 > * CacheLoader and Writer Interceptors are no longer needed. > Check the mailling list for more info. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015