On 16 April 2013 09:51, Bela Ban b...@redhat.com 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
@Bela -- I can help you setup the whole CD env. ;-)
On Apr 15, 2013, at 7:14 AM, Bela Ban b...@redhat.com wrote:
On 4/13/13 1:42 PM, Sanne Grinovero wrote:
On 13 April 2013 11:20, Bela Ban b...@redhat.com wrote:
On 4/13/13 2:02 AM, Sanne Grinovero wrote:
@All, the performance
On Sat, Apr 13, 2013 at 3:02 AM, Sanne Grinovero sa...@hibernate.orgwrote:
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 Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 13 April 2013 11:20, Bela Ban b...@redhat.com 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:
I've attached the logs the the JIRA.
Some replies inline:
On 15 April 2013 11:04, Dan Berindei dan.berin...@gmail.com wrote:
On Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 13 April 2013 11:20, Bela Ban b...@redhat.com wrote:
On 4/13/13 2:02 AM, Sanne
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 be
On Mon, Apr 15, 2013 at 1:30 PM, Sanne Grinovero sa...@infinispan.orgwrote:
I've attached the logs the the JIRA.
Some replies inline:
On 15 April 2013 11:04, Dan Berindei dan.berin...@gmail.com wrote:
On Sat, Apr 13, 2013 at 2:42 PM, Sanne Grinovero sa...@infinispan.org
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?
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
On 4/13/13 1:42 PM, Sanne Grinovero wrote:
On 13 April 2013 11:20, Bela Ban b...@redhat.com 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
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:
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 size
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 b...@redhat.com 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 :-(
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 on
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.executionasync/property
and it broke our tests.
Where previous (old / non JGroups sync) behavior worked.
It of
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
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 ales.jus...@gmail.com wrote:
Although this change fixes query lookup,
it adds horrible performance:
Running CapeDwarf cluster QueryTest:
with
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 sa...@hibernate.org wrote:
Are you sure that the async version actually had applied all writes to the
index in the
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 sa...@hibernate.org wrote:
Are you sure that the async version actually had applied all writes to the
What do you mean?
On Apr 11, 2013, at 21:41, Sanne Grinovero sa...@hibernate.org 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 sa...@hibernate.org
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
23 matches
Mail list logo
