[JBoss JIRA] Created: (ISPN-509) Enable listeners to be hooked to Hot Rod servers
by Galder Zamarreno (JIRA)
Enable listeners to be hooked to Hot Rod servers
------------------------------------------------
Key: ISPN-509
URL: https://jira.jboss.org/browse/ISPN-509
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 5.0.0.Final
Enable Hot Rod servers to have listeners injected.
At the moment, this would require some code to programatically start a Hot Rod server and associate the listener. This would not be nice cos such program would need to deal with command line parameters....etc.
So, we need a way to put listeners into Hot Rod server. I can think of two options:
- Enable listeners to be set via configuration XML.
- Enable Hot Rod to be passed listeners via command line parameter and get Hot Rod to instantiating them.
--
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, 11 months
[JBoss JIRA] Created: (ISPN-1239) Graceful shutdown should be supported
by Manik Surtani (JIRA)
Graceful shutdown should be supported
-------------------------------------
Key: ISPN-1239
URL: https://issues.jboss.org/browse/ISPN-1239
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.0.0.FINAL
Reporter: Manik Surtani
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.1.0.BETA1, 5.1.0.Final
Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down.
Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1189) config schema - clustering mode should validate format of the string
by Michal Linhard (JIRA)
config schema - clustering mode should validate format of the string
--------------------------------------------------------------------
Key: ISPN-1189
URL: https://issues.jboss.org/browse/ISPN-1189
Project: Infinispan
Issue Type: Enhancement
Components: Configuration
Affects Versions: 5.0.0.CR5
Reporter: Michal Linhard
Assignee: Manik Surtani
Priority: Minor
currently the schema for the clustering mode says it's a string and
the mode is decided by first letter of the string. this means that any garbage starting with the correct letter may lead to use of a specific mode e.g.:
lasjadgadfg -> local
rhdbhgh -> replication
dfghbmjfgh -> distribution
IlkHhdf -> invalidation
what about forcing only the documented values
"For distribution, set mode to either 'd', 'dist' or 'distribution'. For replication, use either 'r', 'repl' or 'replication'. Finally, for invalidation, 'i', 'inv' or 'invalidation'."
+ LOCAL
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1341) Eviction treats FIFO as LRU
by Jozef Vilkolak (JIRA)
Eviction treats FIFO as LRU
---------------------------
Key: ISPN-1341
URL: https://issues.jboss.org/browse/ISPN-1341
Project: Infinispan
Issue Type: Bug
Components: Eviction
Affects Versions: 5.0.0.FINAL
Reporter: Jozef Vilkolak
Assignee: Manik Surtani
When a cache is created with eviction strategy set to FIFO it is actually treated as being LRU. This can be seen in org.infinispan.container.DefaultDataContainer.java.
Functional test for FIFO eviction can be found at [https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-functional-tests/trunk/] in the eviction-strategy module.
Basically what the test does is insert 3 values into the cache then retrieves the first value(to differentiate FIFO and LRU) and inserts 4th value which sets eviction in motion because of maxEntries=3.
I would expect the first entered value ("A") to be evicted instead it evicts the second ("B").
It uses the following cache configuration:
{code:xml}
<local-cache
name="fifo"
start="EAGER"
batching="false"
indexing="NONE">
<locking
isolation="REPEATABLE_READ"
acquire-timeout="20000"
concurrency-level="500"
striping="false" />
<eviction
strategy="FIFO"
max-entries="3"
interval="2000"/>
</local-cache>
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months