To our "default" cache - which is where we store Datastore entries,
the test only does 1 put, 1 get, 1 delete, 1 query.
There are other indexes that participate in this test as well, "logging" cache,
etc.
But only "default" is configured with new "sync" stuff,
others all have this:
<indexing index="LOCAL">
<property
name="hibernate.search.default.worker.execution">async</property>
So I fail to see how this is "bunch of them".
-Ales
On Apr 12, 2013, at 2:12 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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 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,
>> but first I'll set the blackhole to confirm that indexing is the cause.
>>
>> On Apr 12, 2013 11:12 AM, "Bela Ban" <bban(a)redhat.com
>> <mailto:bban@redhat.com>> wrote:
>>
>> 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.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.appengine.api.datastore.Entity'
>>> 11:20:54,730 INFO [org.jboss.web] (ServerService Thread Pool --
>> 59) JBAS018224: Unregister web context: /capedwarf-tests
>>>
>>>
>>> On Apr 12, 2013, at 9:43 AM, Bela Ban <bban(a)redhat.com
>> <mailto:bban@redhat.com>> wrote:
>>>
>>>> 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.DirectoryBasedIndexManager]
>> (http-/192.168.1.102:8080-1) HSEARCH000168: Serialization service
>> Avro SerializationProvider v1.0 being used for index
>> 'default_capedwarf-test__com.google.appengine.api.datastore.Entity'
>>>>> 21:01:17,911 INFO [org.jboss.web] (ServerService Thread Pool
>> -- 49) JBAS018224: Unregister web context: /capedwarf-tests
>>>>>
>>>>> 50sec
>>>>>
>>>>> old 4.2.0.Final HS
>>>>>
>>>>> 21:08:19,988 INFO
>> [org.hibernate.search.indexes.impl.DirectoryBasedIndexManager]
>> (http-/192.168.1.102:8080-2) HSEARCH000168: Serialization service
>> Avro SerializationProvider v1.0 being used for index
>> 'default_capedwarf-test__com.google.appengine.api.datastore.Entity'
>>>>> 21:08:20,829 INFO [org.jboss.web] (ServerService Thread Pool
>> -- 49) JBAS018224: Unregister web context: /capedwarf-tests
>>>>>
>>>>> 841ms
>>>>>
>>>>> ---
>>>>>
>>>>> I added
>>>>>
>>>>> <property
>> name="enable_bundling">true</property>
>>>>>
>>>>> to AS jgroups transport config, but no improvement.
>>>>>
>>>>> Any (other) idea?
>>>>>
>>>>> -Ales
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>> <mailto:infinispan-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>
>>>> --
>>>> Bela Ban, JGroups lead (
http://www.jgroups.org)
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>> <mailto:infinispan-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>> <mailto:infinispan-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Bela Ban, JGroups lead (
http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban, JGroups lead (
http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev