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
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
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
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
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
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
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
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
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
On 4/13/13 2:02 AM, Sanne Grinovero wrote:
> @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
Almost no information attached to the case :-( If it wasn't you, Sanne,
I'd outright reject the case ..
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 ;
On 13 April 2013 11:20, Bela Ban wrote:
>
>
> On 4/13/13 2:02 AM, Sanne Grinovero wrote:
>
>> @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
>
>
> Almost no information attached to the case :-( If i
> There are lots of complex moving parts in this scenario: from a Muxed
> JGroups Channel, and the Application Server responsible for
> initializing the stack with some added magic from CapeDwarf itself:
> it's not clear to me what configuration is exactly being used, for
> one.
Some quick info o
On 4/13/13 1:42 PM, Sanne Grinovero wrote:
> On 13 April 2013 11:20, Bela Ban wrote:
>>
>>
>> On 4/13/13 2:02 AM, Sanne Grinovero wrote:
>>
>>> @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
>>
@Bela -- I can help you setup the whole CD env. ;-)
On Apr 15, 2013, at 7:14 AM, Bela Ban wrote:
>
>
> On 4/13/13 1:42 PM, Sanne Grinovero wrote:
>> On 13 April 2013 11:20, Bela Ban wrote:
>>>
>>>
>>> On 4/13/13 2:02 AM, Sanne Grinovero wrote:
>>>
@All, the performance problem seemed
On Sat, Apr 13, 2013 at 3:02 AM, Sanne Grinovero 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 -
On Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero wrote:
> On 13 April 2013 11:20, Bela Ban wrote:
> >
> >
> > On 4/13/13 2:02 AM, Sanne Grinovero wrote:
> >
> >> @All, the performance problem seemed to be caused by a problem in
> >> JGroups, which I've logged here:
> >> https://issues.jboss.org/b
I've attached the logs the the JIRA.
Some replies inline:
On 15 April 2013 11:04, Dan Berindei wrote:
>
>
>
> On Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero
> wrote:
>>
>> On 13 April 2013 11:20, Bela Ban wrote:
>> >
>> >
>> > On 4/13/13 2:02 AM, Sanne Grinovero wrote:
>> >
>> >> @All, the p
>> Does CD also change the JGroups configuration? I thought it only tweaks the
>> Infinispan cache configuration on deployment, and the JGroups channel is
>> already started by the time the CD application is deployed.
>
> CD uses a custom AS build and a custom AS configuration, so anything
> could
On Mon, Apr 15, 2013 at 1:30 PM, Sanne Grinovero wrote:
> I've attached the logs the the JIRA.
>
> Some replies inline:
>
> On 15 April 2013 11:04, Dan Berindei wrote:
> >
> >
> >
> > On Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero
> > wrote:
> >>
> >> On 13 April 2013 11:20, Bela Ban wrote:
>
> Looking at your workaround, I think you actually set the response mode to
> GET_NONE (because that's the default value in RequestOptions), so you're back
> to sending an asynchronous request.
That was my question as well:
> Shouldn't this "synchronous" flag still be used?
>
> https://github.
Sorry that was the wrong branch indeed.
Ales you should be fine with this one?
https://github.com/Sanne/hibernate-search/tree/HSEARCH-1296
Many thanks to Dan :-)
Sanne
On 15 April 2013 13:44, Ales Justin wrote:
> Looking at your workaround, I think you actually set the response mode to
> GET_
Sorry for missing your message, Ales!
Anyway, good news, we found out why the test was taking so long: the
Message instance passed to dispatcher.cast() already had a destination
address set, and JGroups only sent the message to that address, even though
the dispatcher was waiting for a reply from
Nice, great job guys!
@Sanne: are you gonna apply all Dan's suggestions to that branch?
e.g. the exclusion list, etc
-Ales
On Apr 15, 2013, at 8:27 PM, Dan Berindei wrote:
> Sorry for missing your message, Ales!
>
> Anyway, good news, we found out why the test was taking so long: the Message
On 4/15/13 8:27 PM, Dan Berindei wrote:
> Sorry for missing your message, Ales!
>
> Anyway, good news, we found out why the test was taking so long: the
> Message instance passed to dispatcher.cast() already had a destination
> address set, and JGroups only sent the message to that address, even
On 16 April 2013 09:51, Bela Ban wrote:
>
>
> On 4/15/13 8:27 PM, Dan Berindei wrote:
>> Sorry for missing your message, Ales!
>>
>> Anyway, good news, we found out why the test was taking so long: the
>> Message instance passed to dispatcher.cast() already had a destination
>> address set, and JG
26 matches
Mail list logo
