[JBoss JIRA] Created: (ISPN-1146) Improve documentation around transaction and locking
by Mircea Markus (JIRA)
Improve documentation around transaction and locking
----------------------------------------------------
Key: ISPN-1146
URL: https://issues.jboss.org/browse/ISPN-1146
Project: Infinispan
Issue Type: Task
Components: Transactions
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.1.0.Final
As suggested by Jonathan Halliday:
- preserving some subset of the existing transactional guarantees is all well and good BUT if the user is relying on additional 'guarantees' that are not preserved in all cases then they'll be in trouble. Therefore, it's essential to document not just what the minimum expected guarantees for a given config are, but also that no additional properties that may coincidently be observed are actually guaranteed. Some vendors go further and explicitly document the bad things that may happen with given settings, since in some cases these are not easy to reproduce in testing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-825) Consider staggering remote get requests when using DIST
by Manik Surtani (JIRA)
Consider staggering remote get requests when using DIST
-------------------------------------------------------
Key: ISPN-825
URL: https://jira.jboss.org/browse/ISPN-825
Project: Infinispan
Issue Type: Feature Request
Components: RPC
Affects Versions: 4.1.0.Final
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.0.0.BETA1, 5.0.0.Final
In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic.
The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster.
A solution around this could be based on either (or both) of:
* Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc.
* Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5.
Needs careful thought and design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
by Mircea Markus (JIRA)
when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
----------------------------------------------------------------------------------------------------------------
Key: ISPN-317
URL: https://jira.jboss.org/jira/browse/ISPN-317
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.1.0.CR1
at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-1213) TreeCache expires parents that have children
by Todd Ciezadlo (JIRA)
TreeCache expires parents that have children
--------------------------------------------
Key: ISPN-1213
URL: https://issues.jboss.org/browse/ISPN-1213
Project: Infinispan
Issue Type: Bug
Components: Eviction
Affects Versions: 4.2.1.FINAL
Reporter: Todd Ciezadlo
Assignee: Manik Surtani
TreeCache parents expire according to the max-idle value even if they contain children. This puts the tree cache in an inconsistent state since the "dangling" children can be retrieved through TreeCache.get(FQN, String) calls, but cannot be traversed to through TreeCache.getRoot() and Node.getChildren() calls.
Copied a unit test to Steps to Reproduce.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by Paul Ferraro (JIRA)
Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
-------------------------------------------------------------------------
Key: ISPN-761
URL: https://jira.jboss.org/browse/ISPN-761
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.BETA1
Reporter: Paul Ferraro
Assignee: Manik Surtani
Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
I think CacheLoaderInterceptor needs to implement the following methods:
Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month