Scott, if you want I can cut CR5 this morning based on what we have and then a
CR6 for next week, with the bits we originally had in mind for CR5.
I'm trying to compete with Bob McW for the largest number of release
candidates. ;)
On 9 Jun 2011, at 21:42, Scott Marlow wrote:
As a short
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote:
+1 to writing the error marker to the stream. At least prevent false alarms.
Re: unit testing our externalizers, Galder, any thoughts there?
The debugging done by Sanne/Dan seems to be correct.
Thanks for the paper, Paolo - I'll have a read of it over the weekend.
On 9 Jun 2011, at 21:47, Paolo Romano wrote:
There has been a lot of discussion on this topic also in the Transactional
Memory area, triggered to the best of my knowledge by this paper [1].
Mixing transactional and
I was referring to generating byte arrays (sending state), not generating
objects (receiving state). A buffer is maintained in the AbstractMarshaller
and used.
I did see a comment from Bela on this thread about seeing this on the receiver
too though - Bela, care to clarify? I presume on the
On 10 Jun 2011, at 04:48, Tristan Tarrant wrote:
I don't know if I'm actually contributing something here or just creating
noise.
Are these buffers reused over time ? If not, from a GC point of view
it would be better then not to reduce the size of the buffer just to
save a few bytes: it
Manik,
I'd like to try doing that and revert back to using a patched CR4 if we
hit any issues/regressions (would be nice to know what they are for
Monday's build :-)
If we get stuck this weekend (or late today), we can always go the patch
route.
I'll talk to Paul about this as well, as he
2011/6/10 Manik Surtani msurt...@redhat.com:
Some tests - like ExpiryTest - rely on certain timings for the test to run,
and due to thread scheduling on our parallel test suite, tend to
occasionally fail on certain environments such as CloudBees:
So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:
BCHM analyses whether or not to evict stuff every time an operation (put, get,
replace) is run, based on the configured eviction policy (LIRS, LRU or NONE).
It does so by calling evictionStrategy.execute(), which
It looks as a good improvement, especially as we remove the locking,
but I still have some doubts:
1) as the passivation happens in the eviction thread, is that going to
be fast enough or hindering the eviction performance? especially with
LIRS, being this the user thread it means that put
This is a very tricky one indeed. These might fail as well e.g. if we increase
the number of concurrent threads running the test suite. I remember when
switching from 1 thread to 10 there were many of these failing.
I think your suggestion makes sense.
On 10 Jun 2011, at 13:02, Manik Surtani
IDK if it's possible (or if it changes the purpose of the test too much), but
can we add a new expiry policy which is actually deterministic, so we mimic
expirations?
This won't test the default expiry policy, but would test the logic managing
expiration.
On 10 Jun 2011, at 14:20, Mircea
On 10 Jun 2011, at 14:18, Sanne Grinovero wrote:
It looks as a good improvement, especially as we remove the locking,
but I still have some doubts:
1) as the passivation happens in the eviction thread, is that going to
be fast enough or hindering the eviction performance? especially with
This certainly helps, I'll give it a go,
On 10 Jun 2011, at 13:15, Sanne Grinovero wrote:
2011/6/10 Manik Surtani msurt...@redhat.com:
Some tests - like ExpiryTest - rely on certain timings for the test to run,
and due to thread scheduling on our parallel test suite, tend to
occasionally
On Jun 10, 2011, at 3:18 PM, Sanne Grinovero wrote:
/snip
3) so every time we evict an entry, we write it to the store.. I guess
that leads to re-write quite often values which are already in the
store, and for which there's no need to store again. I think this
argument came up before,
On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote:
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote:
+1 to writing the error marker to the stream. At least prevent false alarms.
Re: unit testing our externalizers, Galder, any thoughts
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote:
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote:
+1 to writing the error marker to the stream. At least prevent false
alarms.
Re: unit
On 10 Jun 2011, at 14:44, Sanne Grinovero wrote:
With passivation enabled, the entry is only written to the store when
removed from memory. And when activating (store - memory) it is removed
from the store. So you wouldn't really write twice to the store.
Thanks, with that you answered
On 10 Jun 2011, at 14:33, Manik Surtani wrote:
2) with async stores, the issue is back. The value is not going to be
found while it's in flight in the async storage queue; so unless you
want to avoid supporting it for now, the actual removal from the
container should be performed from the
On Jun 10, 2011, at 3:51 PM, Sanne Grinovero wrote:
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 10, 2011, at 11:42 AM, Sanne Grinovero wrote:
2011/6/10 Galder Zamarreño gal...@redhat.com:
On Jun 9, 2011, at 5:47 PM, Manik Surtani wrote:
+1 to writing the error marker to the
2011/6/10 Manik Surtani ma...@jboss.org:
Anyway, to summarise, does this cover everything?
1) Passivate before evict, as described below
2) AsyncStore checks async queue before delegating to actual cache store on
load
Cheers
Manik
Yes, looks good! 2) won't be easy, AFAIR the AsyncStore
Ok, pls have a look and comment, guys:
https://github.com/infinispan/infinispan/pull/380
On 10 Jun 2011, at 15:45, Manik Surtani wrote:
On 10 Jun 2011, at 15:35, Sanne Grinovero wrote:
2011/6/10 Manik Surtani ma...@jboss.org:
Anyway, to summarise, does this cover everything?
1)
2011/6/10 Manik Surtani ma...@jboss.org:
On 10 Jun 2011, at 15:35, Sanne Grinovero wrote:
2011/6/10 Manik Surtani ma...@jboss.org:
Anyway, to summarise, does this cover everything?
1) Passivate before evict, as described below
2) AsyncStore checks async queue before delegating to actual
22 matches
Mail list logo
