[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1583:
-----------------------------------
Fix Version/s: 5.2.0.CR1
5.2.0.Final
> 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
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> 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
[JBoss JIRA] (ISPN-2352) Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2352?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2352:
----------------------------------------
Marco, a pull req has been sent, did you give it a go to see if it solves your problem?
> Second invocation of ClusteredQueryImpl.lazyIterator() yields results in reverse order
> --------------------------------------------------------------------------------------
>
> Key: ISPN-2352
> URL: https://issues.jboss.org/browse/ISPN-2352
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.1.8.Final, 5.2.0.Alpha4
> Reporter: Marko Lukša
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 5.2.0.Beta6, 5.2.0.Final
>
>
> When you invoke lazyIterator() for the 2nd time on the same ClusteredQueryImpl instance, the iterator returns results in reverse order. This only occurs when the query has a Sort specified.
> Caused by DistributedIterator.setTopDocs(), which inverts the reverse flag on SortField.
> The same is probably also true for ClusteredQueryImpl.iterator()
--
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
[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-1990?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-1990:
---------------------------------------
up
> Preload sets the versions to null (repeatable read + write skew)
> ----------------------------------------------------------------
>
> Key: ISPN-1990
> URL: https://issues.jboss.org/browse/ISPN-1990
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.1.3.FINAL
> Environment: Java 6 (64bits)
> Infinispan 5.2.0-SNAPSHOT
> MacOS
> Reporter: Pedro Ruivo
> Assignee: Mircea Markus
> Labels: preload, skew, versioning, write
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache.
>
> I've made a test case to reproduce the bug. It can be found here [1].
> The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception:
>
> {code}
> java.lang.IllegalStateException: Entries cannot have null versions!
> at org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44)
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133)
> at org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64)
> {code}
>
> I think that all info is in the test case, but if you need something let
> me know.
>
> Cheers,
> Pedro
> [1]
> https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/...
--
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
[JBoss JIRA] (ISPN-2611) Drop rhq-pluginAnnotations and rhq-pluginGen dependencies
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2611?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-2611:
-------------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> Drop rhq-pluginAnnotations and rhq-pluginGen dependencies
> ---------------------------------------------------------
>
> Key: ISPN-2611
> URL: https://issues.jboss.org/browse/ISPN-2611
> Project: Infinispan
> Issue Type: Task
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.Beta5
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 5.2.0.CR1
>
>
> The rhq-pluginAnnotations and rhq-pluginGen dependencies should be dropped since we can generate the required RHQ plugin descriptor using our own ManagedOperation and ManagedAttribute annotations.
> This will also remove the requirement to carry rhq-pluginAnnotations around to workaround a Java compiler bug
--
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