10:23 a.m.
Folks:
My co-workers and I have been using Drools to great success, but we ran smack into a
performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large numbers of
associated facts in working memory (BINNING_INPUT has more than 8 million facts in working
memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately, this rule
and a few others like it are taking FOREVER to insert. Even when I cut the number of
BINNING_INPUT facts in working memory down from 8M to 10k.
This feels like a basic Drools question. But I can't seem to find any help from
google.
Please advise!
Thanks in advance,
Dave Martin
10:27 a.m.
Oops... This e-mail went out too quickly.
There are 8M BINNING_INPUT facts that will eventually be reasoned upon... But only 10k at
a time.
In other words, the matrix of BINNING_INPUT x LU_DEVICE_TYPE should be about 10k x 10k
Dave
From: David Martin
<david.martin@mercedsystems.com<mailto:david.martin@mercedsystems.com>>
Reply-To: Rules Users List
<rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>>
Date: Mon, 19 Dec 2011 16:23:21 +0000
To: "rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>"
<rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>>
Subject: [rules-users] Poor performance from a simple join
Folks:
My co-workers and I have been using Drools to great success, but we ran smack into a
performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large numbers of
associated facts in working memory (BINNING_INPUT has more than 8 million facts in working
memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately, this rule
and a few others like it are taking FOREVER to insert. Even when I cut the number of
BINNING_INPUT facts in working memory down from 8M to 10k.
This feels like a basic Drools question. But I can't seem to find any help from
google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________ rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
10:31 a.m.
If you can write a more restrictive rules, you will be able to not
generate that 10kx10k matrix.
If you activate the log you will see 10kx10k activations that I'm sure
that it's causing the delay.
Can you write a more restrictive rule?
I'm not sure to understand this join -> $call.device_type == device_type
device_type is a constant? or is something that you get from another Pattern?
Cheers
2011/12/19 David Martin <david.martin(a)mercedsystems.com>:
Folks:
My co-workers and I have been using Drools to great success, but we ran
smack into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large
numbers of associated facts in working memory (BINNING_INPUT has more than 8
million facts in working memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately,
this rule and a few others like it are taking FOREVER to insert. Even when
I cut the number of BINNING_INPUT facts in working memory down from 8M to
10k.
This feels like a basic Drools question. But I can't seem to find any help
from google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
10:46 a.m.
Hi Mauracio!
THANK YOU!
I tried the following and things just lit up!
rule "Binning for Attribute: Device_type_desc"
when
$call : BINNING_INPUT( device_type_desc != null )
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
Why does the "guard" on the BINNING_INPUT result in such a speedup? Is the fact
being processed by the same rule over and over again? Do I need to wrap my
$call.setDevice_type_desc(...) call in a modify block?
Dave
On 12/19/11 8:31 AM, "Mauricio Salatino"
<salaboy@gmail.com<mailto:salaboy@gmail.com>> wrote:
If you can write a more restrictive rules, you will be able to not
generate that 10kx10k matrix.
If you activate the log you will see 10kx10k activations that I'm sure
that it's causing the delay.
Can you write a more restrictive rule?
I'm not sure to understand this join -> $call.device_type == device_type
device_type is a constant? or is something that you get from another Pattern?
Cheers
2011/12/19 David Martin
<david.martin@mercedsystems.com<mailto:david.martin@mercedsystems.com>>:
Folks:
My co-workers and I have been using Drools to great success, but we ran
smack into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large
numbers of associated facts in working memory (BINNING_INPUT has more than 8
million facts in working memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately,
this rule and a few others like it are taking FOREVER to insert. Even when
I cut the number of BINNING_INPUT facts in working memory down from 8M to
10k.
This feels like a basic Drools question. But I can't seem to find any help
from google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
10:35 a.m.
How is the ration of different device_type values to BINNING_INPUT facts?
-W
On 19/12/2011, David Martin <david.martin(a)mercedsystems.com> wrote:
Folks:
My co-workers and I have been using Drools to great success, but we ran
smack into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large
numbers of associated facts in working memory (BINNING_INPUT has more than 8
million facts in working memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately,
this rule and a few others like it are taking FOREVER to insert. Even when
I cut the number of BINNING_INPUT facts in working memory down from 8M to
10k.
This feels like a basic Drools question. But I can't seem to find any help
from google.
Please advise!
Thanks in advance,
Dave Martin
10:51 a.m.
Nested accessors are not currently indexed, because we cannot assure
their immutability:
$call.device_type
If people changed indexed nested accessors, without correctly notifying
the engine it would result in integrity problems.
If you have a large number of these, trying flattening the model, such
as you would do in a database.
Mark
On 19/12/2011 16:23, David Martin wrote:
Folks:
My co-workers and I have been using Drools to great success, but we
ran smack into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large
numbers of associated facts in working memory (BINNING_INPUT has more
than 8 million facts in working memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field.
Unfortunately, this rule and a few others like it are taking FOREVER
to insert. Even when I cut the number of BINNING_INPUT facts in
working memory down from 8M to 10k.
This feels like a basic Drools question. But I can't seem to find any
help from google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:58 a.m.
sorry I misread that, you've put the binding first, not using a nested
accessor.
Currently you have
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
try rewriting it as:
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( device_type == $call.device_type )
I know edson was working on making such that the order no longer
matters, I'm not sure what progress he made on that and he's away at the
moment so can't answer. It may be that he's already done that work and
it's correctly getting executed as an indexed constraint, or it might be
rewritting to an eval. Hopefully edson can answer when he gets back.
Ass Mauricio suggests, maybe you can restrict the number of instances
for BINNING_INPUT and LU_DEVICE_TYPE too.
Mark
On 19/12/2011 16:51, Mark Proctor wrote:
Nested accessors are not currently indexed, because we cannot assure
their immutability:
$call.device_type
If people changed indexed nested accessors, without correctly
notifying the engine it would result in integrity problems.
If you have a large number of these, trying flattening the model, such
as you would do in a database.
Mark
On 19/12/2011 16:23, David Martin wrote:
> Folks:
>
> My co-workers and I have been using Drools to great success, but we
> ran smack into a performance brick wall recently.
>
> In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have
> large numbers of associated facts in working memory (BINNING_INPUT
> has more than 8 million facts in working memory, LU_DEVICE_TYPE about
> 10k.)
>
> LU_DEVICE_TYPE models a lookup table.
>
> rule "Binning for Attribute: Device_type_desc"
> when
> $call :
> BINNING_INPUT()
> $device_typeLookup :
> LU_DEVICE_TYPE(
> $call.device_type == device_type
> )
>
> then
> $call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
> end
>
> It's a simple enough rule: join on the device_type field.
> Unfortunately, this rule and a few others like it are taking FOREVER
> to insert. Even when I cut the number of BINNING_INPUT facts in
> working memory down from 8M to 10k.
>
> This feels like a basic Drools question. But I can't seem to find
> any help from google.
>
> Please advise!
>
> Thanks in advance,
>
> Dave Martin
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
10:59 a.m.
On 19/12/2011 16:58, Mark Proctor wrote:
sorry I misread that, you've put the binding first, not using a
nested
accessor.
Currently you have
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
try rewriting it as:
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( device_type == $call.device_type )
I know edson was working on making such that the order no longer
matters, I'm not sure what progress he made on that and he's away at
the moment so can't answer. It may be that he's already done that work
and it's correctly getting executed as an indexed constraint, or it
might be rewritting to an eval. Hopefully edson can answer when he
gets back.
Ass Mauricio suggests, maybe you can restrict the number of instances
for BINNING_INPUT and LU_DEVICE_TYPE too.
ooops
s/Ass/As/
Mark
On 19/12/2011 16:51, Mark Proctor wrote:
> Nested accessors are not currently indexed, because we cannot assure
> their immutability:
> $call.device_type
>
> If people changed indexed nested accessors, without correctly
> notifying the engine it would result in integrity problems.
>
> If you have a large number of these, trying flattening the model,
> such as you would do in a database.
>
> Mark
> On 19/12/2011 16:23, David Martin wrote:
>> Folks:
>>
>> My co-workers and I have been using Drools to great success, but we
>> ran smack into a performance brick wall recently.
>>
>> In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have
>> large numbers of associated facts in working memory (BINNING_INPUT
>> has more than 8 million facts in working memory, LU_DEVICE_TYPE
>> about 10k.)
>>
>> LU_DEVICE_TYPE models a lookup table.
>>
>> rule "Binning for Attribute: Device_type_desc"
>> when
>> $call :
>> BINNING_INPUT()
>> $device_typeLookup :
>> LU_DEVICE_TYPE(
>> $call.device_type == device_type
>> )
>>
>> then
>> $call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
>> end
>>
>> It's a simple enough rule: join on the device_type field.
>> Unfortunately, this rule and a few others like it are taking FOREVER
>> to insert. Even when I cut the number of BINNING_INPUT facts in
>> working memory down from 8M to 10k.
>>
>> This feels like a basic Drools question. But I can't seem to find
>> any help from google.
>>
>> Please advise!
>>
>> Thanks in advance,
>>
>> Dave Martin
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
11:03 a.m.
No, Mark... You nailed it. My "guards" were reversed and my rules were no longer
matching anything.
The change you suggest below seems to do the trick though... Putting the nested accessor
first took a 90s process of 10k records down to 12s.
Phew! I will double and triple check my work now, but thanks a million! I would never
have thought swapping the order could have such a huge impact on performance.
Dave
From: Mark Proctor <mproctor@codehaus.org<mailto:mproctor@codehaus.org>>
Reply-To: Rules Users List
<rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>>
Date: Mon, 19 Dec 2011 16:59:25 +0000
To: <rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>>
Subject: Re: [rules-users] Poor performance from a simple join
On 19/12/2011 16:58, Mark Proctor wrote:
sorry I misread that, you've put the binding first, not using a nested accessor.
Currently you have
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
try rewriting it as:
$call : BINNING_INPUT()
$device_typeLookup : LU_DEVICE_TYPE( device_type == $call.device_type )
I know edson was working on making such that the order no longer matters, I'm not sure
what progress he made on that and he's away at the moment so can't answer. It may
be that he's already done that work and it's correctly getting executed as an
indexed constraint, or it might be rewritting to an eval. Hopefully edson can answer when
he gets back.
Ass Mauricio suggests, maybe you can restrict the number of instances for BINNING_INPUT
and LU_DEVICE_TYPE too.
ooops
s/Ass/As/
Mark
On 19/12/2011 16:51, Mark Proctor wrote:
Nested accessors are not currently indexed, because we cannot assure their immutability:
$call.device_type
If people changed indexed nested accessors, without correctly notifying the engine it
would result in integrity problems.
If you have a large number of these, trying flattening the model, such as you would do in
a database.
Mark
On 19/12/2011 16:23, David Martin wrote:
Folks:
My co-workers and I have been using Drools to great success, but we ran smack into a
performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large numbers of
associated facts in working memory (BINNING_INPUT has more than 8 million facts in working
memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately, this rule
and a few others like it are taking FOREVER to insert. Even when I cut the number of
BINNING_INPUT facts in working memory down from 8M to 10k.
This feels like a basic Drools question. But I can't seem to find any help from
google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________ rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
11:54 a.m.
On 19/12/2011 17:03, David Martin wrote:
No, Mark... You nailed it. My "guards" were reversed and my
rules were
no longer matching anything.
The change you suggest below seems to do the trick though... Putting
the nested accessor first took a 90s process of 10k records down to 12s.
Phew! I will double and triple check my work now, but thanks a
million! I would never have thought swapping the order could have
such a huge impact on performance.
In your case what you have there is not a nested
accessor. "device_type"
is a direct field of BINNING_INPUT. It use to be in earlier versions of
drools that fields must be to the left of the operator, and this would
have blown up. However edson has been working on improving things for
"free form" expressions, to remove artificial barriers to authoring
constraints. I suspect though that things that do not fall into the
legacy layout are written as evals, and thus you miss out on the
indexing. In short because you put $call to the left of the operator
Drools was not intelligent enough to know that this was not a variable
constraint, and it executed as an eval. We'll be improving that
intelligence over time.
M
Dave
From: Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>>
Reply-To: Rules Users List <rules-users(a)lists.jboss.org
<mailto:rules-users@lists.jboss.org>>
Date: Mon, 19 Dec 2011 16:59:25 +0000
To: <rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>>
Subject: Re: [rules-users] Poor performance from a simple join
On 19/12/2011 16:58, Mark Proctor wrote:
> sorry I misread that, you've put the binding first, not using a
> nested accessor.
>
> Currently you have
> $call : BINNING_INPUT()
> $device_typeLookup : LU_DEVICE_TYPE( $call.device_type == device_type )
>
> try rewriting it as:
> $call : BINNING_INPUT()
> $device_typeLookup : LU_DEVICE_TYPE( device_type == $call.device_type )
>
> I know edson was working on making such that the order no longer
> matters, I'm not sure what progress he made on that and he's away at
> the moment so can't answer. It may be that he's already done that
> work and it's correctly getting executed as an indexed constraint, or
> it might be rewritting to an eval. Hopefully edson can answer when he
> gets back.
>
> Ass Mauricio suggests, maybe you can restrict the number of instances
> for BINNING_INPUT and LU_DEVICE_TYPE too.
ooops
s/Ass/As/
>
> Mark
>
>
>
>
> On 19/12/2011 16:51, Mark Proctor wrote:
>> Nested accessors are not currently indexed, because we cannot assure
>> their immutability:
>> $call.device_type
>>
>> If people changed indexed nested accessors, without correctly
>> notifying the engine it would result in integrity problems.
>>
>> If you have a large number of these, trying flattening the model,
>> such as you would do in a database.
>>
>> Mark
>> On 19/12/2011 16:23, David Martin wrote:
>>> Folks:
>>>
>>> My co-workers and I have been using Drools to great success, but we
>>> ran smack into a performance brick wall recently.
>>>
>>> In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have
>>> large numbers of associated facts in working memory (BINNING_INPUT
>>> has more than 8 million facts in working memory, LU_DEVICE_TYPE
>>> about 10k.)
>>>
>>> LU_DEVICE_TYPE models a lookup table.
>>>
>>> rule "Binning for Attribute: Device_type_desc"
>>> when
>>> $call :
>>> BINNING_INPUT()
>>> $device_typeLookup :
>>> LU_DEVICE_TYPE(
>>> $call.device_type == device_type
>>> )
>>>
>>> then
>>>
>>> $call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
>>> end
>>>
>>> It's a simple enough rule: join on the device_type field.
>>> Unfortunately, this rule and a few others like it are taking
>>> FOREVER to insert. Even when I cut the number of BINNING_INPUT
>>> facts in working memory down from 8M to 10k.
>>>
>>> This feels like a basic Drools question. But I can't seem to find
>>> any help from google.
>>>
>>> Please advise!
>>>
>>> Thanks in advance,
>>>
>>> Dave Martin
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>>
rules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>>
>
_______________________________________________ rules-users mailing
list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:58 a.m.
It looks like you have a lot of objects that are not matching with
that guard (device_type_desc != null) that means that the number of
activations are less than 10k x 10k and can be processes quickly.
2011/12/19 Mark Proctor <mproctor(a)codehaus.org>:
Nested accessors are not currently indexed, because we cannot assure
their
immutability:
$call.device_type
If people changed indexed nested accessors, without correctly notifying the
engine it would result in integrity problems.
If you have a large number of these, trying flattening the model, such as
you would do in a database.
Mark
On 19/12/2011 16:23, David Martin wrote:
Folks:
My co-workers and I have been using Drools to great success, but we ran
smack into a performance brick wall recently.
In the example below, both BINNING_INPUT and LU_DEVICE_TYPE have large
numbers of associated facts in working memory (BINNING_INPUT has more than 8
million facts in working memory, LU_DEVICE_TYPE about 10k.)
LU_DEVICE_TYPE models a lookup table.
rule "Binning for Attribute: Device_type_desc"
when
$call :
BINNING_INPUT()
$device_typeLookup :
LU_DEVICE_TYPE(
$call.device_type == device_type
)
then
$call.setDevice_type_desc($device_typeLookup.getDevice_type_desc());
end
It's a simple enough rule: join on the device_type field. Unfortunately,
this rule and a few others like it are taking FOREVER to insert. Even when
I cut the number of BINNING_INPUT facts in working memory down from 8M to
10k.
This feels like a basic Drools question. But I can't seem to find any help
from google.
Please advise!
Thanks in advance,
Dave Martin
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
5218
days inactive
5218
days old
10 comments
4 participants
participants (4)
-
David Martin -
Mark Proctor -
Mauricio Salatino -
Wolfgang Laun