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
Design for clustered events
by Radim Vansa
Hi Mircea,
as we were discussing the design of remote Hot Rod events with Galder,
the document regarding clustered events does not cover how should the
clustered listener information be propagated in case of topology change.
Could you add this info (or at least TODO so that we can see that there
is more work required on the document). Also, situations related to such
changes (such as reliability guarantees in case of node crash/join)
should be specified.
Thanks
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
11 years, 11 months
Re: [infinispan-dev] help with Infinispan OSGi
by Mircea Markus
+ infinispan-dev
Thanks for offering to look into this Brett!
We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
Tristan can get you up to speed with this.
>> Sanne/Galder/Pete,
>>
>> Random question: what's the current state of making Infinispan OSGi friendly? I'm definitely interested in helping, if it's still a need. This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind. Plus, I'd love for hibernate-infinispan to work in OSGi.
>>
>> If you're up for it, fill me in? I'm happy to pull everything down and start working with it.
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11 years, 11 months
Synchronous write on cachestore
by Guillaume SCHEIBEL
Hello everyone,
I'm fixing some issues on the MongoDB cachestore configuration (v5.3). I've
written a test [1] to check that the value I've added in the cache is
correctly persisted into my MongoDB collection.
The problem is that when comes at the "assert" time, the value put in the
cache has still not been stored in MongoDB.
So how can I do to have the value directly persisted into the cache store
database ?
Thanks
Guillaume
[1] https://gist.github.com/gscheibel/8138722
11 years, 11 months
Hot rod version 1.3 and QueryOperation
by Michal Linhard
Hi,
I'm checking the JDG 6.2.0 Docs on Hot Rod protocol that should describe
the 1.3 version
I realized that we don't actually fill version number 13 yet, i.e.
there's no such thing as HotRodConstants.VERSION_13 yet
but we already added HotRodConstants.QUERY_REQUEST = 0x1F; to protocol
1.2 which is in contradiction with docs
that says queries come in version 1.3:
http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_hot_rod_prot...
how do we plan to solve this ?
is this a bug and are we going to create version 13, whereby query op
will be supported only there and not in 12 ?
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
Re: [infinispan-dev] manual eviction and indexing
by Sanne Grinovero
Hi Adrian,
+1 good catch.
but what's a realistic use case for {indexing + eviction + no cachestore} ?
I guess some use cases might exist but I don't think it's critical,
would you agree?
and what about automatic eviction?
I think the guiding principle should be that if an entry can be
retrieved by key it should be searchable, and vice-versa, if I can
find it by running a query I should be able to load the result.
So expiry and other forms of eviction should also be considered, but
if there is no practical use case we can consider making this an
illegal configuration or simply log a warning about the particular
configuration.
Sanne
----- Original Message -----
> Hi Sanne,
>
> I found that manual eviction does not update the index. I think manual
> eviction should behave like a remove, if there are no cache stores
> configured.
>
> Here's a test and a 'fix' :)
> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>
> Let's discuss this when you have time.
>
> There is also the more complex situation of in-DataContainer eviction ...
>
12 years
