On Nov 15, 2013, at 2:02 PM, Sanne Grinovero sa...@infinispan.org wrote:
+1
(as I've always been, damn my pessimistic opinions)
However there is an alternative. If I recall correctly, one of your
motivations for the split was to not keep maintaining all the
non-essential components.
I
Someone mentioned the grouping API as some sort of alternative to
AtomicMap. Maybe we should use that?
Note that if we don't have a fine-grained approach we will need to
make sure we *copy* the complex data structure upon reads to mimic
proper transaction isolation.
On Tue 2013-11-12 15:14, Sanne
It appears that the even though InjectedCacheResolver has been configured in
the beans.xml of the example, at runtime DefaultCacheResolver is in use, which
creates a brand new cache manager instead of using an injected one. That's how
it's ending up with two cache managers. I'm debugging this
On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 14, 2013, at 1:20 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi,
Simple question: shouldn't PFER ensure some consistency?
I know that PFER is asynchronous but (IMO) it can create inconsistencies
in
Updated: we still have a REST cache store failure we're currently looking at,
6.0.0.Final will be released once that's fixed.
On Nov 13, 2013, at 1:11 PM, Mircea Markus mmar...@redhat.com wrote:
Hi guys,
The performance issues were fixed, I think we're good to release the final on
+1, also only the gui-demo should be in the main repo. All other
examples/demos should be moved to quickstarts or their own repos.
Tristan
On 11/18/2013 09:15 AM, Galder Zamarreño wrote:
On Nov 15, 2013, at 2:02 PM, Sanne Grinovero sa...@infinispan.org wrote:
+1
(as I've always been, damn
On 11/14/2013 06:06 PM, Vladimir Blagojevic wrote:
services? We only have William on our team who is native English
speaker, and I think all of us could use some help in that department :-)
I take offense to that: I am a native English speaker. I also happen to
be a native Italian speaker too
Attempt 1#
Failed tests:
Your machines are notorious the high number of intermittent failures, so this
doesn't look that bad then :-)
I've disabled AsyncReplExtendedStatisticTest [1] as it is not that critical.
Dan, can you please look at NonTxStateTransferOverwritingValue2Test? We seem to
be quite close to a stable
I have already issued a PR for NonTxStateTransferOverwritingValue2Test:
https://github.com/infinispan/infinispan/pull/2228
On Mon, Nov 18, 2013 at 10:13 PM, Mircea Markus mmar...@redhat.com wrote:
Your machines are notorious the high number of intermittent failures, so
this doesn't look that
Neither the grouping API nor the AtomicMap work over hotrod.
Between the grouping API and AtomicMap, I think the one that would make more
sense migrating is the grouping API.
One way or the other, I think the hotrod protocol would require an enhancement
- mind raising a JIRA for that?
For now I
On 18 November 2013 23:05, Mircea Markus mmar...@redhat.com wrote:
Neither the grouping API nor the AtomicMap work over hotrod.
Between the grouping API and AtomicMap, I think the one that would make more
sense migrating is the grouping API.
One way or the other, I think the hotrod protocol
On Nov 18, 2013, at 11:52 PM, Sanne Grinovero sa...@infinispan.org wrote:
Neither the grouping API nor the AtomicMap work over hotrod.
Between the grouping API and AtomicMap, I think the one that would make more
sense migrating is the grouping API.
One way or the other, I think the hotrod
Nice work!
Few questions:
- in the context of near-caching, entry-modified and entry-deleted would have
the same effect on the client: invalidation of data. If near-caching is our
main goal, we might as well send a single notification type (entry-modified)
for both modification and deletion
On Nov 12, 2013, at 2:51 PM, Paul Ferraro paul.ferr...@redhat.com wrote:
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple key/values. If the
batch is successful you
On Nov 12, 2013, at 3:11 PM, Pedro Ruivo pe...@infinispan.org wrote:
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple key/values. If the
batch is successful you know
On Nov 12, 2013, at 3:12 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/12/2013 11:56 AM, Galder Zamarreño wrote:
On Nov 8, 2013, at 4:28 PM, Mircea Markus mmar...@redhat.com wrote:
Hey guys,
Several things were discussed lately([1],[2],[3],[4]) around our
transaction support.
I've created a JIRA to track this: https://issues.jboss.org/browse/ISPN-3730
On Nov 19, 2013, at 2:17 AM, Mircea Markus mmar...@redhat.com wrote:
On Nov 12, 2013, at 3:12 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/12/2013 11:56 AM, Galder Zamarreño wrote:
On Nov 8, 2013, at 4:28
On 11/19/2013 03:06 AM, Mircea Markus wrote:
On Nov 12, 2013, at 2:51 PM, Paul Ferraro paul.ferr...@redhat.com wrote:
3. Optimistic tx without Write Skew Check (WSC)
- well, without WSC the transactions are not optimistic by definition
- they are something else: an batch update of multiple
19 matches
Mail list logo
