[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
11 years, 11 months
[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
11 years, 11 months
[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
11 years, 11 months
[JBoss JIRA] (ISPN-2177) Refactor AbstractCacheTransaction
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2177:
-----------------------------------
Summary: Refactor AbstractCacheTransaction
Key: ISPN-2177
URL: https://issues.jboss.org/browse/ISPN-2177
Project: Infinispan
Issue Type: Feature Request
Components: Transactions
Affects Versions: 5.1.2.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.FINAL
There are several collections holding transaction related information in the AbstractCacheTraansaction:
- lockedKeys: this holds all the keys that were actually locked on the local node
- affectedKeys: this holds all the keys that were acquired by the transaction allover the cluster
- backupKeyLocks: this holds all the locks for which the local node is a secondary data owner.
To do:
- affectedKeys belongs to LocalCacheTransaction(subclass) and no point in having it in the AbstractCacheTransaction
- a better name for affectedKeys might be "clusterLockedKey" and for lockedKeys --> localLokedKeys
- also add a Javadoc explaining the correlation between these key groups
--
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
11 years, 11 months
[JBoss JIRA] (ISPN-2107) Enable logging for all modules' test suites
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2107:
----------------------------------
Summary: Enable logging for all modules' test suites
Key: ISPN-2107
URL: https://issues.jboss.org/browse/ISPN-2107
Project: Infinispan
Issue Type: Task
Components: Test Suite
Affects Versions: 5.1.5.FINAL
Reporter: Dan Berindei
Assignee: Mircea Markus
Fix For: 5.2.0.ALPHA1
Some modules do not log anything, not even to the console, because they don't have a {{log4j.xml}} file in their classpath (e.g. cdi). Because of this, errors in jenkins are harder to spot and to fix.
We should ensure that each module has a log4j configuration file in the test classpath (or maybe use a system property to configure a generic log4j.xml in the root directory). Preferably each module should have its own log file, but they could use the same log file as long as they don't truncate it.
--
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
11 years, 11 months