Guys,
I was thinking about test ISPN-200 in a real environment. I want to compare
the distributed queries with local queries in different scenarios. Do you
have any thought about this? Any suggestions?
My first idea is to create an application that puts and search "n" values
(of size "x") in a ca
On 28 September 2011 19:08, Pete Muir wrote:
> I would say non-TX by default.
+1, as it's the current default.
I see many advantages in using TX instead, but if we change that I'd
expect that to happen in a mayor release.
Sanne
___
infinispan-dev mail
I would say non-TX by default.
On 28 Sep 2011, at 17:10, Mircea Markus wrote:
> Hi,
>
> ATM the default cache transaction model in 5.1 is transactional. The main
> reason transactional cache was chosen by default was backward compatibility:
> existing code that access the cache in a mixed way
On Wed, Sep 28, 2011 at 6:21 PM, Galder Zamarreño wrote:
>
> On Sep 28, 2011, at 4:06 PM, Galder Zamarreño wrote:
>
>>
>> On Sep 27, 2011, at 6:50 PM, Dan Berindei wrote:
>>
>>> On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-13
2 use cases:
- existing users already have this in place
- non exiting users: defaults to DummyTM.
On 28 Sep 2011, at 17:44, Manik Surtani wrote:
> Don't transactional caches require a JTA cache manager being present,
> configured and running?
>
> On 28 Sep 2011, at 17:10, Mircea Markus wrot
Don't transactional caches require a JTA cache manager being present,
configured and running?
On 28 Sep 2011, at 17:10, Mircea Markus wrote:
> Hi,
>
> ATM the default cache transaction model in 5.1 is transactional. The main
> reason transactional cache was chosen by default was backward compa
On 28 Sep 2011, at 12:48, Dan Berindei wrote:
>>
>> - Do we need the complex PREPARE_VIEW / ROLLBACK_VIEW / COMMIT_VIEW 2PC
>> handling ? This adds a lot of complexity. Is it only used when we have a
>> transactional cache ?
>>
>
> Nope, this doesn't have anything to do with transactional cach
On 09/28/2011 11:35 AM, Mircea Markus wrote:
> Hi,
>
> I'm not aware of any convention on using trace vs log.isTraceEnabled() to
> guard the trace statements.
>
> if (trace) log.trace("some request related stuff")
> vs
> if (log.isTraceEnabled()) log.trace("some request related stuff");
>
> The fo
Hi,
I'm not aware of any convention on using trace vs log.isTraceEnabled() to guard
the trace statements.
if (trace) log.trace("some request related stuff")
vs
if (log.isTraceEnabled()) log.trace("some request related stuff");
The former is more efficient, but cannot be managed at runtime. It s
Hi,
ATM the default cache transaction model in 5.1 is transactional. The main
reason transactional cache was chosen by default was backward compatibility:
existing code that access the cache in a mixed way (i.e. both transactional and
non transactional) would fail if the default mode is non tra
On Sep 28, 2011, at 4:06 PM, Galder Zamarreño wrote:
>
> On Sep 27, 2011, at 6:50 PM, Dan Berindei wrote:
>
>> On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño wrote:
>>> Hi,
>>>
>>> Re: https://issues.jboss.org/browse/ISPN-1384
>>>
>>> I've had a look to this and this race condition could,
On Sep 28, 2011 5:24 PM, "Mircea Markus" wrote:
>
> Nice stuff.
>
> Some q:
>
> - When a node CM that has c1 and c2 caches running on it goes down, you'll
end up having REQUEST_LEAVE(c1) and REQUEST_LEAVE(c2) at the same time. Is
this handled in serial or in parallel?
>
In parallel, although tha
Nice stuff.
Some q:
- When a node CM that has c1 and c2 caches running on it goes down, you'll end
up having REQUEST_LEAVE(c1) and REQUEST_LEAVE(c2) at the same time. Is this
handled in serial or in parallel?
- The view updates can be disabled dynamically (DISABLE_VIEW_UPDATES).
Shouldn't we
On 28 Sep 2011, at 15:02, Galder Zamarreño wrote:
> Thanks Mircea :)
>
> To all: I've had a look and made some comments, but this patch is definitely
> worth another look by at least another person.
+1
Manik and Sanne are good candidates.
___
infini
On Sep 27, 2011, at 6:50 PM, Dan Berindei wrote:
> On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño wrote:
>> Hi,
>>
>> Re: https://issues.jboss.org/browse/ISPN-1384
>>
>> I've had a look to this and this race condition could, in theory, be
>> resolved by making InboundInvocationHandlerImpl.
Thanks Mircea :)
To all: I've had a look and made some comments, but this patch is definitely
worth another look by at least another person.
On Sep 28, 2011, at 1:51 PM, Mircea Markus wrote:
>
> On 28 Sep 2011, at 10:05, Galder Zamarreño wrote:
>
>> Thanks Mircea. I've made some comments.
>
Hi Bela
After writing my reply I realized there is a small problem with my argument:
>
> In order to do it deterministically we need to have a common "last
> good consistent hash" for the last rebalance that finished
> successfully, and each node must determine if it should push a key or
> not ba
On 28 Sep 2011, at 10:05, Galder Zamarreño wrote:
> Thanks Mircea. I've made some comments.
Thanks, I've replied and updated the pull request.
Also added a summary: https://github.com/infinispan/infinispan/pull/551
>
> To all:
>
> If you're gonna submit a big pull req, please use the descrip
On Wed, Sep 28, 2011 at 12:59 PM, Bela Ban wrote:
> My 5 cents:
>
> Virtual Cache Views:
>
>
>
> - The REQUEST_VIEW_UPDATE is a good idea to manually trigger flushing of
> pending views. However, I'm not sure what the goal of
> DISABLE_VIEW_UPDATES is. Since I assume this is for t
On 28 Sep 2011, at 11:31, Sanne Grinovero wrote:
> Agreed, even better if we could use the commit description so it stays
> with the code, and you can describe a step at a time.
>
> We usually use a single-liner description, but for the more complex
> patches we should add a paragraph. I did it
Agreed, even better if we could use the commit description so it stays
with the code, and you can describe a step at a time.
We usually use a single-liner description, but for the more complex
patches we should add a paragraph. I did it occasionally, not sure
anybody noticed :)
Sanne
On 28 Septe
On 28 Sep 2011, at 10:05, Galder Zamarreño wrote:
>
> If you're gonna submit a big pull req, please use the description to
> *summarise the changes* in order to help reviewers. This helps focus the
> attention of the reviewer to the pieces of code that are most relevant.
+1!
--
Manik Surtani
My 5 cents:
Virtual Cache Views:
- The REQUEST_VIEW_UPDATE is a good idea to manually trigger flushing of
pending views. However, I'm not sure what the goal of
DISABLE_VIEW_UPDATES is. Since I assume this is for the entire cluster,
can 1 member disable view delivery for the e
I'm commenting on the wiki page.
On 27 Sep 2011, at 17:22, Dan Berindei wrote:
> Following the discussions last week I've written up a wiki page
> describing the strategies for cache view management and state transfer
> that will enable asymmetric caches and manual rehashing:
> http://community.j
Thanks Mircea. I've made some comments.
To all:
If you're gonna submit a big pull req, please use the description to *summarise
the changes* in order to help reviewers. This helps focus the attention of the
reviewer to the pieces of code that are most relevant.
On Sep 27, 2011, at 7:10 PM, Mi
25 matches
Mail list logo
