+1 for Externalizer/AdvancedExternalizer.
Dan
On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote:
Guys, any thoughts on this? I want this in for BETA2...
On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote:
Hi,
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir
On Wed, May 4, 2011 at 5:09 PM, Pete Muir pm...@redhat.com wrote:
On 4 May 2011, at 05:34, Dan Berindei wrote:
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05
2011/5/4 Pete Muir pm...@redhat.com:
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com
wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero
that (a) is the best approach right now, and is not that
onerous a requirement.
We might want to make the TCCL usage pluggable for OSGI envs. Cc'd David to
get his feedback.
On 4 May 2011, at 10:46, Dan Berindei wrote:
On Wed, May 4, 2011 at 5:09 PM, Pete Muir pm...@redhat.com wrote:
On 4 May
On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic
vblag...@redhat.com wrote:
The more I research ReentrantReadWriteLock the more shocked I am. Not
only that a thread wanting to acquire write lock first has to release
read lock, but we can block forever even if we release the read lock if
On Wed, May 11, 2011 at 5:51 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 11 May 2011, at 13:57, Dan Berindei wrote:
With the new push-based rebalancing code, we install the new CH before
doing any rebalancing work, so the inconsistency window should be much
smaller.
In theory we
I disabled the Osmorc plugin and that seemed to stop it.
Dan
On Wed, May 11, 2011 at 8:50 PM, Mircea Markus mircea.mar...@jboss.com wrote:
Hi,
Whenever I'm switching branches from 4.2.x to master the build in IDEA takes
ages(even more, about 5 mins!!!). Most of the time is spent is
On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote:
Were we developing for OSGi I would certainly agree with you. However in
many environments today we can
On Thu, May 12, 2011 at 1:22 PM, Emmanuel Bernard
emman...@hibernate.org wrote:
On 12 mai 2011, at 11:18, Dan Berindei wrote:
That seems like a lot of overhead to me, and forcing the user to
provide the classloader doesn't seem that bad in comparison. Perhaps
we should use something other
stored
together.
Cheers
Dan
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Dan Berindei
Sent: Wednesday, May 11, 2011 12:47 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] https
On Fri, May 13, 2011 at 6:38 PM, Erik Salter esal...@bnivideo.com wrote:
Yes, collocation of all keys is a large concern of my application(s).
Currently, I can handle keys I'm in control of (like database-generated
keys), where I can play around with the hash code. What I would love to do
On Fri, May 13, 2011 at 5:48 PM, Jason T. Greene
jason.gre...@redhat.com wrote:
On 5/12/11 4:18 AM, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com
wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm
Hi Olaf,
Did you see any problems with RHQ + Spring interaction that determined
you to exclude the rhq-pluginAnnotations dependency in the spring
module?
dependency
groupId${project.groupId}/groupId
artifactIdinfinispan-core/artifactId
, Dan Berindei wrote:
On Wed, May 11, 2011 at 11:18 PM, David Bosschaert
da...@redhat.com mailto:da...@redhat.com wrote:
On 11/05/2011 17:54, Dan Berindei wrote:
On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com
mailto:pm...@redhat.com wrote:
Were
On Wed, May 18, 2011 at 7:06 PM, Manik Surtani ma...@jboss.org wrote:
Hi guys
Sorry I've been absent from this thread for a while now (it's been growing
faster than I've been able to deal with email backlog!)
Anyway, this is a very interesting discussion. To summarise - as Pete did at
On Thu, May 19, 2011 at 1:31 PM, Galder Zamarreño gal...@redhat.com wrote:
On May 19, 2011, at 12:11 PM, Manik Surtani wrote:
Guys - what are we talking about? Specifying ClassLoaders is only
meaningful if storeAsBinary is set to true.
Ok, that was not clear to me throughout the
On Mon, May 23, 2011 at 7:04 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/20/2011 03:54 PM, Manik Surtani wrote:
Is spanning rows the only real solution? As you say it would mandate using
transactions to keep multiple rows coherent, and 'm not sure if everyone
would want to enable
Hi Galder
Sorry I'm replying so late
On Thu, May 19, 2011 at 2:02 PM, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1102
First of all thanks to Dan for his suggestion on reservoir
sampling+percentiles, very good suggestion:). So, I'm looking
in the
MarshalledValue, we could save some copying by replacing the
output.write(raw) in writeObject(ObjectOutput output,
MarshalledValue mv) by using a
output.write( byte[] , offset, length );
Cheers,
Sanne
2011/5/23 Bela Ban b...@redhat.com:
On 5/23/11 6:15 PM, Dan Berindei wrote:
I totally agree
On Mon, May 23, 2011 at 10:12 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
2011/5/23 Dan Berindei dan.berin...@gmail.com:
On Mon, May 23, 2011 at 7:44 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom
On Mon, May 23, 2011 at 11:50 PM, Bela Ban b...@redhat.com wrote:
On 5/23/11 6:44 PM, Sanne Grinovero wrote:
To keep stuff simple, I'd add an alternative feature instead:
have the custom externalizers to optionally recommend an allocation buffer
size.
In my experience people use a set of
that's the first question people ask when they start
using Infinispan.
Cheers
Dan
Cheers,
Sanne
Cheers,
On May 24, 2011, at 8:12 AM, Bela Ban wrote:
On 5/23/11 11:09 PM, Dan Berindei wrote:
No need to expose the ExposedByteArrayOutputStream, a byte[] buffer,
offset and length will do
On Tue, May 24, 2011 at 11:42 AM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
2011/5/24 Dan Berindei dan.berin...@gmail.com:
On Mon, May 23, 2011 at 8:05 PM, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
2011/5/23 이희승 (Trustin Lee) trus...@gmail.com:
On 05/23/2011 07:40 PM, Sanne
I've only got ISPN-1092 to review with Pete and some improvements
planned around ISPN-1000. Monday sounds good.
Dan
On Wed, Jun 8, 2011 at 9:08 AM, Mircea Markus mmar...@redhat.com wrote:
I'll be mainly working on perf bechmark, so no deliverables from me.
On 7 Jun 2011, at 17:19, Manik
I don't think it's an externalizer issue, as I also see some
exceptions on the node that generates state:
2011-06-09 18:16:18,250 ERROR
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(STREAMING_STATE_TRANSFER-sender-1,Infinispan-Cluster,NodeA-57902)
ISPN00095: Caught while
Hi Jeff
On Mon, Jun 20, 2011 at 10:48 AM, Jeff Ramsdale jeff.ramsd...@gmail.com wrote:
I've posted https://issues.jboss.org/browse/JBLOGGING-65 to address an
issue I've run into converting to Infinispan 5.0.0.CR5. The issue
concerns the switch to JBoss Logging and its failure to support
On Mon, Jun 20, 2011 at 11:42 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/6/20 Manik Surtani ma...@jboss.org:
Oddly enough, I don't see any other tests exhibiting this behaviour. Let me
know if you see it in more recent CI runs, and we'll investigate in detail.
In fact there are
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
just work: the API is there,
On Tue, Jul 5, 2011 at 12:49 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
After all Sanne has two use cases for atomic operations: sequences and
reference counts. Sequences can and should happen outside
transactions, but as we discussed
On Tue, Jul 5, 2011 at 12:46 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was
On Tue, Jul 5, 2011 at 1:45 PM, Sanne Grinovero sa...@infinispan.org wrote:
That's an interesting case, but I wasn't thinking about that. So it
might become useful later on.
The refcount scenario I'd like to improve first is about garbage
collection of old unused index segments,
we're
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3. cache.replace(k, v0, v1)
4. gache.get(k) - ??
With repeatable read and suspend/resume around
On Tue, Jul 5, 2011 at 4:04 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2
On Tue, Jul 5, 2011 at 7:23 PM, Vladimir Blagojevic vblag...@redhat.com wrote:
Hey guys,
In the past few days I've look around how to squeeze every bit of
performance out of BCHM and particularly our LRU impl. What I did not
like about current LRU is that a search for an element in the queue
On Tue, Jul 5, 2011 at 7:47 PM, Alex Kluge java_kl...@yahoo.com wrote:
Hi,
I have a completely in-line limit on the cache entries built on a clock
cache that is an approximation to an LRU cache, and is extremely fast
(O(1)). It is not a strick LRU, but chooses a not recently used item for
On Thu, Jul 7, 2011 at 1:21 PM, Manik Surtani ma...@jboss.org wrote:
I think we leave the old LRU as LRU_OLD and mark it as deprecated.
I for one am against keeping the old policy around, as the new LRU
policy implements exactly the same algorithm only in O(1) instead of
O(n).
It would have made
On Fri, Jul 8, 2011 at 2:53 AM, Dan Berindei dan.berin...@gmail.com wrote:
I've updated pull #414
(https://github.com/infinispan/infinispan/pull/414) to work on top of
Vladimir's pull request, in case you want to have a look. You might
want to adjust the number of keys and/or disable some
On Fri, Jul 8, 2011 at 12:44 PM, Dan Berindei dan.berin...@gmail.com wrote:
It's interesting that in the writeOnMiss test the new LRU performance
dropped when I increased the concurrency level from 32 to 128. I think
it might be because the eviction.thresholdExpired() check
On Mon, Jul 11, 2011 at 7:29 PM, Vladimir Blagojevic
vblag...@redhat.com wrote:
On 11-07-08 5:44 AM, Dan Berindei wrote:
I haven't run the tests with concurrency level 512, as the total
number of threads is only 100, but I suspect the old LRU still won't
catch up with the new LRU's
TBH I'm not sure why the patch helped with the error messages in the
log, I always thought that doing this would just replace the
IllegalStateException with an InterruptedException (since do some more
stuff after invalidation).
Of course the best solution would be to not do rehashing at all when
2011/7/14 Dan Berindei dan.berin...@gmail.com:
TBH I'm not sure why the patch helped with the error messages in the
log, I always thought that doing this would just replace the
IllegalStateException with an InterruptedException (since do some more
stuff after invalidation).
Of course the best
Hi guys
While fixing https://issues.jboss.org/browse/ISPN-1243 I found that in
certain cases state transfer will copy the in-memory data twice: first
when copying the in-memory data and then again while copying the
persistent data.
I was getting duplicate key exceptions in
On Thu, Aug 4, 2011 at 2:03 AM, Sanne Grinovero sa...@infinispan.org wrote:
2011/8/3 Dan Berindei dan.berin...@gmail.com:
I think it's supposed to be an automatic version of
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/config/GlobalConfiguration.java
Hi guys
I've found a deadlock with transactions spanning multiple caches
during rehashing if the joiner's caches are started sequentially (for
more details see https://gist.github.com/1124740)
After discussing a bit on IRC with Manik and Galderz it appears the
only solution for 5.0.0.FINAL would
On Thu, Aug 4, 2011 at 2:01 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/8/4 Dan Berindei dan.berin...@gmail.com:
Hi guys
I've found a deadlock with transactions spanning multiple caches
during rehashing if the joiner's caches are started sequentially (for
more details see https
Going back to your original question Galder, the exception is most
likely thrown because of this sequence of events:
0. Given a cluster {A, B}, a key k and a node C joining.
1. Put acquires the transaction lock on node A (blocking rehashing)
2. Put acquires lock for key k on node A
3. Rehashing
On Thu, Sep 15, 2011 at 12:25 PM, Galder Zamarreño gal...@redhat.com wrote:
On Sep 14, 2011, at 11:40 AM, Dan Berindei wrote:
Going back to your original question Galder, the exception is most
likely thrown because of this sequence of events:
0. Given a cluster {A, B}, a key k and a node C
On Wed, Sep 14, 2011 at 7:48 PM, Sanne Grinovero sa...@infinispan.org wrote:
Wouldn't the node performing the operation always do an RPC anyway iff
the intended operation is to replace a specific value?
I was thinking along the same lines, if there is no value in the
InvocationContext (L0
I've seen the same thing on Linux but a lot less often, about 4 times
in the whole test suite with DEBUG logging. I didn't see it at all
when I switched TRACE logging on.
Dan
On Mon, Sep 26, 2011 at 7:22 PM, Manik Surtani ma...@jboss.org wrote:
Guys - has anyone seen this? Happens on many
On Tue, Sep 27, 2011 at 5:59 PM, Galder Zamarreño gal...@redhat.com 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.handle() waiting for cache not only to
be
component,
and that component would have it's own mechanism for synchronizing the
last rebalanced view among cache members. So I think the 2PC
approach in CacheViewsManager actually simplifies things.
On 9/27/11 6:22 PM, Dan Berindei wrote:
Following the discussions last week I've written up a wiki
lock in exclusive mode, then releases it immediately
Shouldn't this be:
- acquire exclusive lock
- updates the pending view
- release lock
?
Right, what I meant to say is that it doesn't hold the lock for the entire
duration of the rebalance task.
On 27 Sep 2011, at 17:22, Dan Berindei
On Thu, Sep 29, 2011 at 10:01 AM, Bela Ban b...@redhat.com wrote:
On 9/28/11 1:48 PM, Dan Berindei wrote:
On Wed, Sep 28, 2011 at 12:59 PM, Bela Banb...@redhat.com wrote:
My 5 cents:
- Are you clubbing (virtual) view updates and rebalancing together ? And
if so (I should probably read
Galder, I didn't know about @Listener(sync = false), but a separate
executor makes sense for state transfer because I didn't want
concurrent state transfers and I could set it up to automatically
cancels any state transfer task that's waiting in the queue.
For the StaleTransactionCleanup I
Hi Paul
Yeah, I have changed replicated mode's state transfer to transfer
state in parallel from all the existing nodes and I'm using a
consistent hash to determine which keys should be pushed by each node.
This one looks tricky, the transport reports 0 members but it should
always have at least
On Fri, Oct 14, 2011 at 7:40 PM, Pete Muir pm...@redhat.com wrote:
What is the use case for that method? I've never know anyone actually want to
export a running config as XML. So I was planning to loose it.
It may be useful to take the configuration out of a cache configured
in AS' ISPN
like to push the Infinispan/JGroups upgrade
this week if possible, but this is currently blocking my progress.
Thanks,
Paul
On Fri, 2011-10-14 at 15:36 +0300, Dan Berindei wrote:
Hi Paul
Yeah, I have changed replicated mode's state transfer to transfer
state in parallel from all the existing
On Mon, Oct 17, 2011 at 7:51 PM, Sanne Grinovero sa...@infinispan.org wrote:
I've noticed that every time we perform a get() operation (or any
other retrieval) the value is NOT returned to the client if it's
expired, which is going to receive a null instead.
It looks like that these checks
On Tue, Oct 18, 2011 at 1:32 AM, Mircea Markus mircea.mar...@jboss.com wrote:
On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
Very interesting, I knew that in Windows currentTimeMillis() basically
just reads a volatile because I got bit by the 15 millisecond accuracy
issue before, so I
Nice!
On Tue, Oct 18, 2011 at 6:16 PM, Sanne Grinovero sa...@infinispan.org wrote:
Almost forgot the main tip; use:
git config branch.master.mergeoptions --ff-only
It will prevent a non-linear creating merge with an error as
fatal. Not possible to fast-forward, aborting.
Cheers,
Sanne
Nice writeup Galder!
On Wed, Oct 19, 2011 at 10:54 AM, Manik Surtani ma...@jboss.org wrote:
Nice one!
On 19 Oct 2011, at 08:51, Galder Zamarreño wrote:
Read all about it in http://goo.gl/C6BtO
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
but I'd first want to remove the main bottleneck.
--Sanne
On 18 October 2011 07:57, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Oct 18, 2011 at 1:32 AM, Mircea Markus mircea.mar...@jboss.com
wrote:
On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
Very interesting, I knew
David, I've upgraded to 3.1.0.Beta3 and I'm getting the same errors in
the query module:
[INFO] diagnostic error: All message bundles and message logger
messageMethods must have or inherit a message.
...
[ERROR] error on execute: error during compilation
Dan
On Mon, Oct 24, 2011 at 2:14 AM,
for those keys).
What do you think, should I discard the non-local keys with the fix
for ISPN-1470 or should I let them be and warn the user about
potentially stale data?
Cheers
Dan
On Mon, Oct 3, 2011 at 3:09 AM, Manik Surtani ma...@jboss.org wrote:
On 28 Sep 2011, at 10:56, Dan Berindei
On Mon, Oct 24, 2011 at 4:42 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 24 October 2011 12:58, Dan Berindei dan.berin...@gmail.com wrote:
Hi Galder
On Mon, Oct 24, 2011 at 1:46 PM, Galder Zamarreño gal...@redhat.com wrote:
On Oct 24, 2011, at 12:04 PM, Dan Berindei wrote:
ISPN-1470
Hi Galder, sorry it took so long to reply.
On Mon, Oct 24, 2011 at 4:16 PM, Galder Zamarreño gal...@redhat.com wrote:
Btw, forgot to attach the log:
On Oct 24, 2011, at 3:13 PM, Galder Zamarreño wrote:
Hi Dan,
Re: http://goo.gl/TGwrP
There's a few of this in the Hot Rod server+client
I was gunning for beta3 but I don't think I'm going to make it.
On Wed, Oct 26, 2011 at 12:38 PM, Galder Zamarreño gal...@redhat.com wrote:
On Oct 26, 2011, at 9:46 AM, Dan Berindei wrote:
Hi Galder, sorry it took so long to reply.
On Mon, Oct 24, 2011 at 4:16 PM, Galder Zamarreño gal
Cool link Elias, I read the paper linked in the javadoc and it's very
interesting.
Netty seems to use scheme 6 (a single array of lists with hashing and
without any overflow). I believe in general our timeouts will be much
longer so I suspect scheme 5 or scheme 7 should perform better for us.
Any pros?
On Tue, Nov 22, 2011 at 2:11 AM, Mircea Markus mircea.mar...@jboss.com wrote:
This is simple to implement and I don't see how it can cause any API
incompatibilities, but as it is in the very core I'd like to ask your opinion
- any cons for adding it into next release?
On Tue, Nov 29, 2011 at 5:09 PM, Bela Ban b...@redhat.com wrote:
On 11/29/11 3:50 PM, Galder Zamarreño wrote:
On Nov 29, 2011, at 2:23 PM, Bela Ban wrote:
On 11/29/11 2:10 PM, Galder Zamarreño wrote:
Hi,
We've been having a discussion this morning with regards to the Hot Rod
changes
On Wed, Nov 30, 2011 at 10:04 AM, Bela Ban b...@redhat.com wrote:
On 11/30/11 8:59 AM, Dan Berindei wrote:
Why don't you send the UUID as a (16 byte) string then ?
Yeah, that would work. However, a UUID is not always a valid UTF-8
string, so we should probably define it in the protocol
Sanne, I think I changed this with my fix for ISPN-1493 and now the
StateTransferLockInterceptor retries the operation (at the moment, for
up to 3 times).
Dan
On Fri, Dec 9, 2011 at 4:56 PM, Slorg1 slo...@gmail.com wrote:
Hi,
On Fri, Dec 9, 2011 at 09:53, Sanne Grinovero sa...@infinispan.org
On Tue, Dec 13, 2011 at 10:44 AM, Galder Zamarreño gal...@redhat.com wrote:
On Dec 12, 2011, at 3:45 AM, Mircea Markus wrote:
On 10 Dec 2011, at 10:04, Pete Muir wrote:
https://issues.jboss.org/browse/ISPN-1474
Currently we do a mix of:
enableXXX()
disableXXX()
enabled(boolean b)
Hi guys
For a little background, see the discussion at
https://issues.jboss.org/browse/ISPN-1586
How do you feel about discarding the contents of the cache store on all
cache (virtual) nodes except the first to start?
Configuring purgeOnStartup=true is not ok in data grid scenarios, because
I've been working on some state transfer/virtual cache view
improvements: ISPN-1606. I'll have a pull request up in an hour.
Dan
On Thu, Dec 15, 2011 at 8:58 PM, Galder Zamarreño gal...@redhat.com wrote:
On Dec 15, 2011, at 2:21 PM, Vladimir Blagojevic wrote:
If someone can deal with my
Dan, thanks for looking. So it ignores the return values: wouldn't it
be more efficient to ask the remote node to not serialize it at all in
first place?
I mean ReplicationInterceptor should send over both
Flag.SKIP_CACHE_LOAD (*not* X_LOAD) and Flag.SKIP_REMOTE_LOOKUP
on any write
I still have some state transfer failures, I was hoping to fix them by
this morning but I'm still having troubles so I might finish very late
today.
Dan
On Mon, Jan 9, 2012 at 1:39 PM, Galder Zamarreño gal...@redhat.com wrote:
Not on my side. I still need to check what 2LC looks with the fixes
Good catch Manik! I just copied the approach from
ClusteredGetResponseFilter and I didn't think too much about
performance issues.
Bela, the BitSet approach sounds a little better than a simple counter
from a debugging perspective. But I think we're also missing some
synchronization at the
On Thu, Jan 19, 2012 at 7:46 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 19 Jan 2012, at 17:36, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than
In this particular case it just means that the commit is sync even if
it's configured to be async.
But there are more places where we check the remote lock nodes list,
e.g. BaseRpcInterceptor.shouldInvokeRemotely or
AbstractEnlistmentAdapter - which, incidentally, could probably settle
with a
Hi Sanne
On Wed, Jan 25, 2012 at 1:22 AM, Sanne Grinovero sa...@infinispan.org wrote:
Hello,
in the method:
org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(Object,
InvocationContext, boolean)
we have:
ListAddress targets = locate(key);
// if any of
On Fri, Jan 27, 2012 at 2:35 PM, Mircea Markus mircea.mar...@jboss.com wrote:
I've created a JIRA to track this: https://issues.jboss.org/browse/ISPN-1801
I understand everybody has to have the exact same number of vnodes for
reads and writes to hit the correct node, right ?
Yes.
That's
On Fri, Jan 27, 2012 at 2:53 PM, Mircea Markus mircea.mar...@jboss.com wrote:
That's true, but it is not a good thing: numVirtNodes should be proportional
with the node's capacity, i.e. more powerful machines in the cluster should
have assigned more virtual nodes.
This way we can better
On Fri, Jan 27, 2012 at 3:43 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 27 Jan 2012, at 13:31, Sanne Grinovero wrote:
My experiments where using the default JVM settings regarding compile
settings, with these others:
-Xmx2G -Xms2G -XX:MaxPermSize=128M -XX:+HeapDumpOnOutOfMemoryError
Manik, Bela, I think we send the requests sequentially as well. In
ReplicationTask.call:
for (Address a : targets) {
NotifyingFutureObject f =
sendMessageWithFuture(constructMessage(buf, a), opts);
futureCollator.watchFuture(f, a);
On Fri, Jan 27, 2012 at 5:31 PM, Bela Ban b...@redhat.com wrote:
On 1/27/12 4:26 PM, Mircea Markus wrote:
On 27 Jan 2012, at 15:08, Bela Ban wrote:
Build the JGroups JAR with ./build.sh jar, *not* via maven !
I attached the JAR for you.
Thanks!
JGroups *is* and *will remain* JAR less !
Manik, I'm assigning ISPN-1801 to myself - I need to add my key
distribution test and the results anyway.
Cheers
Dan
On Mon, Jan 30, 2012 at 1:17 PM, Manik Surtani ma...@jboss.org wrote:
On 29 Jan 2012, at 14:57, Galder Zamarreño wrote:
To reiterate what I said in another thread, the memory
On Tue, Jan 31, 2012 at 4:49 PM, Bela Ban b...@redhat.com wrote:
I don't know, but I don't see why not.
If you look at java.lang.{Memory,GarbageCollector,MemoryPool}, there are
a lot of values you can look at, including the details on eden and old.
I just looked at G1 with JConsole, it does
Hi Bela
I guess it's pretty clear now... In Sanne's thread dump the main
thread is blocked in a cache.put() call after the cluster has
supposedly already formed:
org.infinispan.benchmark.Transactional.main() prio=10
tid=0x7ff4045de000 nid=0x7c92 in Object.wait()
[0x7ff40919d000]
...@jboss.org wrote:
Doesn't setBlockForResults(false) mean that we're not waiting on a response,
and can proceed to the next message to the next recipient?
On 27 Jan 2012, at 16:34, Dan Berindei wrote:
Manik, Bela, I think we send the requests sequentially as well. In
ReplicationTask.call
On Wed, Feb 1, 2012 at 9:48 AM, Bela Ban b...@redhat.com wrote:
On 1/31/12 10:55 PM, Dan Berindei wrote:
Hi Bela
I guess it's pretty clear now... In Sanne's thread dump the main
thread is blocked in a cache.put() call after the cluster has
supposedly already formed
Bela, you're right, this is essentially what we talked about in Lisbon:
https://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign
For joins I actually started working on a policy of coalescing joins
that happen one after the other in a short time interval. The current
On Wed, Feb 1, 2012 at 1:46 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 1 February 2012 11:23, Dan Berindei dan.berin...@gmail.com wrote:
Bela, you're right, this is essentially what we talked about in Lisbon:
https://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign
,
Sanne
Please ping when as soon as you've calmed down... :-)
Cheers,
On 2/1/12 4:52 PM, Sanne Grinovero wrote:
On 1 February 2012 15:18, Bela Banb...@redhat.com wrote:
On 2/1/12 10:25 AM, Dan Berindei wrote:
That's not the way it works; at startup of F, it sends its IP address
:43 PM, Manik Surtani wrote:
Is that a micro-optimisation? Do we know that socket.send() really is a
hotspot?
On 1 Feb 2012, at 00:11, Dan Berindei wrote:
It's true, but then JGroups' GroupRequest does exactly the same thing...
socket.send() takes some time too, I thought sending
On Sat, Feb 4, 2012 at 4:49 PM, Manik Surtani ma...@jboss.org wrote:
On 1 Feb 2012, at 12:23, Dan Berindei wrote:
Bela, you're right, this is essentially what we talked about in Lisbon:
https://community.jboss.org/wiki/AsymmetricCachesAndManualRehashingDesign
For joins I actually started
On Sun, Feb 5, 2012 at 12:24 PM, Bela Ban b...@redhat.com wrote:
On 2/5/12 9:44 AM, Dan Berindei wrote:
On Sat, Feb 4, 2012 at 5:23 PM, Bela Banb...@redhat.com wrote:
No, Socket.send() is not a hotspot in the Java code.
On the networking level, with UDP datagrams, a packet is placed
On Sun, Feb 5, 2012 at 5:56 PM, Bela Ban b...@redhat.com wrote:
On 2/5/12 4:40 PM, Dan Berindei wrote:
Remember that a message might be retransmitted, so it is placed into a
retransmit buffer. If M1 has destination A and M2 has destination B, and
we send M1 first (to A), then change M1's
1 - 100 of 666 matches
Mail list logo
