some general comments:
- preserving some subset of the existing transactional guarantees is all
well and good BUT if the user is relying on additional 'guarantees' that
are not preserved in all cases then they'll be in trouble. Therefore,
it's essential to document not just what the minimum
2011/6/1 Jonathan Halliday jonathan.halli...@redhat.com:
some general comments:
- preserving some subset of the existing transactional guarantees is all
well and good BUT if the user is relying on additional 'guarantees' that
are not preserved in all cases then they'll be in trouble.
For those of you that are constantly building Infinispan, I've gone and moved
all non-essential build plugins to an 'extras' profile that can be disabled at
build time, i..e.:
mvn install -P-extras
More info in: http://community.jboss.org/docs/DOC-15189
Cheers,
--
Galder Zamarreño
Sr.
What do you mean by TopologyView's Externalizer not being picked? If it's not,
that's a bug (=JIRA).
On Jun 1, 2011, at 6:29 AM, 이희승 (Trustin Lee) wrote:
Thanks for a hint. TopologyView has its own Externalizer, but it was
not picked up by Infinispan and thus fell back to Serializable.
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of partial state transfer in JGroups 3.0, and don't like
to add it back, I'd like to know whether this is still needed.
I thought that we currently require
Hi Bela,
2011/6/1 Bela Ban b...@redhat.com:
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of partial state transfer in JGroups 3.0, and don't like
to add it back, I'd like to know whether this is still
On 6/1/11 4:21 PM, Sanne Grinovero wrote:
Hi Bela,
2011/6/1 Bela Banb...@redhat.com:
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of partial state transfer in JGroups 3.0, and don't like
to add it
Why are we actually using JGroups' state transfer with replication, but
use our own state transfer with distribution ?
I don't know, but guess it's because each node has a different set of
keys so no node has the same state as another ?
You could still use JGroups state transfer;
Hi,
My name is Pedro and I am working in CloudTM project.
I think that I may have encountered a possible bug in the consistent
hash function.
I am working on Infinispan 'Pagoa' 5.0.0-SNAPSHOT with JGroups 3.0.0
Alpha1 and I have a total of 100 000 keys distributed by 11 nodes.
I am using
On 1 Jun 2011, at 08:26, Jonathan Halliday wrote:
some general comments:
- preserving some subset of the existing transactional guarantees is all well
and good BUT if the user is relying on additional 'guarantees' that are not
preserved in all cases then they'll be in trouble. Therefore,
I'll hold on ISPN-1107 which is about measuring performance and switch to doing
fixes. I'll also take some issues from Manik's queue.
On 31 May 2011, at 22:42, Vladimir Blagojevic wrote:
I'll close ISPN-83 if I do not hear any negative feedback from Paul
about Infinispan flush tests that
I posted a message on the as7-dev ml
(http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html),
about switching to use the TransactionSynchronizationRegistry.
Does Infinispan currently register Transaction synchronization objects?
Does Infinispan currently register
On 6/1/11 6:05 PM, Mircea Markus wrote:
Why are we actually using JGroups' state transfer with replication, but
use our own state transfer with distribution ?
I don't know, but guess it's because each node has a different set of
keys so no node has the same state as another ?
You could
13 matches
Mail list logo
