On 11/19/2013 03:06 AM, Mircea Markus wrote:
> On Nov 12, 2013, at 2:51 PM, Paul Ferraro 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 t
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 wrote:
>
> On Nov 12, 2013, at 3:12 PM, Pedro Ruivo wrote:
>
>> On 11/12/2013 11:56 AM, Galder Zamarreño wrote:
>>>
>>> On Nov 8, 2013, at 4:28 PM, Mircea Markus wrote:
>>
On Nov 12, 2013, at 3:12 PM, Pedro Ruivo wrote:
> On 11/12/2013 11:56 AM, Galder Zamarreño wrote:
>>
>> On Nov 8, 2013, at 4:28 PM, Mircea Markus wrote:
>>
>>> Hey guys,
>>>
>>> Several things were discussed lately([1],[2],[3],[4]) around our
>>> transaction support. Here's some some though
On Nov 12, 2013, at 3:11 PM, Pedro Ruivo 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 the update was
On Nov 12, 2013, at 2:51 PM, Paul Ferraro 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 the update wa
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 (th
On Nov 18, 2013, at 11:52 PM, Sanne Grinovero 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 would
On 18 November 2013 23:05, Mircea Markus 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 would require an
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 g
I've created ISPN-3728 to track this.
On Nov 18, 2013, at 2:16 PM, Tristan Tarrant wrote:
> +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:
>> O
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 wrote:
> Your machines are notorious the high number of intermittent failures, so
> this doesn't look that bad then :-)
>
>
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 tes
Attempt 1#
Failed tests:
AsyncReplExtendedStatisticTest>BaseClusteredExtendedStatisticTest.testReplaceWithOldVal:190->BaseClusteredExtendedStatisticTest.assertCacheValue:253->MultipleCacheManagersTest.assertEventuallyEquals:554->AbstractInfinispanTest.eventually:173->AbstractInfinispanTest.eventua
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
+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 wrote:
>
>> +1
>> (as I've always been, damn my "pessimistic"
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 wrote:
> Hi guys,
>
> The performance issues were fixed, I think we're good to release the final on
> Thu/Fri.
> Please let
On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreño wrote:
>
> On Nov 14, 2013, at 1:20 PM, Pedro Ruivo wrote:
>
> > Hi,
> >
> > Simple question: shouldn't PFER ensure some consistency?
> >
> > I know that PFER is asynchronous but (IMO) it can create inconsistencies
> > in the data. the primary ow
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 fu
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
On Nov 15, 2013, at 2:02 PM, Sanne Grinovero 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 really like th
20 matches
Mail list logo
