Mircea, I think I'm missing something here. Why would the originator send a
TxCompletionNotificationCommand at all if the commit command was
asynchronous?
I don't think recovery should require the originator to send a
TxCompletionNotificationCommand. Our commit commands can't fail anyway, so
the
On May 14, 2013, at 3:54 PM, Mark Addy ma...@c2b2.co.uk wrote:
Hi,
Thanks for the replies, all sorted now. I went back through the
previous archives and found ISPN-2281 and the changes associated to this.
So to get Hotrod working you must supply a custom Equivalence
implementation as an
On 05/16/2013 01:46 PM, Galder Zamarreño wrote:
On May 14, 2013, at 3:54 PM, Mark Addy ma...@c2b2.co.uk wrote:
Hi,
Thanks for the replies, all sorted now. I went back through the
previous archives and found ISPN-2281 and the changes associated to this.
So to get Hotrod working you must
Hi guys
I'm working on an intermittent failure in NodeMoveAPIPessimisticTest and I
think I've come across what I think is underspecified behaviour in
AtomicHashMap.
Say we have two transactions, tx1 and tx2, and they both work with the same
atomic map in a pessimistic cache:
1. tx1: am1 =
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? Shouldn't it be enabled by default/enforced?
[1] https://github.com/infinispan/infinispan/pull/1802
Cheers,
--
Mircea
Awesome stuff Cliff!
All other operations are just variations of put and get so this is quite a big
step forward!
On 16 May 2013, at 10:28, Clifford Jansen cjan...@redhat.com wrote:
Hi Mircea,
Progress is still slow. I have a successful ping to a Hot Rod server (Linux
only). At the
On 16 May 2013, at 15:04, Dan Berindei dan.berin...@gmail.com wrote:
Hi guys
I'm working on an intermittent failure in NodeMoveAPIPessimisticTest and I
think I've come across what I think is underspecified behaviour in
AtomicHashMap.
Say we have two transactions, tx1 and tx2, and they
Hi,
First, nice work on org.infinispan.affinity.KeyAffinityService ... May I
make 2 recommendations.
1. Add to the interface an overload =
*K getKeyForAddress(Address address, K otherKey);/*compute
address specific version of otherKey*/*
2. Provide documentation that
On 16 May 2013, at 19:12, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Hi,
First, nice work on org.infinispan.affinity.KeyAffinityService ... May I
make 2 recommendations.
Thanks for the feedback!
1. Add to the interface an overload =
*K getKeyForAddress(Address
On 16 May 2013, at 19:12, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
2. Provide documentation that *explicitly* motivates users to
understand/exercise the differences (and compatibilities) of the
KeyAffinityService API and the Grouping API. Now, that I have some
competency using
Done. see https://issues.jboss.org/browse/ISPN-3112
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027155.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
Added to the FAQ:
https://docs.jboss.org/author/display/ISPN/Grouping+API+vs+Key+Affinity+Service
Excellent. Thanks.
--
View this message in context:
http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-nice-2-recommendations-tp4027152p4027156.html
Sent from the
thank you.
On 16 May 2013, at 20:00, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Done. see https://issues.jboss.org/browse/ISPN-3112
--
View this message in context:
13 matches
Mail list logo
