December 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2628) ActivationManagerImpl has a useless method which breaks the build

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2628?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2628: ----------------------------------- Fix Version/s: 5.2.0.Beta6 > ActivationManagerImpl has a useless method which breaks the build > ----------------------------------------------------------------- > > Key: ISPN-2628 > URL: https://issues.jboss.org/browse/ISPN-2628 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 5.2.0.Beta6 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ] Paul Ferraro reopened ISPN-1583: -------------------------------- Why did you close this as opposed to just lowering the priority? Do you disagree that this is a significant usability bug? How do you expect users to know that they need to override these two methods in order have a usable cache delegate? In AS7, cache instances created by the infinispan subsystem are custom implementations of this delegate class. See: https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src... The DelegatingCache inner class extends: https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src... ...which contains the workaround for this issue. Until I implemented this workaround, no invocation flags were applied to cache operations. Kind of a big deal, I think. As I see it, this issue can be fixed in 1 of 2 ways: * via an abstract method to AbstractDelegatingAdvancedCache (see above) that needs to be extended by the implementing class that re-wraps the cache instance * via adding a factory parameter to the AbstractDelegatingAdvancedCache constructor that performs the cache wrapping e.g. {code} public interface AdvancedCacheWrapper { <K, V> AdvancedCache<K, V> wrap(AdvancedCache<K, V> cache); } public class AbstractDelegatingAdvancedCache<K, V> extends AbstractDelegatingCache<K, V> implements AdvancedCache<K, V> { private final AdvancedCache<K, V> cache; private final AdvancedCacheWrapper wrapper; protected AbstractDelegatingAdvancedCache(AdvancedCache<K, V> cache, AdvancedCacheWrapper wrapper) { super(cache); this.cache = cache; this.wrapper = wrapper; } public AdvancedCache<K, V> with(ClassLoader loader) { return this.wrapper.wrap(this.cache.with(loader)); } public AdvancedCache<K, V> withFlags(Flag... flags) { return this.wrapper.wrap(this.cache.withFlags(flags)); } // ... } {code} The latter is probably the more elegant solution. > AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken > ------------------------------------------------------------------------------------- > > Key: ISPN-1583 > URL: https://issues.jboss.org/browse/ISPN-1583 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.1.0.BETA5 > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > > When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke. > Take the following code: > AdvancedCache<K, V> baseCache; > AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) { > public void clear() { > // custom clear logic > } > }; > customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear(); > In the above statement, the flag is not applied. > The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection. > In the case of with(ClassLoader) we have the opposite problem. > customCache.with(customClassLoader).clear(); > In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of customCache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2628) ActivationManagerImpl has a useless method which breaks the build

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2628?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-2628: --------------------------------------- It appears the ActivationManagerImpl class has a copy/pasted method from CacheLoaderInterceptor with a too long displayName [ERROR] javadoc: error - In doclet class org.infinispan.tools.rhq.RhqPluginXmlGenerator, method start has thrown an exception java.lang.reflect.InvocationTargetException [ERROR] java.lang.RuntimeException: Display name too long (max 100 chars): [Activation] Disable all cache loaders of a given type, where type is a fully qualified class name of the cache loader to disable [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.validateDisplayName(RhqPluginXmlGenerator.java:324) > ActivationManagerImpl has a useless method which breaks the build > ----------------------------------------------------------------- > > Key: ISPN-2628 > URL: https://issues.jboss.org/browse/ISPN-2628 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2628) ActivationManagerImpl has a useless method which breaks the build

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2628?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2628: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1524 > ActivationManagerImpl has a useless method which breaks the build > ----------------------------------------------------------------- > > Key: ISPN-2628 > URL: https://issues.jboss.org/browse/ISPN-2628 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2607) Typo in remote protocol MBeans

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2607?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2607: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Typo in remote protocol MBeans > ------------------------------ > > Key: ISPN-2607 > URL: https://issues.jboss.org/browse/ISPN-2607 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.0.Beta5 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 5.2.0.Beta6 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2628) ActivationManagerImpl has a useless method which breaks the build

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2628: ------------------------------------- Summary: ActivationManagerImpl has a useless method which breaks the build Key: ISPN-2628 URL: https://issues.jboss.org/browse/ISPN-2628 Project: Infinispan Issue Type: Bug Components: Eviction Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2627) Fail to build minimal-distribution at RhqPluginXmlGenerator

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2627: ---------------------------------- Summary: Fail to build minimal-distribution at RhqPluginXmlGenerator Key: ISPN-2627 URL: https://issues.jboss.org/browse/ISPN-2627 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 5.2.0.Beta5 Reporter: Thomas Fromm Assignee: Mircea Markus mvn clean package -Dmaven.test.skip.exec=true -Pminimal-distribution I'm struggeling building minimal distribution always here: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (default) on project infinispan-rhq-plugin: An error has occurred in JavaDocs report generation: [ERROR] Exit code: 1 - log4j:WARN No appenders could be found for logger (org.jboss.logging). [ERROR] log4j:WARN Please initialize the log4j system properly. [ERROR] log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. [ERROR] javadoc: error - In doclet class org.infinispan.tools.rhq.RhqPluginXmlGenerator, method start has thrown an exception java.lang.reflect.InvocationTargetException [ERROR] java.lang.RuntimeException: Display name too long (max 100 chars): [Activation] Disable all cache loaders of a given type, where type is a fully qualified class name of the cache loader to disable [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.validateDisplayName(RhqPluginXmlGenerator.java:324) [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.populateMetricsAndOperations(RhqPluginXmlGenerator.java:244) [ERROR] at org.infinispan.tools.rhq.RhqPluginXmlGenerator.start(RhqPluginXmlGenerator.java:144) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [ERROR] at java.lang.reflect.Method.invoke(Method.java:601) [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:280) [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:160) [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:397) [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:167) [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:59) [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:49) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2384) Entry lost after Eviction/Passivation

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-2384?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2384: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Entry lost after Eviction/Passivation > ------------------------------------- > > Key: ISPN-2384 > URL: https://issues.jboss.org/browse/ISPN-2384 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.0.Beta1 > Reporter: Thomas Fromm > Assignee: Galder Zamarreño > Labels: jdg, jdg6 > Fix For: 5.2.0.Beta6, 5.2.0.Final > > Attachments: eviction.log > > > Cache is LOCAL, eviction + passivation enabled. After put the entry gets passivated, shortly after an other thread tries to get() the entry, but get null. > Attached a log file. The key is "50b2c9e7-0a38-0043-01fc-76cdf49fa2ce". Tried JDBC and File store with same results, also sync/async store tested. It happens under some load. > I wasn't successful to create unit test for reproduction :-/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2626) XSite test suite doesn't work

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2626: ----------------------------------- Summary: XSite test suite doesn't work Key: ISPN-2626 URL: https://issues.jboss.org/browse/ISPN-2626 Project: Infinispan Issue Type: Feature Request Components: Cross-Site Replication Affects Versions: 5.2.0.Beta5 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.Beta6 The problem was introduced with the RELAY.async_relay_creation (enabled by default) and which doesn't guarantee that after the bridge is created discovery has run. Disabling it solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2552) Support concurrent updates for non-transactional caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2552?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2552: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1520 > Support concurrent updates for non-transactional caches > -------------------------------------------------------- > > Key: ISPN-2552 > URL: https://issues.jboss.org/browse/ISPN-2552 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.1.0.FINAL > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Blocker > Fix For: 5.2.0.Beta6, 5.2.0.Final > > > for non-transactional caches, when a key is updated, a local lock is acquired and also a lock on all the owning nodes as well. This is very inefficient for concurrent updates as it is very deadlock-prone. > The following locking approach should solve this problem at the cost of an additional RPC: > - 'k' is written on node A, owners(k)={B,C} > - A forwards the given command to B > - B acquires a lock on 'k' then it forwards it to the remaining owners: C > - C applies the change and returns to B (no lock acquisition is needed) > - B applies the result as well, releases the lock and returns the result of the operation to A. > Note that even though this introduces an additional RPC (the forwarding), it behaves very well in conjunction with consistent-hash aware hotrod clients which connect directly to the lock owner. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012