5:04 p.m.
Hello; I am aware of the fundamental difference between inserting facts--and
evaluating them against all the rules in the rule base--and firing
rules--i.e., executing only certain rules' consequences.
I understand that ruleflow-group and agenda-group and activation-group can
all be employed to govern which rules' consequences are fired at
fireAllRules() time.
My question (which has been asked by many others in different ways, yet not
answered as far as I can tell on the mailing list to anyone's satisfaction)
is: is there any construct that can be used when it is known up front that
only certain rules will match? That is, is there any way to limit rule
evaluation?
For example, I have a series of surveys that all use the same KnowledgeBase
to govern the flow of the user through the survey. But once I've asked a
given question, then I know right then and there which rules have a chance
of taking effect.
I've already put them in their own agenda-group, and I already switch focus
to that agenda group prior to fact insertion, so that by the time I call
fireAllRules() I've made it so that--say--ten rules' consequences are the
only ones (out of hundreds) that could possibly fire in this given session.
But unless I'm radically misunderstanding something, each time I insert a
fact, it is evaluated against all the hundreds of rules, even when several
hundred of those rules don't have any chance of having their consequences
firing.
I even understand (I think) why this is. If I were, for example, to
subsequently pop the agenda group that I had set focus to, then "MAIN" would
be selected, and for those activations to fire the inserted fact would have
had to have been evaluated against all the rules, including those whose
agenda group is "MAIN".
But I guess what I'm wondering is: can I somehow turn this off? Can I, in
other words, partition the KnowledgeBase itself? Can I effectively tell
Drools, during this stateless session, don't even bother trying to match
facts against rules 1-10, just try rules 11-14?
Thanks,
Laird
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluat...
Sent from the Drools - User mailing list archive at Nabble.com.
7:31 a.m.
Hi,
Having the same questions you had, I played a bit with agenda-groups to see
if there was any notable performance effect.
I added 200 extra rules which did not fire at all and did two "series" of
rule executions. Once with all rules within the same agenda-group and once
with the 200 extra rules in a different agenda-group, while setting focus to
the firing rules. Allthough I cannot claim statistical significance, I
didn't notice big effects.
As I consider it, the reason for still evaluating all rules is because you
would need an Update() statement everytime focus is switched to an other
agenda-group to make sure Objects are matched to those rules.
Maybe ruleflow-groups work a bit different - allthough I doubt it - but I
haven't played with them yet.
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluat...
Sent from the Drools - User mailing list archive at Nabble.com.
8:20 a.m.
The algorithm as is does eager evaluation, as for the general case that
is still better than doing selective evaluation.
If, in your case, the decision of which rules to fire is an arbitrary
application decision, and not based on the actual constraints of the rules
themselves, then the only way would be by creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it
effectively disables all the beta evaluations for rules of phases other than
the current one. Just be aware that by blocking the eager evaluation this
way, phase switches are heavier than without the control fact, where most
constraints were already previously evaluated. Obvious, but worth saying out
loud... :)
There is also a feature that Leonardo is working on that makes the engine
automatically unlink and relink parts of the network, based on the existence
and possibility of matching the other required facts in a rule LHS. It might
achieve similar results to what you are looking for in some cases, but that
is totally based on the constraints in there and not on any arbitrary
application decision.
Edson
2011/3/21 FrankVhh <frank.vanhoenshoven(a)agserv.eu>
Hi,
Having the same questions you had, I played a bit with agenda-groups to see
if there was any notable performance effect.
I added 200 extra rules which did not fire at all and did two "series" of
rule executions. Once with all rules within the same agenda-group and once
with the 200 extra rules in a different agenda-group, while setting focus
to
the firing rules. Allthough I cannot claim statistical significance, I
didn't notice big effects.
As I consider it, the reason for still evaluating all rules is because you
would need an Update() statement everytime focus is switched to an other
agenda-group to make sure Objects are matched to those rules.
Maybe ruleflow-groups work a bit different - allthough I doubt it - but I
haven't played with them yet.
Regards,
Frank
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluat...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
8:33 a.m.
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group behaves
like an agenda filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation for node
that does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case
that is still better than doing selective evaluation.
If, in your case, the decision of which rules to fire is an
arbitrary application decision, and not based on the actual
constraints of the rules themselves, then the only way would be by
creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it
effectively disables all the beta evaluations for rules of phases
other than the current one. Just be aware that by blocking the eager
evaluation this way, phase switches are heavier than without the
control fact, where most constraints were already previously
evaluated. Obvious, but worth saying out loud... :)
There is also a feature that Leonardo is working on that makes the
engine automatically unlink and relink parts of the network, based on
the existence and possibility of matching the other required facts in
a rule LHS. It might achieve similar results to what you are looking
for in some cases, but that is totally based on the constraints in
there and not on any arbitrary application decision.
Edson
8:37 a.m.
The thing to remember is that fact evaluation occurs at object insert/update time, not at
the point you call fireAllRules. Salience, Agenda and rufeflow control on the other hand
are runtime conditions which control which rules are actually activated in what order.
Thomas
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Vincent Legendre
Sent: 21 March 2011 13:34
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group behaves like an agenda
filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation for node that
does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case that is still better
than doing selective evaluation.
If, in your case, the decision of which rules to fire is an arbitrary application
decision, and not based on the actual constraints of the rules themselves, then the only
way would be by creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it effectively disables
all the beta evaluations for rules of phases other than the current one. Just be aware
that by blocking the eager evaluation this way, phase switches are heavier than without
the control fact, where most constraints were already previously evaluated. Obvious, but
worth saying out loud... :)
There is also a feature that Leonardo is working on that makes the engine automatically
unlink and relink parts of the network, based on the existence and possibility of matching
the other required facts in a rule LHS. It might achieve similar results to what you are
looking for in some cases, but that is totally based on the constraints in there and not
on any arbitrary application decision.
Edson
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
8:47 a.m.
ok.
So the only way to do that is to add a control fact, and update it at
runtime...
Do you think that using the "control fact" method will speed up the
execution time for a large ruleset that have different ruleflow-group ?
My feeling is yes, especially if "first" rules does many updates, but I
haven't done any tests.
Le 21/03/2011 14:37, Swindells, Thomas a écrit :
The thing to remember is that fact evaluation occurs at object
insert/update time, not at the point you call fireAllRules. Salience,
Agenda and rufeflow control on the other hand are runtime conditions
which control which rules are actually activated in what order.
Thomas
*From:*rules-users-bounces@lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] *On Behalf Of *Vincent
Legendre
*Sent:* 21 March 2011 13:34
*To:* Rules Users List
*Subject:* Re: [rules-users] Limiting rule evaluation--not firing
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group
behaves like an agenda filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation for
node that does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case
that is still better than doing selective evaluation.
If, in your case, the decision of which rules to fire is an
arbitrary application decision, and not based on the actual
constraints of the rules themselves, then the only way would be by
creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it
effectively disables all the beta evaluations for rules of phases
other than the current one. Just be aware that by blocking the eager
evaluation this way, phase switches are heavier than without the
control fact, where most constraints were already previously
evaluated. Obvious, but worth saying out loud... :)
There is also a feature that Leonardo is working on that makes the
engine automatically unlink and relink parts of the network, based on
the existence and possibility of matching the other required facts in
a rule LHS. It might achieve similar results to what you are looking
for in some cases, but that is totally based on the constraints in
there and not on any arbitrary application decision.
Edson
------------------------------------------------------------------------
**************************************************************************************
This message is confidential and intended only for the addressee. If
you have received this message in error, please immediately notify the
postmaster(a)nds.com and delete it from your system as well as any
copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the
environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex,
TW18 4EX, United Kingdom. A company registered in England and Wales.
Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:25 a.m.
That's probably the best way to go. I think it's a case of experimentation to work
out what runs best (and please report your results). Things to consider are what order you
have the conditions in the rules (the control fact first is probably most efficient but
may be worth comparing with it at the end) and the order you insert facts - do you insert
the control fact first or last.
Thomas
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Vincent Legendre
Sent: 21 March 2011 13:47
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
ok.
So the only way to do that is to add a control fact, and update it at runtime...
Do you think that using the "control fact" method will speed up the execution
time for a large ruleset that have different ruleflow-group ?
My feeling is yes, especially if "first" rules does many updates, but I
haven't done any tests.
Le 21/03/2011 14:37, Swindells, Thomas a écrit :
The thing to remember is that fact evaluation occurs at object insert/update time, not at
the point you call fireAllRules. Salience, Agenda and rufeflow control on the other hand
are runtime conditions which control which rules are actually activated in what order.
Thomas
From:
rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent Legendre
Sent: 21 March 2011 13:34
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group behaves like an agenda
filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation for node that
does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case that is still better
than doing selective evaluation.
If, in your case, the decision of which rules to fire is an arbitrary application
decision, and not based on the actual constraints of the rules themselves, then the only
way would be by creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it effectively disables
all the beta evaluations for rules of phases other than the current one. Just be aware
that by blocking the eager evaluation this way, phase switches are heavier than without
the control fact, where most constraints were already previously evaluated. Obvious, but
worth saying out loud... :)
There is also a feature that Leonardo is working on that makes the engine automatically
unlink and relink parts of the network, based on the existence and possibility of matching
the other required facts in a rule LHS. It might achieve similar results to what you are
looking for in some cases, but that is totally based on the constraints in there and not
on any arbitrary application decision.
Edson
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the
postmaster@nds.com<mailto:postmaster@nds.com> and delete it from your system as well
as any copies. The content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not print this
e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
9:34 a.m.
Given that facts (after some common initial processing) fall into two or
more classes that should be processed with significantly different (although
not necessarily disjoint) sets of rules and also given that the fact and/or
rule number is prohibitive for processing according to the simple design
pattern of throwing it all into one basket:--
Why not create two (or more) different rule bases and spawn a session from
each? Initial processing could be done with an additional (simple) engine,
with the other sessions being provided via some global, as a service, ready
to accept the classified facts.
True, there will be some overhead, but it's a clean solution, doesn't mess
up the rules with control facts and you get exactly those rules to work on
your facts you put into the different K-bases.
-W
10:06 a.m.
Hi all,
This is a very interesting discussion, so I re-read the Drools Flow manual.
IN section 8.1, it is stated as one of the reasons to use rules in your
process:
Performance: Rule evaluation is optimized.
How do I have to understand this? Does rule evaluation only happens for the
rules that are in the current ruleflowgroup? Because the above conversation
seems to imply it isn't.
Regards,
Frank
Swindells, Thomas wrote:
That's probably the best way to go. I think it's a case of experimentation
to work out what runs best (and please report your results). Things to
consider are what order you have the conditions in the rules (the control
fact first is probably most efficient but may be worth comparing with it
at the end) and the order you insert facts - do you insert the control
fact first or last.
Thomas
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent Legendre
Sent: 21 March 2011 13:47
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
ok.
So the only way to do that is to add a control fact, and update it at
runtime...
Do you think that using the "control fact" method will speed up
the execution time for a large ruleset that have different ruleflow-group
?
My feeling is yes, especially if "first" rules does many
updates, but I haven't done any tests.
Le 21/03/2011 14:37, Swindells, Thomas a écrit :
The thing to remember is that fact evaluation occurs at object
insert/update time, not at the point you call fireAllRules. Salience,
Agenda and rufeflow control on the other hand are runtime conditions which
control which rules are actually activated in what order.
Thomas
From:
rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent Legendre
Sent: 21 March 2011 13:34
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group behaves
like an agenda filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation
for node that does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case that
is still better than doing selective evaluation.
If, in your case, the decision of which rules to fire is an arbitrary
application decision, and not based on the actual constraints of the rules
themselves, then the only way would be by creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it
effectively disables all the beta evaluations for rules of phases other
than the current one. Just be aware that by blocking the eager evaluation
this way, phase switches are heavier than without the control fact, where
most constraints were already previously evaluated. Obvious, but worth
saying out loud... :)
There is also a feature that Leonardo is working on that makes the
engine automatically unlink and relink parts of the network, based on the
existence and possibility of matching the other required facts in a rule
LHS. It might achieve similar results to what you are looking for in some
cases, but that is totally based on the constraints in there and not on
any arbitrary application decision.
Edson
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you
have received this message in error, please immediately notify the
postmaster@nds.com<mailto:postmaster@nds.com> and delete it from
your system as well as any copies. The content of e-mails as well as
traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless
necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
4EX, United Kingdom. A company registered in England and Wales. Registered
no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluat...
Sent from the Drools - User mailing list archive at Nabble.com.
11:26 a.m.
All,
Please let me re-emphasize something from my e-mail: "for the general
case [eager evaluation] is still better than doing selective evaluation".
Unless you are having performance problems for your specific use case, you
should not be worrying about this, as the engine is optimized for the
general use case.
If you *are* having performance problems, then there is a number of
possible factors that need to be analyzed, one of which is the possible use
of control facts to prevent beta evaluation. So, don't think that control
facts are a general solution that will work for everybody... it is quite the
opposite, control facts are only worth for a minority of very specific
cases, because depending on your situation, it might be very costly to do
the phase switch on a control fact.
Regarding the question on the rule-flow optimizations, there are
optimizations there... for instance, activations don't go into the main
agenda until the rule-flow group is activated, and it is usually much
cheaper to maintain activations in the separate groups than it is to
maintain them on the main agenda...
Edson
2011/3/21 FrankVhh <frank.vanhoenshoven(a)agserv.eu>
Hi all,
This is a very interesting discussion, so I re-read the Drools Flow manual.
IN section 8.1, it is stated as one of the reasons to use rules in your
process:
Performance: Rule evaluation is optimized.
How do I have to understand this? Does rule evaluation only happens for the
rules that are in the current ruleflowgroup? Because the above conversation
seems to imply it isn't.
Regards,
Frank
Swindells, Thomas wrote:
>
> That's probably the best way to go. I think it's a case of
experimentation
> to work out what runs best (and please report your results). Things to
> consider are what order you have the conditions in the rules (the control
> fact first is probably most efficient but may be worth comparing with it
> at the end) and the order you insert facts - do you insert the control
> fact first or last.
>
> Thomas
>
> From: rules-users-bounces(a)lists.jboss.org
> [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent
Legendre
> Sent: 21 March 2011 13:47
> To: Rules Users List
> Subject: Re: [rules-users] Limiting rule evaluation--not firing
>
> ok.
> So the only way to do that is to add a control fact, and update it at
> runtime...
> Do you think that using the "control fact" method will speed up
> the execution time for a large ruleset that have different ruleflow-group
> ?
> My feeling is yes, especially if "first" rules does many
> updates, but I haven't done any tests.
>
> Le 21/03/2011 14:37, Swindells, Thomas a écrit :
> The thing to remember is that fact evaluation occurs at object
> insert/update time, not at the point you call fireAllRules. Salience,
> Agenda and rufeflow control on the other hand are runtime conditions
which
> control which rules are actually activated in what order.
>
> Thomas
>
> From:
> rules-users-bounces(a)lists.jboss.org&lt;mailto:
rules-users-bounces(a)lists.jboss.org&gt;
> [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent
Legendre
> Sent: 21 March 2011 13:34
> To: Rules Users List
> Subject: Re: [rules-users] Limiting rule evaluation--not firing
>
> And what about ruleflow-group ?
> There is no network filtering for that too ? The ruleflow-group behaves
> like an agenda filter, but still evaluate all nodes ?
> Could we imagine setting "tags" to nodes, and stop propagation
> for node that does not declare the current task tag ?
>
>
> Le 21/03/2011 14:20, Edson Tirelli a écrit :
>
> The algorithm as is does eager evaluation, as for the general case
that
> is still better than doing selective evaluation.
>
> If, in your case, the decision of which rules to fire is an arbitrary
> application decision, and not based on the actual constraints of the
rules
> themselves, then the only way would be by creating a control fact:
>
> rule 1
> when
> ControlFact( phase == Phase.ONE )
> ...
>
> rule 2
> when
> ControlFact( phase == Phase.TWO )
> ...
>
> This way, if the control fact is the first pattern in each rule it
> effectively disables all the beta evaluations for rules of phases other
> than the current one. Just be aware that by blocking the eager evaluation
> this way, phase switches are heavier than without the control fact, where
> most constraints were already previously evaluated. Obvious, but worth
> saying out loud... :)
>
> There is also a feature that Leonardo is working on that makes the
> engine automatically unlink and relink parts of the network, based on the
> existence and possibility of matching the other required facts in a rule
> LHS. It might achieve similar results to what you are looking for in some
> cases, but that is totally based on the constraints in there and not on
> any arbitrary application decision.
>
> Edson
>
>
>
> ________________________________
>
>
**************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster@nds.com<mailto:postmaster@nds.com> and delete it from
> your system as well as any copies. The content of e-mails as well as
> traffic data may be monitored by NDS for employment and security
purposes.
> To protect the environment please do not print this e-mail unless
> necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
> 4EX, United Kingdom. A company registered in England and Wales.
Registered
> no. 3080780. VAT no. GB 603 8808 40-00
>
**************************************************************************************
>
>
>
>
>
>
> _______________________________________________
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluat...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
5007
days inactive
5011
days old
9 comments
6 participants
participants (6)
-
Edson Tirelli -
FrankVhh -
ljnelson -
Swindells, Thomas -
Vincent Legendre -
Wolfgang Laun