[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, 2 months
[JBoss JIRA] (ISPN-1893) Query module demo
by Mathieu Lachance (JIRA)
Mathieu Lachance created ISPN-1893:
--------------------------------------
Summary: Query module demo
Key: ISPN-1893
URL: https://issues.jboss.org/browse/ISPN-1893
Project: Infinispan
Issue Type: Task
Components: Core API, Locking and Concurrency, Migration tools
Reporter: Mathieu Lachance
Assignee: Manik Surtani
Would it be possible to make a query-module demo showing the best practice with :
- replication clustering mode + local query,
- distribution clustering mode + index replication + local query,
- distribution clustering mode + clustered query
I guess this would be easy to integrate it in the already existant gui demo.
Big thanks !
--
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, 2 months
[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, 2 months
[JBoss JIRA] (ISPN-1534) Optimise Hot Rod client and server to work with asynchronous distributed caches
by Galder Zamarreño (Created) (JIRA)
Optimise Hot Rod client and server to work with asynchronous distributed caches
-------------------------------------------------------------------------------
Key: ISPN-1534
URL: https://issues.jboss.org/browse/ISPN-1534
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.FINAL
With Hot Rod clients, we can control where to direct invocations too, so there's a very interesting performance optimization we can apply with distributed caches. We can tolerate, and benefit from the speed of, asynchronous distributed caches very easily if we can get Hot Rod clients to always hit the owner of a key.
It's a bit like sticky sessions, but applied to remote distributed caches! I think this would improve performance of our Hot Rod architecture quite notably.
I think the Hot Rod client already works this way since I don't think it load balances between owners of a key.
So, the aim of this JIRA is to:
1. Verify whether the Hot Rod client works this way
2. Consider whether Hot Rod servers could transform, on the fly, synchronous distributed caches into asynchronous ones, indicating so in the logs (INFO level).
--
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, 2 months