Re: [hibernate-dev] HSEARCH-1296

2013-04-13 Thread Sanne Grinovero
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 ;

Re: [hibernate-dev] HSEARCH-1296

2013-04-13 Thread Ales Justin
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-13 Thread Ales Justin
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-12 Thread Sanne Grinovero
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-12 Thread Ales Justin
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-11 Thread Sanne Grinovero
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-11 Thread Ales Justin
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-11 Thread Ales Justin
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-11 Thread Sanne Grinovero
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

Re: [hibernate-dev] HSEARCH-1296

2013-04-11 Thread Sanne Grinovero
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