that's right, as suggested by Emmanuel I plan to separate the JGroups
Sync/Async options from the worker.execution property so you can play
with the two independently.
I think the JGroups option's default could depend on the backend - if
not otherwise specified, and if we all agree it doesn't make
I think we need more fine-grained config for this new JGroups sync feature.
I added this to our cache config
async
and it broke our tests.
Where previous (old / non JGroups sync) behavior worked.
It of course also works without this async config,
but in this case we do
In this particular case, there shouldn't be any other indexing going on.
Our 5 indexable caches:
"default" - Datastore
"logs" -- logging
"search" -- text search
"prospective_search" -- some weird search :-)
"tasks" -- JMS-like stuff
We disable logging for this test, and there is no Search, PSear
The index master is essentially a queue + the queue processor.
So if many people as the index master to index data (even as async).
the sync call will have to wait for all the other ones to be done before
carrying on.
But are the other put involving indexed entities? If not, then that's
not what is
To our "default" cache - which is where we store Datastore entries,
the test only does 1 put, 1 get, 1 delete, 1 query.
https://github.com/capedwarf/capedwarf-blue/blob/master/cluster-tests/src/test/java/org/jboss/test/capedwarf/cluster/test/QueryTest.java
There are other indexes that participate
No, it is one RPC call for every put or delete in the grid. I'm sure the
test makes a bunch of them.
On Fri 2013-04-12 12:40, Bela Ban wrote:
> I might have misunderstood something: if this is *one* sync RPC, then
> enabling or disabling of bundling won't have an impact; as 60ms added to
> 50 se
On 12 Apr 2013, at 11:14, Sanne Grinovero wrote:
> Thanks Israel! You're very welcome back.
>
> In mandating the types :
>
> First problem is you either change the method signature or you need to throw
> a runtime exception when the varargs array is empty.
>
> More importantly, the query tar
I might have misunderstood something: if this is *one* sync RPC, then
enabling or disabling of bundling won't have an impact; as 60ms added to
50 secs doesn't make a diff.
On 4/12/13 12:20 PM, Sanne Grinovero wrote:
> +1
> I'm going to verify that. Some index tuning options won't hurt either,
>
+1
I'm going to verify that. Some index tuning options won't hurt either, but
first I'll set the blackhole to confirm that indexing is the cause.
On Apr 12, 2013 11:12 AM, "Bela Ban" wrote:
> OK, then it isn't JGroups related. Probably some indexing work done by
> HS is on the critical path now,
> OK, then it isn't JGroups related. Probably some indexing work done by
> HS is on the critical path now, and wasn't before. The test probably
> returned before that work was done.
Yes it did -- hence we had the failing test; cache deleted the entry, where
index still had the old view.
But, i
Thanks Israel! You're very welcome back.
In mandating the types :
First problem is you either change the method signature or you need to
throw a runtime exception when the varargs array is empty.
More importantly, the query targets are supposed to be polymorphic and we
actually need the list of
OK, then it isn't JGroups related. Probably some indexing work done by
HS is on the critical path now, and wasn't before. The test probably
returned before that work was done.
On 4/12/13 11:21 AM, Ales Justin wrote:
> Still the same -- after changing this to false.
>
> 11:20:04,013 INFO
> [org
On 04/12/2013 09:43 AM, Bela Ban wrote:
> You need to set enable_bundling to *false*, not true !
>
Bela, false is the default in AS/EAP/JDG.
Tristan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/
Mandating passing in the types in SearchManager.getQuery() won't work?
On 11 Apr 2013, at 20:50, Sanne Grinovero wrote:
> That's correct. It does not affect only joiners though, there are several
> cases:
>
> - first node starting but having existing data in some CacheStore
> - node A does a
Awesome, thanks Israel.
On 12 Apr 2013, at 02:46, Israel Lacerra wrote:
> Sanne,
>
> I think I can try. Actually, I would like to continue coding in Infinispan!
> The problem is I will probably take a time to do anything (too much work).
>
> I will watch the issue on Jira. If I solve this bef
Still the same -- after changing this to false.
11:20:04,013 INFO
[org.hibernate.search.indexes.impl.DirectoryBasedIndexManager]
(http-/192.168.30.235:8080-2) HSEARCH000168: Serialization service Avro
SerializationProvider v1.0 being used for index
'default_capedwarf-test__com.google.appengin
You need to set enable_bundling to *false*, not true !
On 4/11/13 9:13 PM, Ales Justin wrote:
> Although this change fixes query lookup,
> it adds horrible performance:
>
> Running CapeDwarf cluster QueryTest:
>
> with HSEARCH-1296
>
> 21:00:27,188 INFO
> [org.hibernate.search.indexes.impl.Direc
17 matches
Mail list logo
