[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3617:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2163
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3443:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1001634|https://bugzilla.redhat.com/show_bug.cgi?id=1001634] from ASSIGNED to VERIFIED
> WriteCommand may be ignored during state transfer
> -------------------------------------------------
>
> Key: ISPN-3443
> URL: https://issues.jboss.org/browse/ISPN-3443
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: jdg62blocker
> Fix For: 6.0.0.CR1
>
>
> Distributed sync non-tx cache.
> Situation:
> 1) A node is joining the cluster, requesting some segment
> 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true
> 3) It looks up the entry and finds null
> 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet)
> 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context)
> Result: the value is removed on primary but on backup this is still present
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3604) Provide JMX operation which shows the numberOfEntries in the entire dist-cache
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/ISPN-3604?page=com.atlassian.jira.plugin.... ]
Duncan Doyle commented on ISPN-3604:
------------------------------------
Idea is to refactor 'org.infinispan.tasks.GlobalKeySetTask'. That implementation currently does not take entries in the CacheLoader into account. So I want to change that implementation to use the implementation of 'org.infinispan.server.hotrod.util.BulkUtil' and make the HotRod server use the GlobalKeySetTask.
I want to implement the JMX operation on the 'org.infinispan.CacheImpl', as the 'org.infinispan.interceptors.CacheMgmtInterceptor' is not really the correct place for it (first of all, it is not data that is collected via an interceptor (i.e., we use a Map/Reduce function), second the data is not really statistics data (i.e. it's the current global number of keys in the grid), third I don't actually have access to the Cache object in the interceptor code ....).
Any comments?
> Provide JMX operation which shows the numberOfEntries in the entire dist-cache
> ------------------------------------------------------------------------------
>
> Key: ISPN-3604
> URL: https://issues.jboss.org/browse/ISPN-3604
> Project: Infinispan
> Issue Type: Feature Request
> Components: JMX, reporting and management
> Affects Versions: 6.0.0.CR1
> Environment: Max OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Infinispan 5.2.4.Final
> Reporter: Duncan Doyle
> Assignee: Mircea Markus
>
> The Infinispan statistics component only shows the 'numberOfEntries' in a particular node, including entries of which the node is not the primary owner (basically, doing a sum of this value of all the cluster members gives you (numberOfEntries * numOwners). The 'cache.keySet()' method does return the entire keyset, and thus you can calculate the numberOfEntries in the cache, but this requires writing custom code in a cache client. It would be nice if Infinispan would provide a JMX operation which is able to show the number of entries in the entire dist-cache cluster.
--
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
11 years, 3 months
[JBoss JIRA] (ISPN-3621) Most CacheStore configuration examples in the documentation are wrong (outdated)
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-3621:
-------------------------------------
Summary: Most CacheStore configuration examples in the documentation are wrong (outdated)
Key: ISPN-3621
URL: https://issues.jboss.org/browse/ISPN-3621
Project: Infinispan
Issue Type: Bug
Components: Documentation
Reporter: Sanne Grinovero
Assignee: Mircea Markus
Fix For: 6.0.0.CR2, 6.0.0.Final
I've been trying half a dozen configuration snippets from the documentation, I couldn't get any CacheStore to work. All I get from the configuration parser is an unhelpfull stack trace:
{quote}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[50,63]
Message: Unexpected element '{urn:infinispan:config:6.0}loaders' encountered
at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:35)
at org.infinispan.configuration.parsing.Parser60.parseCache(Parser60.java:178)
at org.infinispan.configuration.parsing.Parser60.parseNamedCache(Parser60.java:109)
at org.infinispan.configuration.parsing.Parser60.readElement(Parser60.java:76)
at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:130)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:112)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:99)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:86)
... 47 more
{quote}
One might think that something (what?) is wrong at [row,col]:[50,63] but I'm copy pasting the documentation.
--
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
11 years, 3 months