[infinispan-dev] HSEARCH-1296

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] HSEARCH-1296

Ales Justin
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Sanne Grinovero-2

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" <[hidden email]> 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


_______________________________________________
hibernate-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/hibernate-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Sanne Grinovero-2

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" <[hidden email]> wrote:

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" <[hidden email]> 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


_______________________________________________
hibernate-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/hibernate-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Ales Justin
In reply to this post by Sanne Grinovero-2
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 <[hidden email]> wrote:

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" <[hidden email]> 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


_______________________________________________
hibernate-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/hibernate-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Ales Justin
In reply to this post by Sanne Grinovero-2
What do you mean?

On Apr 11, 2013, at 21:41, Sanne Grinovero <[hidden email]> 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" <[hidden email]> wrote:

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" <[hidden email]> 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


_______________________________________________
hibernate-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/hibernate-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Sanne Grinovero-2
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 the point is not
functional testing but to verify how much the SYNC option on the
JGroups backend is actually slowing you down. I suspect the
performance penalty is not in the network but in the fact you're now
waiting for the index operations, while in async you where not waiting
for them to be flushed.

If you can identify which part is slow, then we can help you with
better configuration options.


On 11 April 2013 20:47, Ales Justin <[hidden email]> wrote:

> What do you mean?
>
> On Apr 11, 2013, at 21:41, Sanne Grinovero <[hidden email]> 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" <[hidden email]> wrote:
>>
>> 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" <[hidden email]> 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
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Bela Ban
In reply to this post by Ales Justin
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Ales Justin
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Tristan Tarrant-2
In reply to this post by Bela Ban
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Bela Ban
In reply to this post by Ales Justin
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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Ales Justin
> 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, if I add 2sec sleep between delete and query, it works.
Which makes me wonder why the additional 48sec, for something that works in ~2sec.

-Ales

> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Bela Ban, JGroups lead (http://www.jgroups.org)
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Sanne Grinovero-3
In reply to this post by Bela Ban

+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" <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Bela Ban
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" <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>      >>> [hidden email]
>     <mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>>
>      >>
>      >> --
>      >> Bela Ban, JGroups lead (http://www.jgroups.org)
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Bela Ban, JGroups lead (http://www.jgroups.org)
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Emmanuel Bernard
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" <[hidden email]
> > <mailto:[hidden email]>> 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 <[hidden email]
> >     <mailto:[hidden email]>> 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
> >      >>> [hidden email]
> >     <mailto:[hidden email]>
> >      >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >      >>>
> >      >>
> >      >> --
> >      >> Bela Ban, JGroups lead (http://www.jgroups.org)
> >      >> _______________________________________________
> >      >> infinispan-dev mailing list
> >      >> [hidden email]
> >     <mailto:[hidden email]>
> >      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >      >
> >      >
> >      > _______________________________________________
> >      > infinispan-dev mailing list
> >      > [hidden email]
> >     <mailto:[hidden email]>
> >      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >      >
> >
> >     --
> >     Bela Ban, JGroups lead (http://www.jgroups.org)
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     [hidden email] <mailto:[hidden email]>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Ales Justin
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 <[hidden email]> 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" <[hidden email]
<[hidden email]>> 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 <[hidden email]
   <[hidden email]>> 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
[hidden email]
   <[hidden email]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
   <[hidden email]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
   <[hidden email]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev


   --
   Bela Ban, JGroups lead (http://www.jgroups.org)
   _______________________________________________
   infinispan-dev mailing list
   [hidden email] <[hidden email]>
   https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Emmanuel Bernard
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 going on.

I can't explain one index operation taking 50s if nothing is happening
in parallel.
As Sanne said, use the blackhole backend on your index master node. We
will know if the index is really taking all that time.

Emmanuel

On Fri 2013-04-12 14:19, Ales Justin wrote:

> 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 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 <[hidden email]> 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" <[hidden email]
> >>> <mailto:[hidden email]>> 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 <[hidden email]
> >>>    <mailto:[hidden email]>> 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
> >>>>>> [hidden email]
> >>>    <mailto:[hidden email]>
> >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Bela Ban, JGroups lead (http://www.jgroups.org)
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> [hidden email]
> >>>    <mailto:[hidden email]>
> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> [hidden email]
> >>>    <mailto:[hidden email]>
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>
> >>>    --
> >>>    Bela Ban, JGroups lead (http://www.jgroups.org)
> >>>    _______________________________________________
> >>>    infinispan-dev mailing list
> >>>    [hidden email] <mailto:[hidden email]>
> >>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>
> >> --
> >> Bela Ban, JGroups lead (http://www.jgroups.org)
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] HSEARCH-1296

Ales Justin
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, PSearch or Queue taking place.

Hence the only ops should be those 4 ops to "default" cache.

We did see huge perf drop when trace logging is enabled,
and that wouldn't surprise me then, but that's not the case here.

But 4 ops, for 50sec ...

On Apr 12, 2013, at 2:41 PM, Emmanuel Bernard <[hidden email]> wrote:

> 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 going on.
>
> I can't explain one index operation taking 50s if nothing is happening
> in parallel.
> As Sanne said, use the blackhole backend on your index master node. We
> will know if the index is really taking all that time.
>
> Emmanuel
>
> On Fri 2013-04-12 14:19, Ales Justin wrote:
>> 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 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 <[hidden email]> 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" <[hidden email]
>>>>> <mailto:[hidden email]>> 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 <[hidden email]
>>>>>   <mailto:[hidden email]>> 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
>>>>>>>> [hidden email]
>>>>>   <mailto:[hidden email]>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bela Ban, JGroups lead (http://www.jgroups.org)
>>>>>>> _______________________________________________
>>>>>>> infinispan-dev mailing list
>>>>>>> [hidden email]
>>>>>   <mailto:[hidden email]>
>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>>>>   <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>
>>>>>   --
>>>>>   Bela Ban, JGroups lead (http://www.jgroups.org)
>>>>>   _______________________________________________
>>>>>   infinispan-dev mailing list
>>>>>   [hidden email] <mailto:[hidden email]>
>>>>>   https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>
>>>> --
>>>> Bela Ban, JGroups lead (http://www.jgroups.org)
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Ales Justin
In reply to this post by Sanne Grinovero-2
I think we need more fine-grained config for this new JGroups sync feature.

I added this to our cache config

                        <property name="hibernate.search.default.worker.execution">async</property>

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 don't need sync / ACK JGroups message.
(we didn't have one before and it worked ;-)

-Ales

On Apr 11, 2013, at 11:51 PM, Sanne Grinovero <[hidden email]> wrote:

> 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 the point is not
> functional testing but to verify how much the SYNC option on the
> JGroups backend is actually slowing you down. I suspect the
> performance penalty is not in the network but in the fact you're now
> waiting for the index operations, while in async you where not waiting
> for them to be flushed.
>
> If you can identify which part is slow, then we can help you with
> better configuration options.
>
>
> On 11 April 2013 20:47, Ales Justin <[hidden email]> wrote:
>> What do you mean?
>>
>> On Apr 11, 2013, at 21:41, Sanne Grinovero <[hidden email]> 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" <[hidden email]> wrote:
>>>
>>> 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" <[hidden email]> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

Sanne Grinovero-2
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 it too
confusing.

@All, the performance problem seemed to be caused by a problem in
JGroups, which I've logged here:
https://issues.jboss.org/browse/JGRP-1617

For the record, the first operation was indeed triggering some lazy
initialization of indexes, which in turn would trigger a Lucene
Directory being started, triggering 3 Cache starts which in turn would
trigger 6 state transfer processes: so indeed the first operation
would not be exactly "cheap" performance wise, still this would
complete in about 120 milliseconds.
The same cost is paid again when the second node is hit the first
time, after that index write operations block the writer for <1ms (not
investigated further on potential throughput).

Not being sure about the options of depending to a newer JGroups
release or the complexity of a fix, I'll implement a workaround in
HSearch in the scope of HSEARCH-1296.

As a lesson learned, I think we need to polish some of our TRACE level
messaged to include the cache name: to resolve this we had not just
many threads and components but also 4 of them where using JGroups
(interleaving messages of all sorts) and 9 different caches where
involved for each simple write operation in CD: made it interesting to
figure what was going on! Also I'm wondering how hard it would be to
have a log parser which converts my 10GB of text log from today in a
graphical sequence diagram.
Big thanks to Mircea who helped me figuring this out.

Sanne

On 12 April 2013 21:10, Ales Justin <[hidden email]> wrote:

> I think we need more fine-grained config for this new JGroups sync feature.
>
> I added this to our cache config
>
>                         <property name="hibernate.search.default.worker.execution">async</property>
>
> 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 don't need sync / ACK JGroups message.
> (we didn't have one before and it worked ;-)
>
> -Ales
>
> On Apr 11, 2013, at 11:51 PM, Sanne Grinovero <[hidden email]> wrote:
>
>> 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 the point is not
>> functional testing but to verify how much the SYNC option on the
>> JGroups backend is actually slowing you down. I suspect the
>> performance penalty is not in the network but in the fact you're now
>> waiting for the index operations, while in async you where not waiting
>> for them to be flushed.
>>
>> If you can identify which part is slow, then we can help you with
>> better configuration options.
>>
>>
>> On 11 April 2013 20:47, Ales Justin <[hidden email]> wrote:
>>> What do you mean?
>>>
>>> On Apr 11, 2013, at 21:41, Sanne Grinovero <[hidden email]> 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" <[hidden email]> wrote:
>>>>
>>>> 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" <[hidden email]> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] [hibernate-dev] HSEARCH-1296

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:   deleteAndQueryInA(org.jboss.test.capedwarf.cluster.test.QueryTest): Should not be here: null
  deleteAndQueryInA_2(org.jboss.test.capedwarf.cluster.test.QueryTest): Should not be here: null

-Ales

On Apr 13, 2013, at 2:02 AM, Sanne Grinovero <[hidden email]> wrote:

> 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 it too
> confusing.
>
> @All, the performance problem seemed to be caused by a problem in
> JGroups, which I've logged here:
> https://issues.jboss.org/browse/JGRP-1617
>
> For the record, the first operation was indeed triggering some lazy
> initialization of indexes, which in turn would trigger a Lucene
> Directory being started, triggering 3 Cache starts which in turn would
> trigger 6 state transfer processes: so indeed the first operation
> would not be exactly "cheap" performance wise, still this would
> complete in about 120 milliseconds.
> The same cost is paid again when the second node is hit the first
> time, after that index write operations block the writer for <1ms (not
> investigated further on potential throughput).
>
> Not being sure about the options of depending to a newer JGroups
> release or the complexity of a fix, I'll implement a workaround in
> HSearch in the scope of HSEARCH-1296.
>
> As a lesson learned, I think we need to polish some of our TRACE level
> messaged to include the cache name: to resolve this we had not just
> many threads and components but also 4 of them where using JGroups
> (interleaving messages of all sorts) and 9 different caches where
> involved for each simple write operation in CD: made it interesting to
> figure what was going on! Also I'm wondering how hard it would be to
> have a log parser which converts my 10GB of text log from today in a
> graphical sequence diagram.
> Big thanks to Mircea who helped me figuring this out.
>
> Sanne
>
> On 12 April 2013 21:10, Ales Justin <[hidden email]> wrote:
>> I think we need more fine-grained config for this new JGroups sync feature.
>>
>> I added this to our cache config
>>
>>                        <property name="hibernate.search.default.worker.execution">async</property>
>>
>> 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 don't need sync / ACK JGroups message.
>> (we didn't have one before and it worked ;-)
>>
>> -Ales
>>
>> On Apr 11, 2013, at 11:51 PM, Sanne Grinovero <[hidden email]> wrote:
>>
>>> 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 the point is not
>>> functional testing but to verify how much the SYNC option on the
>>> JGroups backend is actually slowing you down. I suspect the
>>> performance penalty is not in the network but in the fact you're now
>>> waiting for the index operations, while in async you where not waiting
>>> for them to be flushed.
>>>
>>> If you can identify which part is slow, then we can help you with
>>> better configuration options.
>>>
>>>
>>> On 11 April 2013 20:47, Ales Justin <[hidden email]> wrote:
>>>> What do you mean?
>>>>
>>>> On Apr 11, 2013, at 21:41, Sanne Grinovero <[hidden email]> 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" <[hidden email]> wrote:
>>>>>
>>>>> 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" <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12