Infinispan embedded off-heap cache
by yavuz gokirmak
Hi all,
Is it possible to use infinispan as embedded off-heap cache.
As I understood it is not implemented yet.
If this is the case, we are planning to put effort for off-heap embedded
cache development.
I really need to hear your advices,
best regards
11 years, 9 months
Design change in Infinispan Query
by Sanne Grinovero
Hello all,
currently Infinispan Query is an interceptor registering on the
specific Cache instance which has indexing enabled; one such
interceptor is doing all what it needs to do in the sole scope of the
cache it was registered in.
If you enable indexing - for example - on 3 different caches, there
will be 3 different Hibernate Search engines started in background,
and they are all unaware of each other.
After some design discussions with Ales for CapeDwarf, but also
calling attention on something that bothered me since some time, I'd
evaluate the option to have a single Hibernate Search Engine
registered in the CacheManager, and have it shared across indexed
caches.
Current design limitations:
A- If they are all configured to use the same base directory to
store indexes, and happen to have same-named indexes, they'll share
the index without being aware of each other. This is going to break
unless the user configures some tricky parameters, and even so
performance won't be great: instances will lock each other out, or at
best write in alternate turns.
B- The search engine isn't particularly "heavy", still it would be
nice to share some components and internal services.
C- Configuration details which need some care - like injecting a
JGroups channel for clustering - needs to be done right isolating each
instance (so large parts of configuration would be quite similar but
not totally equal)
D- Incoming messages into a JGroups Receiver need to be routed not
only among indexes, but also among Engine instances. This prevents
Query to reuse code from Hibernate Search.
Problems with a unified Hibernate Search Engine:
1#- Isolation of types / indexes. If the same indexed class is
stored in different (indexed) caches, they'll share the same index. Is
it a problem? I'm tempted to consider this a good thing, but wonder if
it would surprise some users. Would you expect that?
2#- configuration format overhaul: indexing options won't be set on
the cache section but in the global section. I'm looking forward to
use the schema extensions anyway to provide a better configuration
experience than the current <properties />.
3#- Assuming 1# is fine, when a search hit is found I'd need to be
able to figure out from which cache the value should be loaded.
3#A we could have the cache name encoded in the index, as part
of the identifier: {PK,cacheName}
3#B we actually shard the index, keeping a physically separate
index per cache. This would mean searching on the joint index view but
extracting hits from specific indexes to keep track of "which index"..
I think we can do that but it's definitely tricky.
It's likely easier to keep indexed values from different caches in
different indexes. that would mean to reject #1 and mess with the user
defined index name, to add for example the cache name to the user
defined string.
Any comment?
Cheers,
Sanne
11 years, 10 months
Integration between HotRod and OGM
by Davide D'Alto
Hi,
I'm working on the integration between HotRod and OGM.
We already have a dialect for Inifinispan and I'm trying to follow the same
logic.
At the moment I'm having two problems:
1) In the Infinispan dialect we are using the AtomicMap and the
AtomicMapLookup but this classes don't work with the RemoteCache. Is there
an equivalent for HotRod?
2) As far as I know HotRod does not support transactions. I've found a link
to a branch on Mircea repository:
https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
Is this something I could/should use?
Any help is appreciated.
Thanks,
Davide
11 years, 11 months
Cost of inheritance
by Sanne Grinovero
In a particular benchmark I'm running, the bottleneck of my system
seems to be the object allocation rate.
More specifically, in just some minutes I've got about 55GB allocated
just of instances of SingleKeyNonTxInvocationContext
(yes I literally mean GigaBytes)
and 45GB of org.infinispan.commands.read.GetKeyValueCommand.
To be clear: these high amounts are caused only by the "shallow" class
instance of these two types, not counting key nor value sizes being
actually moved into/out Infinispan.
Of course it means we're talking about many of these instances, but
also the size of each of them matters, so I've been taking a look at
their definitions.
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
# org.infinispan.context.SingleKeyNonTxInvocationContext
offset size type description
0 12 (assumed to be the object header + first
field alignment)
12 1 byte AbstractInvocationContext.contextFlags
13 3 (alignment/padding gap)
16 4 Address AbstractInvocationContext.origin
20 4 WeakReference AbstractInvocationContext.classLoader
24 1 boolean SingleKeyNonTxInvocationContext.isOriginLocal
25 1 boolean SingleKeyNonTxInvocationContext.isLocked
26 2 (alignment/padding gap)
28 4 Object SingleKeyNonTxInvocationContext.key
32 4 CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
36 4 (loss due to the next object alignment)
40 (object boundary, size estimate)
I notice two things in here:
a) we could refactor maybe some code to have less fields in such a
hot allocated type
b) Lots of space is being wasted in padding!
If you count the bytes lost because of the various alignment rules: 9
That's almost 25%, about 13GB of used memory!
Why are there two separate object alignment gaps? That's because the
fields of the parent class need to be grouped, then the child class's
fields are aligned after it.
In other words, if I move the fields from the parent class to the
bottom class I get:
org.infinispan.context.SingleKeyNonTxInvocationContext
offset size type description
0 12 (assumed to be the object header + first
field alignment)
12 1 byte SingleKeyNonTxInvocationContext.contextFlags
13 1 boolean SingleKeyNonTxInvocationContext.isOriginLocal
14 1 boolean SingleKeyNonTxInvocationContext.isLocked
15 1 (alignment/padding gap)
16 4 Address SingleKeyNonTxInvocationContext.origin
20 4 ClassLoader SingleKeyNonTxInvocationContext.classLoader
24 4 Object SingleKeyNonTxInvocationContext.key
28 4 CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
32 (object boundary, size estimate)
which recovers 20% ..
Looking forward to see simpler class hierarchies in the code ;-)
Sanne
12 years
rethinking ISPN transactions
by Mircea Markus
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our transaction support. Here's some some thoughts I have around re-modeling transactions for 7.0:
1. Async options for commit/rollback
- they don't really make sense as a user you don't get any guarantee on the status of the transaction
- they complicate the code significantly
- I think they should be removed
2. READ_COMMITTED
- it has the same performance as REPEATABLE_READ, but offers less guarantees.
- unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
- I think it should be removed
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
- suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
- build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
4. Remove 1PC option
- I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
[1] http://markmail.org/thread/a7fjko4dyejxqgdy
[2] https://github.com/infinispan/infinispan/pull/2177
[3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
[4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years
Doubt Regarding Infinispan Cache Creation limit
by Faseela K
Hello,
Is there any limitation on the number of infinispan caches that can be created, in a clustered environment?
Also, is there any performance difference between the below two cases :
Case 1 : Constructing a cache with 10000 entries
Case 2 : Splitting the above cache into 100 caches of 100 entries.
Entry count is same in both the cases, but will there be any significant performance overhead in creating 100 caches?
Thanks,
Faseela
12 years
PutForExternalRead consistency
by Pedro Ruivo
Hi,
Simple question: shouldn't PFER ensure some consistency?
I know that PFER is asynchronous but (IMO) it can create inconsistencies
in the data. the primary owner replicates the PFER follow by a PUT (PFER
is sent async log the lock is released immediately) for the same key, we
have no way to be sure if the PFER is delivered after or before in all
the backup owners.
comments?
Pedro
12 years
Today's topic: eviction
by Pedro Ruivo
(re: https://issues.jboss.org/browse/ISPN-3048)
(ps. sorry for the long mail. I hope that is clear)
* Automatic eviction:
I've been writing some scenario involving eviction and concurrent
operations. This test shows a very reliable eviction but we have a
problem when passivation is enabled. The passivation phase is ok but
when we need to activate a key, we have a huge window in which the
read/write operation does not find the key neither in-memory data
container neither in the cache loader. This happens because the check
in-memory data container is not synchronized with the check in cache loader.
Passivation phase works fine, as I said, because it happens inside the
data container, i.e., the bounded concurrent hash map (BCHM) evict the
key under the segment lock.
* Manual eviction
I haven't finish my test suite but so far it does not work as expected.
If you are a backup owner, you are unable to evict any keys (because the
EvictCommand is handled as a RemoveCommand and the key is not wrapped in
EntryWrappingInterceptor). In addition, I believe that it has the same
problems with activation as above.
Also, I believe that passivation phase does not work well because it
first tries to passivate than it removes from DataContainer. Nothing is
preventing to passivate an old value, a put occurs and modifies the data
in DataContainer and finally the EvictCommand removes the new value
(that is lost).
* New implementation
Since we are stating a new major release, I would like to "propose" the
following improvements. One aspect of the implementation is the dropping
of the *Cache[Writer or Loader]Interceptor and the EvictCommand. Also,
it would add a new method in DataContainer (void evict(K key)) and
possible change the interface in PersistenceManager.
My idea is based on the current implementation of the BCHM. The BCHM
implementation is aware of the persistence and it performs internally
the passivate() and activate() operations. I would like to extend this
and make it full aware of the PersistenceManager. Also, it would be
required to have ConcurrentHashMap (CHM) with the same features
Enter in more detail, the (B)CHM.get() will be responsible to load the
key from persistence (and activate it) if it is not found in-memory.
Also, it stores the entry in memory. In other hand, the put() stores the
entry in-memory and in the persistence (if passivation==false) and we
add an evict(k) to the CHM interface to remove from memory and passivate
it to persistence a single key.
* Pros
** solves all the problems :)
** remove all the interceptors related to cache writer and cache loader
=> small interceptor chain
** remove evict command => lower process time(?)
** cache writer and cache loader does not need to have per key lock
based (however, they should be thread safe)
** when passivation==true, we don't loose any key/value (yey)
** no need to acquire locks in lock manager (as the current manual
eviction does)
** all the logic for cache loader/writer will be located in a single mode
* Cons
** difficult to maintain. We have to maintain the code for the (B)CHM
** new API and contract for DataContainer interface => it should handle
all the load/write from cache loader/writer
** new API for PersistenceManager
toughs?
Cheers
Pedro
* Open question in case this is going forward
** should contains(key) put the entry loaded in-memory (if loaded from
cache loader)?
** how iterator(), keys(), values() and entrySet() should behave? should
they put the entries in memory? And size()?
* API changes
DataContainer
(new) void evict(K key)
PersistenceManager
(new) Entry onRead(K key) //shoud read the key. if passivation, remove
from loader
(new) void onWrite(K key, Entry entry) //if passivation, then do
nothing, else store it
(new) Entry onRemove(K key) //remove and return old
(new) void onEvict(K key, Entry entry) //if passivation, then store it
* Some (B)CHM pseudo-code
V get(K key)
Segment s = segment(key)
V value = s.get(key)
if (value == null) {
s.lock()
//recheck if s.get(key) is still null
value = persistenceManager.onLoad(key); //this activates the key if
needed
if (value != null) s.put(key, value)
s.unlock()
}
return value
V put(K key, V value)
Segment s = segment(key)
s.lock()
V oldValue = s.get(key)
persistenceManager.onWrite(key, value) //first try the persistence
s.put(key, value) //can trigger eviction
s.unlock()
void evict(K key, V value)
Segment s = segment(key)
s.lock()
persistenceManager.onEvict(key, value) //first try the persistence
s.remove(key) //remove from memory if peristence is successful (we
don't wanna loose the value, right?)
s.unlock()
12 years
configuration toProperties
by Michal Linhard
Hi,
This is a configuration output format feature proposal.
I'd like to be able to flatten the infinispan cache configuration to
flat properties style so that two configurations can be easily comparable
in a view that displays sorted matching properties side by side to
quickly spot differences.
This is useful in our internal PerfRepo app where I do it so far by
reflection, by patching the server or a radargun plugin by special
addon, but this can lead to numerous errors. It would be much simpler
and less error-prone process if we had it integrated in the upstream code.
I proposed adding a method configuration.toProperties() that flattens
properties of a configuration object
(org.infinispan.configuration*Configuration) and produces
java.util.Properties. The nested configuration objects under the main
Configuration would recursively add their properties under an extended
property prefix.
I also added a possibility to specify --format=properties in the info
command of the CLI so that the server responds with the property style
configuration of the specific cache...
https://github.com/mlinhard/infinispan/commit/d8360f7850b67956adfa29aca86...
(I didn't implement toProperties in all objects, cause it's quite a lot
of changes that would be made in vain in case you don't like this
approach, the commit just demonstrates how I'd like to go about it.)
These properties would also be exposed via JMX as (example values)
jboss.infinispan:type=Cache,name="testCache(dist_sync)",manager="default",component=Cache
attribute "configurationProperties"
jboss.infinispan:type=CacheManager,name="default",component=CacheManager
attribute "globalConfigurationProperties"
that could be converted by any JMX client back to java.util.Properties
WDYT?
m.
--
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 8262320
mobile: +420 728 626 363
12 years
