[JBoss JIRA] (ISPN-1491) Provide methods to retrieve the CacheKey parameters
by Kevin Pollet (Created) (JIRA)
Provide methods to retrieve the CacheKey parameters
---------------------------------------------------
Key: ISPN-1491
URL: https://issues.jboss.org/browse/ISPN-1491
Project: Infinispan
Issue Type: Enhancement
Components: CDI integration
Reporter: Kevin Pollet
Assignee: Kevin Pollet
Fix For: 5.1.0.BETA4, 5.1.0.FINAL
Currently, it's not possible to retrieve the parameter values composing the {{CacheKey}} (generated by JCache interceptors). For that, we could introduce two interfaces.
* {{SimpleCacheKey<T>}} used when only one parameter is used as key. This interface could add the following method {{T getValue()}}
* {{ComposedCacheKey}} used when the key is composed by more than one parameter. This interface could add the following method {{Object[] getValues()}}
Here, we need to ensure that we are compliant with the specification.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-1403) Optimise sending Hot Rod topology updates for distributed caches
by Galder Zamarreño (JIRA)
Optimise sending Hot Rod topology updates for distributed caches
----------------------------------------------------------------
Key: ISPN-1403
URL: https://issues.jboss.org/browse/ISPN-1403
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server, Distributed Cache
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.FINAL
Right now, whenever a Hot Rod client sends a request with a view id which is different to the one on the server, it'd get a brand new view in the response to the request. This could be optimised nicely by only sending back a new view id when the server discovers that the client is using an inefficient view. For example, in distributed caches, the moment it gets a request for a key which lands on a node that does not own the key, it could decide to send back the view.
This would reduce the number of times the view is returned, hence improving the performance of requests.
--
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-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