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, 2 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, 2 months
Non-tx X-Site: doubts and opinions
by Pedro Ruivo
Hi guys,
I'm digging in detail in X-Site code and I have a couple of
doubts/comments.
*Note*: I'm talking about non-tx caches :)
First, I've noticed that we are forcing the /site_master/ node to have a
reference to the cache in order to perform the modifications from other
sites. IMO, it can be possible the user may not want to have that cache
running that node. WDYT?
My idea is, if the /site_master/ has the reference to the cache, it can
use, otherwise it multicast the command to all the nodes in the site.
The nodes that does not have the cache (or if they are not primary owner
of any key) will ignore the command :)
Second and finally, I find a couple of optimization that can be done. #1
I've noticed that we are sending the conditional commands to the backup
sites without checking if the command is successful in the originator
site. I think we can save network bandwidth and time to avoid
serializing the commands that will fail...
#2 Also, the originator is the node that sends the command to the other
sites. IMO, it can generate inconsistencies because 2 or more nodes in
/site_a/ can update the same key concurrently and other /site_b/ can
receive the commands in different order (at least, I didn't see any
protection mechanism against this case)
I think the backup to other sites should be sent by the /primary_owner/
(lock owner).
Thanks in advance for the feedback.
Cheers and Happy New Year :)
Pedro
11 years, 2 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, 2 months
