On 5/18/13 3:25 AM, Erik Salter wrote:
Hi all,
I’ve spent quite a bit of time with the existing XSite implementation,
getting my solution to run in multiple data centers. I’ve been talking
with Mircea and Bela on and off over the past few weeks, but since this
affects the community and
On May 16, 2013, at 12:00 PM, Mircea Markus mmar...@redhat.com wrote:
Hi Galder,
Whilst reviewing Tristan's pull request for ISPN-3008[1] I saw that we allow
configuring fetchInMemoryState for topology caches and wondering why we do
that?
^ Not sure exactly what you mean… When a node
On 05/21/2013 08:58 AM, Galder Zamarreño wrote:
Shouldn't it be enabled by default/enforced?
^ Either that, or the cluster cache loader are used, both of which serve the
same purpouse.
I think what Mircea is getting at, is that there is an intention to
deprecate / remove the CCL. I think
Can someone investigate why CacheImpl.replaceInternal() throws an NPE ?
I can reproduce this every time. Using the latest JDG.
See the attached stack trace for details.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
11:39:36,342 WARN
[Mircea]
Might be a problem in xsite replication when the keys that are updated
are not present. This happens all the time as xsite state transfer is
not yet implemented: a new site comes online, no state transfer, and an
xsite replication update will not be able to replace non-existing keys.
On 20 May 2013, at 22:12, Guillaume SCHEIBEL guillaume.schei...@gmail.com
wrote:
Hi Sanne,
You probably missed the notification but there is still one pending question
I asked you for the pull request:
@Sanne, I would like the MongoDBCacheStoreConfig constructor to return an
exception
On May 6, 2013, at 2:20 PM, Mircea Markus mmar...@redhat.com wrote:
On 3 May 2013, at 20:15, Paul Ferraro wrote:
Is it essential? No - but it would simplify things on my end.
If Infinispan can't implement expiration notifications, then I am forced
to use immortal cache entries and
I wouldn't want to deprecate CCL, I think it definitely has a purpose - at
least in invalidation mode.
Even in replication mode, having a lazy alternative to state transfer may
be useful. Maybe not for the topology cache, but it might make sense for
large caches.
On Tue, May 21, 2013 at 4:36
Hmmm, one hacky way might be to hold on to the grouper instance passed in via
configuration, and once the cache manager has been started, set it in the
grouper and use to query either the address, or the physical address (via
EmbeddedCacheManager.getTransport…)?
On May 14, 2013, at 6:34 PM,
I guess the grouper could use a KeyAffinityService (or something similar)
to generate a key local to each node and return that instead of 0 or 1.
However, you won't have any guarantee that the keys will stay on the same
node if the cache topology changes (e.g. another node joins).
It used to be
Thanks for the response Galder. Interesting. I have been counseled by
Mircea to use the KeyAffiinityService API to do my physical key pinning @
specific node participants. However, the KeyAffinityService brings the risk
of not being able to allow my pinned keys to survive topology changes
Ben, do you think being able to pin a key permanently to a node would be
useful?
Indeed I do.
The ideal mechanism would be to merge both the ambitions of the
Grouper#computeGroup(key) API and KeyAffinityService API into a capability
that would allow me to render non-anonymous grouping that
On Tue, 2013-05-21 at 17:07 +0200, Galder Zamarreño wrote:
On May 6, 2013, at 2:20 PM, Mircea Markus mmar...@redhat.com wrote:
On 3 May 2013, at 20:15, Paul Ferraro wrote:
Is it essential? No - but it would simplify things on my end.
If Infinispan can't implement expiration
Thanks to Guillaume Scheibel, Infinispan now has an mongodb cache store that
will be shipped as part of 5.3.0.CR1.
The test for the mongodb cache store are not run by default. In order to be
able to run them you need to:
- install mongodb locally
- run mongodb profile
The cache store was add in
Sent from my iPhone
On 21 May 2013, at 16:07, Galder Zamarreño gal...@redhat.com wrote:
On May 6, 2013, at 2:20 PM, Mircea Markus mmar...@redhat.com wrote:
On 3 May 2013, at 20:15, Paul Ferraro wrote:
Is it essential? No - but it would simplify things on my end.
If Infinispan
There is a way to download (via Maven) and run MongoDB locally from within
Java, via Flapdoodle's Embedded MongoDB:
https://github.com/flapdoodle-oss/embedmongo.flapdoodle.de
ModeShape uses this in our builds in support of our storage of binary values
inside MongoDB. The relevant Maven
16 matches
Mail list logo