As I told you, we had not finished, but after 10h debugging it was
night and we still where in the office, but the ugly experiment you
see was working fine so I opted to send you a preview of the branch
for the case I would not get up early in the morning and you would
need something which worked ;
Shouldn't this "synchronous" flag still be used?
https://github.com/Sanne/hibernate-search/blob/077f29c245d2d6e960cd6ab59ff58752320d5658/hibernate-search-engine/src/main/java/org/hibernate/search/backend/impl/jgroups/DispatcherMessageSender.java#L57
e.g.
if (synchronous) {
int siz
Hmmm, did you try our QueryTest with this fix?
With HS update (your jgroupsWorkaround branch), my current run:
Running org.jboss.test.capedwarf.cluster.test.QueryTest
Tests run: 9, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 14.287 sec <<<
FAILURE!
Results :
Failed tests:
deleteAndQue
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
There is a "blackhole" indexing backend, which pipes all indexing
requests > /dev/null
Set this as an Infinispan Query configuration property:
default.worker.backend = blackhole
Of course that means that the index will not be updated: you might
need to adapt your test to tolerate that, but t
What do you mean?
On Apr 11, 2013, at 21:41, Sanne Grinovero wrote:
> You could try the new sync version but setting the blackhole backend on the
> master node to remove the indexing overhead from the picture.
> On Apr 11, 2013 8:39 PM, "Sanne Grinovero" wrote:
>> Are you sure that the async
No, not in those 800ms, hence the failing test.
But if i add 2sec sleep in between delete and query,
the test passes.
Which is still 25x better. :)
On Apr 11, 2013, at 21:39, Sanne Grinovero wrote:
> Are you sure that the async version actually had applied all writes to the
> index in the mea
You could try the new sync version but setting the blackhole backend on the
master node to remove the indexing overhead from the picture.
On Apr 11, 2013 8:39 PM, "Sanne Grinovero" wrote:
> Are you sure that the async version actually had applied all writes to the
> index in the measured interva
Are you sure that the async version actually had applied all writes to the
index in the measured interval?
On Apr 11, 2013 8:13 PM, "Ales Justin" wrote:
> Although this change fixes query lookup,
> it adds horrible performance:
>
> Running CapeDwarf cluster QueryTest:
>
> with HSEARCH-1296
>
> 2
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.DirectoryBasedIndexManager]
(http-/192.168.1.102:8080-1) HSEARCH000168: Serialization service Avro
SerializationP
11 matches
Mail list logo
