Hi all,
So, in my previous update it seems I had numOwners=2, but was only
using two servers. Therefore, what I was seeing made complete sense,
actually. After changing numOwners to 1, distribution appears to work
as expected with that clusterLoader added to the config as suggested.
Thanks for
Hi James,
By specifying the LuceneCacheLoader as a loader for the default cache, it will
added to both the lucene-index (where it is needed) and the other two caches
(lucene-metadata and lucene-locks) - where I don't think it is needed. I think
it should only be configured for the lucene-index
Hi,
Thanks for the tips, but I think there will be a couple of issues:
* By mistake, I actually tried creating the lucene-metadata cache
without the loader to start with, and the Directory is unusable
without it, as it isn't able to list the index files when Lucene's
IndexReader asks for them.
On 16 Mar 2013, at 01:19, Sanne Grinovero wrote:
Hi Adrian,
let's forget about Lucene details and focus on DIST.
With numOwners=1 and having two nodes the entries should be stored
roughly 50% on each node, I see nothing wrong with that
considering you don't need data failover in a read-only
Mircea,
what I was most looking forward was to you comment on the interceptor
order generated for DIST+cachestores
- we don't think the ClusteredCacheLoader should be needed at all
- each DIST node is loading from the CacheLoader (any) rather than
loading from its peer nodes for non-owned
James, to workaround ISPN-2938
you could use preloading=true on the lucene-index cacheloader, and
preloading=false on the lucene-metadata cacheloader.
Not particularly critical, but would save you a bunch of memory.
Sanne
On 19 March 2013 14:12, Sanne Grinovero sa...@infinispan.org wrote:
Yes, please - we need to make this a priority if we intend to start on 5.3 work.
On 18 Mar 2013, at 16:50, Galder Zamarreño gal...@redhat.com wrote:
That's certainly doable, but we have the opposite problem too:
Some docu of the 5.2 is not there yet AFAIK:
- Non-blocking state transfer,
Hi James.
Strange that no one else has responded to you on this list as yet; I'm all for
reorganising the JMX names to suit Hawt.io, but not by default since it will
affect our JON/RHQ plugins.
Care to create a JIRA in Infinispan to allow a JVM system parameter to swap the
JMX name components
On 19 Mar 2013, at 15:07, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On 19 Mar 2013, at 12:21, Mircea Markus mmar...@redhat.com wrote:
On 19 Mar 2013, at 11:05, Sanne Grinovero wrote:
Does Marshalling really need to be performed in a separate thread
pool?
Hi Sanne
On Tue, Mar 19, 2013 at 4:12 PM, Sanne Grinovero sa...@infinispan.orgwrote:
Mircea,
what I was most looking forward was to you comment on the interceptor
order generated for DIST+cachestores
- we don't think the ClusteredCacheLoader should be needed at all
Agree,
And will conditional operations on byte[] work as well within this fix? I have
just noticed that in library mode I can't use remove with byte[] value (should
I file a feature request JIRA for that?)
Radim
- Original Message -
| From: Tristan Tarrant ttarr...@redhat.com
| To: infinispan
On 19 Mar 2013, at 16:15, Dan Berindei wrote:
Hi Sanne
On Tue, Mar 19, 2013 at 4:12 PM, Sanne Grinovero sa...@infinispan.org wrote:
Mircea,
what I was most looking forward was to you comment on the interceptor
order generated for DIST+cachestores
- we don't think the
On Tue, Mar 19, 2013 at 5:17 PM, Manik Surtani msurt...@redhat.com wrote:
On 19 Mar 2013, at 15:07, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On 19 Mar 2013, at 12:21, Mircea Markus mmar...@redhat.com wrote:
On 19 Mar 2013, at 11:05, Sanne Grinovero
Implementation-wise, just changing the interceptor order is probably not
enough. If the key doesn't exist in the cache, the CacheLoaderInterceptor
will still try to load it from the cache store after the remote lookup, so
we'll need a marker in the invocation context to avoid the extra
This is an invalid use of the MBean names.
The keys in an ObjectName are unordered. It is a bug to depend on a
specific ordering of the keys.
-Dennis
On 03/19/2013 10:07 AM, Manik Surtani wrote:
Hi James.
Strange that no one else has responded to you on this list as yet; I'm all
for
On 19 Mar 2013, at 17:38, Dan Berindei wrote:
Implementation-wise, just changing the interceptor order is probably not
enough. If the key doesn't exist in the cache, the CacheLoaderInterceptor
will still try to load it from the cache store after the remote lookup, so
we'll need a
On 19 Mar 2013, at 15:17, Manik Surtani wrote:
On 19 Mar 2013, at 15:07, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On 19 Mar 2013, at 12:21, Mircea Markus mmar...@redhat.com wrote:
On 19 Mar 2013, at 11:05, Sanne Grinovero wrote:
Does Marshalling
On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
Hi all,
A heads up on what is going on with https://issues.jboss.org/browse/ISPN-2281
While discussing this, Tristan and I came to the conclusion that we could
avoid the need to create some wrappers required to fulfill requirements in
On 18 Mar 2013, at 16:50, Galder Zamarreño wrote:
That's certainly doable, but we have the opposite problem too:
Some docu of the 5.2 is not there yet AFAIK:
- Non-blocking state transfer, segments…
Adrian is working on this right now.
- Is x-site replication docu there? I don't mean
On Mon, Mar 18, 2013 at 6:09 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi all,
To solve ISPN-2808 (avoid blocking JGroups threads in order to allow to
deliver the request responses), I've created another thread pool to move
the possible blocking commands (i.e. the commands that may block
* Marshalling happens in the async thread (the same one that puts the
message on the wire) rather than in the caller's thread
my understanding is that there's no such additional thread, but caller's
thread goes to the network stack even for async calls. I think Bela can put
some light on
On 18 Mar 2013, at 16:09, Pedro Ruivo wrote:
Hi all,
To solve ISPN-2808 (avoid blocking JGroups threads in order to allow to
deliver the request responses), I've created another thread pool to move
the possible blocking commands (i.e. the commands that may block until
some state is
On 19 Mar 2013, at 20:58, Dan Berindei wrote:
* Marshalling happens in the async thread (the same one that puts the
message on the wire) rather than in the caller's thread
my understanding is that there's no such additional thread, but caller's
thread goes to the network stack even for
On 03/19/2013 08:41 PM, Dan Berindei wrote:
On Mon, Mar 18, 2013 at 6:09 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
Hi all,
To solve ISPN-2808 (avoid blocking JGroups threads in order to allow to
deliver the request responses), I've created
On 03/19/2013 09:01 PM, Mircea Markus wrote:
On 18 Mar 2013, at 16:09, Pedro Ruivo wrote:
Hi all,
To solve ISPN-2808 (avoid blocking JGroups threads in order to allow to
deliver the request responses), I've created another thread pool to move
the possible blocking commands (i.e. the
yes :)
On 03/18/2013 06:51 PM, Erik Salter wrote:
Hi Pedro,
May I steal this implementation for improving xsite replication? =)
Erik
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Pedro Ruivo
Sent:
Any idea how this can happen?
01:06:36,722 ERROR [org.infinispan.interceptors.InvocationContextInterceptor]
(http-/127.0.0.1:8080-2) ISPN000136: Execution error:
java.lang.IllegalStateException: Entries cannot have null versions!
at
27 matches
Mail list logo
