12:58 p.m.
Hi,
Total order requires JGroup's SEQEUNCER[1] protocol to be added to the protocol stack.
So users that want to switch between e.g. total order and optimistic TX are required to
also change the jgroups config (and the other way around). This is not very user friendly,
so I'm thinking to try and insert the SEQUENCER if it is missing from the stack and
TotalOrder is enabled, together with a log message. Anyone sees any problem with this?
Bela?
[1] http://www.jgroups.org/javadoc/org/jgroups/protocols/SEQUENCER.html
Cheers
Mircea
--
Mircea Markus
twitter.com/mirceamarkus
Sr. Software Engineer, Infinispan
http://www.infinispan.org
1:39 p.m.
On 03/06/2012 12:58 PM, Mircea Markus wrote:
Hi,
Total order requires JGroup's SEQEUNCER[1] protocol to be added to the protocol
stack. So users that want to switch between e.g. total order and optimistic TX are
required to also change the jgroups config (and the other way around). This is not very
user friendly, so I'm thinking to try and insert the SEQUENCER if it is missing from
the stack and TotalOrder is enabled, together with a log message. Anyone sees any problem
with this? Bela?
What about when Infinispan is not the owner of the JGroups channel,
i.e.
in the AS?
Tristan
1:43 p.m.
On 03/06/2012 01:39 PM, Tristan Tarrant wrote:
On 03/06/2012 12:58 PM, Mircea Markus wrote:
> Hi,
>
> Total order requires JGroup's SEQEUNCER[1] protocol to be added to the protocol
stack. So users that want to switch between e.g. total order and optimistic TX are
required to also change the jgroups config (and the other way around). This is not very
user friendly, so I'm thinking to try and insert the SEQUENCER if it is missing from
the stack and TotalOrder is enabled, together with a log message. Anyone sees any problem
with this? Bela?
What about when Infinispan is not the owner of the JGroups channel, i.e.
in the AS?
Replying to myself: I guess this could be done by offering different
named configurations
Tristan
2:41 p.m.
I might need COUNTER as well in the stack for certain configurations.
AFAIR, COUNTER would not affect the stack unless invoked explicitly so
I'm assuming when I'll finally use it I should be able to enable it on
all relevant configurations by default without fear of affecting other
users of the same channel; so being able to insert it dynamically on
an existing stack would be very useful, however it sounds like an
unpolished hack: one might add protocols which affect other Channel
users, or create unintended side-effects.
Could we do better and provide a shared base communication channel on
top of differently configured logical channels? Conceptually similar
to the MuxChannel, but moving the split point to a lower point in the
stack.
On 6 March 2012 12:43, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 03/06/2012 01:39 PM, Tristan Tarrant wrote:
> On 03/06/2012 12:58 PM, Mircea Markus wrote:
>> Hi,
>>
>> Total order requires JGroup's SEQEUNCER[1] protocol to be added to the
protocol stack. So users that want to switch between e.g. total order and optimistic TX
are required to also change the jgroups config (and the other way around). This is not
very user friendly, so I'm thinking to try and insert the SEQUENCER if it is missing
from the stack and TotalOrder is enabled, together with a log message. Anyone sees any
problem with this? Bela?
> What about when Infinispan is not the owner of the JGroups channel, i.e.
> in the AS?
>
Replying to myself: I guess this could be done by offering different
named configurations
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:59 p.m.
On 3/6/12 2:41 PM, Sanne Grinovero wrote:
I might need COUNTER as well in the stack for certain
configurations.
AFAIR, COUNTER would not affect the stack unless invoked explicitly so
I'm assuming when I'll finally use it I should be able to enable it on
all relevant configurations by default without fear of affecting other
users of the same channel; so being able to insert it dynamically on
an existing stack would be very useful, however it sounds like an
unpolished hack: one might add protocols which affect other Channel
users, or create unintended side-effects.
Yes, say someone might insert SEQUENCER on top of COUNTER after COUNTER
was inserted. This has unintended consequences, now all counter
invocations are globally ordered, which makes no sense as COUNTER uses
locks to provide exclusive access and thus doesn't need global order !
While it is useful to be able to dynamically insert protocols, e.g. for
testing, this can become a nightmare, e.g. when support asks for the
config and it doesn't include either SEQUENCER or COUNTER !
Also, IIRC the channel used by Infinispan is also used by the AS
(copying Paul), so changes to the stack will also affect the AS.
Could we do better and provide a shared base communication channel
on
top of differently configured logical channels? Conceptually similar
to the MuxChannel, but moving the split point to a lower point in the stack.
Is this something similar to the shared transport [1] ? I'm not sure but
AFAIK the AS already uses a shared transport. Is what you suggest above
similar to a shared transport ?
[1]
http://www.jgroups.org/manual-3.x/html/user-advanced.html#SharedTransport
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
3:25 p.m.
On 6 March 2012 13:59, Bela Ban <bban(a)redhat.com> wrote:
On 3/6/12 2:41 PM, Sanne Grinovero wrote:
> I might need COUNTER as well in the stack for certain configurations.
>
> AFAIR, COUNTER would not affect the stack unless invoked explicitly so
> I'm assuming when I'll finally use it I should be able to enable it on
> all relevant configurations by default without fear of affecting other
> users of the same channel; so being able to insert it dynamically on
> an existing stack would be very useful, however it sounds like an
> unpolished hack: one might add protocols which affect other Channel
> users, or create unintended side-effects.
Yes, say someone might insert SEQUENCER on top of COUNTER after COUNTER
was inserted. This has unintended consequences, now all counter
invocations are globally ordered, which makes no sense as COUNTER uses
locks to provide exclusive access and thus doesn't need global order !
While it is useful to be able to dynamically insert protocols, e.g. for
testing, this can become a nightmare, e.g. when support asks for the
config and it doesn't include either SEQUENCER or COUNTER !
Also, IIRC the channel used by Infinispan is also used by the AS
(copying Paul), so changes to the stack will also affect the AS.
> Could we do better and provide a shared base communication channel on
> top of differently configured logical channels? Conceptually similar
> to the MuxChannel, but moving the split point to a lower point in the stack.
Is this something similar to the shared transport [1] ? I'm not sure but
AFAIK the AS already uses a shared transport. Is what you suggest above
similar to a shared transport ?
Ha yes that looks like perfect!
But looking at the diagram, wouldn't it be useful to have those stacks
share PING, MERGE2 and FD ?
Taking a step further (and getting back to the topic), why not share
the full stack up to SEQUENCER or COUNTER,
so that we have two "virtual" channels but not having the two affect each
other?
-- Sanne
[1]
http://www.jgroups.org/manual-3.x/html/user-advanced.html#SharedTransport
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:30 p.m.
On 3/6/12 3:25 PM, Sanne Grinovero wrote:
> Is this something similar to the shared transport [1] ? I'm
not sure but
> AFAIK the AS already uses a shared transport. Is what you suggest above
> similar to a shared transport ?
Ha yes that looks like perfect!
But looking at the diagram, wouldn't it be useful to have those stacks
share PING, MERGE2 and FD ?
Taking a step further (and getting back to the topic), why not share
the full stack up to SEQUENCER or COUNTER,
so that we have two "virtual" channels but not having the two affect each
other?
On the todo list: [1], [2], [3]... It's not as trivial as it sounds
though...
[1] https://issues.jboss.org/browse/JGRP-844
[2] https://issues.jboss.org/browse/JGRP-790
[3] https://issues.jboss.org/browse/JGRP-640
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
3:31 p.m.
On 6 March 2012 14:30, Bela Ban <bban(a)redhat.com> wrote:
On 3/6/12 3:25 PM, Sanne Grinovero wrote:
>> Is this something similar to the shared transport [1] ? I'm not sure but
>> AFAIK the AS already uses a shared transport. Is what you suggest above
>> similar to a shared transport ?
>
> Ha yes that looks like perfect!
> But looking at the diagram, wouldn't it be useful to have those stacks
> share PING, MERGE2 and FD ?
>
> Taking a step further (and getting back to the topic), why not share
> the full stack up to SEQUENCER or COUNTER,
> so that we have two "virtual" channels but not having the two affect each
other?
On the todo list: [1], [2], [3]... It's not as trivial as it sounds
though...
[1] https://issues.jboss.org/browse/JGRP-844
[2] https://issues.jboss.org/browse/JGRP-790
[3] https://issues.jboss.org/browse/JGRP-640
Great, thanks! In the meantime, do you think it would make sense to
hardcode NO_TOTAL_ORDER flag in COUNTER usage ?
-- Sanne
3:44 p.m.
On 3/6/12 3:31 PM, Sanne Grinovero wrote:
On 6 March 2012 14:30, Bela Ban<bban(a)redhat.com> wrote:
>
>
> On 3/6/12 3:25 PM, Sanne Grinovero wrote:
>
>>> Is this something similar to the shared transport [1] ? I'm not sure but
>>> AFAIK the AS already uses a shared transport. Is what you suggest above
>>> similar to a shared transport ?
>>
>> Ha yes that looks like perfect!
>> But looking at the diagram, wouldn't it be useful to have those stacks
>> share PING, MERGE2 and FD ?
>>
>> Taking a step further (and getting back to the topic), why not share
>> the full stack up to SEQUENCER or COUNTER,
>> so that we have two "virtual" channels but not having the two affect
each other?
>
> On the todo list: [1], [2], [3]... It's not as trivial as it sounds
> though...
>
> [1] https://issues.jboss.org/browse/JGRP-844
> [2] https://issues.jboss.org/browse/JGRP-790
> [3] https://issues.jboss.org/browse/JGRP-640
Great, thanks! In the meantime, do you think it would make sense to
hardcode NO_TOTAL_ORDER flag in COUNTER usage ?
No, because this violates separation of concerns. Some people may
actually want to use COUNTER with total order (maybe it even makes sense
!)...
I say our best bet for now is to communicate with all stakeholders (e.g.
Paul for the AS), and come up with agreed-upon sets of configs, to be
used perhaps over a shared transport. I reconsider my previous statement
and now think it's best to avoid hidden insertions of protocols.
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
11:34 p.m.
I say our best bet for now is to communicate with all stakeholders
(e.g.
Paul for the AS), and come up with agreed-upon sets of configs, to be
used perhaps over a shared transport. I reconsider my previous
statement
and now think it's best to avoid hidden insertions of protocols.
+1 - I've started doing that and it's an ugly business.
Here's another approach:
- all jgroups configs shipped with ISPN come with the SEQUENCER added
- by default all messages have NO_TOTAL_ORDER flag attached
- RpcManager.invoke mthods would also support a totalOrder flag (similar to OBB flag
currently supported)
With this approach:
- we would support heterogeneous caches on the same cache manager: TO, 2PC *and* non-tx
caches
- we would allow existing users to switch to total order replication without the need to
change the jgroups configuration
- the performance penalty of having the SEQUENCER for caches that don't need it, e.g.
not tx caches, is minimal by the look of the code
How does it sound?
Cheers,
Mircea
8:06 a.m.
On 3/6/12 11:34 PM, Mircea Markus wrote:
> I say our best bet for now is to communicate with all
stakeholders
> (e.g.
> Paul for the AS), and come up with agreed-upon sets of configs, to be
> used perhaps over a shared transport. I reconsider my previous
> statement
> and now think it's best to avoid hidden insertions of protocols.
+1 - I've started doing that and it's an ugly business.
Here's another approach:
- all jgroups configs shipped with ISPN come with the SEQUENCER added
- by default all messages have NO_TOTAL_ORDER flag attached
- RpcManager.invoke mthods would also support a totalOrder flag (similar to OBB flag
currently supported)
With this approach:
- we would support heterogeneous caches on the same cache manager: TO, 2PC *and* non-tx
caches
- we would allow existing users to switch to total order replication without the need to
change the jgroups configuration
- the performance penalty of having the SEQUENCER for caches that don't need it, e.g.
not tx caches, is minimal by the look of the code
How does it sound?
Intuitively, not nice ! Can't we have different configurations for these
use cases ?
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
1:34 p.m.
> +1 - I've started doing that and it's an ugly business.
>
> Here's another approach:
> - all jgroups configs shipped with ISPN come with the SEQUENCER added
> - by default all messages have NO_TOTAL_ORDER flag attached
> - RpcManager.invoke mthods would also support a totalOrder flag (similar to OBB flag
currently supported)
>
> With this approach:
> - we would support heterogeneous caches on the same cache manager: TO, 2PC *and*
non-tx caches
> - we would allow existing users to switch to total order replication without the need
to change the jgroups configuration
> - the performance penalty of having the SEQUENCER for caches that don't need it,
e.g. not tx caches, is minimal by the look of the code
>
> How does it sound?
Intuitively, not nice ! Can't we have different configurations for these
use cases ?
We can, but the users that want to use both TO transactional caches and non transactional
caches on the same transport - a pretty common scenario IMO - would have to add the
seqeuncer to the jgroups configuration by hand. As the seqeuncer doesn't harm
performance, why not have it there by default?
1:57 p.m.
On 3/7/12 1:34 PM, Mircea Markus wrote:
>> +1 - I've started doing that and it's an ugly business.
>>
>> Here's another approach:
>> - all jgroups configs shipped with ISPN come with the SEQUENCER added
>> - by default all messages have NO_TOTAL_ORDER flag attached
>> - RpcManager.invoke mthods would also support a totalOrder flag (similar to OBB
flag currently supported)
>>
>> With this approach:
>> - we would support heterogeneous caches on the same cache manager: TO, 2PC *and*
non-tx caches
>> - we would allow existing users to switch to total order replication without the
need to change the jgroups configuration
>> - the performance penalty of having the SEQUENCER for caches that don't need
it, e.g. not tx caches, is minimal by the look of the code
>>
>> How does it sound?
>
> Intuitively, not nice ! Can't we have different configurations for these
> use cases ?
We can, but the users that want to use both TO transactional caches and non transactional
caches on the same transport - a pretty common scenario IMO - would have to add the
seqeuncer to the jgroups configuration by hand.
Why not have 2 separate channels, but both residing on the same shared
transport. I think Infinispan is injected a shared transport anyway, but
AS, so this could be reused...
Not sure on the details though, you'd have to talk to Paul for clarification
As the seqeuncer doesn't harm performance, why not have it there
by
default?
Because this suggests total order when looking at the config. A user
looking at the config, doesn't know that we're secretly bypassing SEQUENCER.
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
2:12 p.m.
> We can, but the users that want to use both TO transactional
caches and non transactional caches on the same transport - a pretty common scenario IMO -
would have to add the seqeuncer to the jgroups configuration by hand.
Why not have 2 separate channels, but both residing on the same shared
transport. I think Infinispan is injected a shared transport anyway, but
AS, so this could be reused...
Not sure on the details though, you'd have to talk to Paul for clarification
I'm not taking about 2 different caches on different CacheManagers here (this would
support two transports) but two caches (one TO tx and the other non-transactional) on the
same CacheManager: in this situation they share the same channel instance.
> As the seqeuncer doesn't harm performance, why not have it
there by
default?
Because this suggests total order when looking at the config. A user
looking at the config, doesn't know that we're secretly bypassing SEQUENCER.
We already do that with bundling, i.e. secretly not-bundle the sync messages even though
bundling is enabled in the configs by default.
3:22 p.m.
----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Tuesday, March 6, 2012 1:41:31 PM
Subject: Re: [infinispan-dev] TotalOrder and jgroups
I might need COUNTER as well in the stack for certain configurations.
AFAIR, COUNTER would not affect the stack unless invoked explicitly
Same for
SEQUENCER
so
I'm assuming when I'll finally use it I should be able to enable it
on
all relevant configurations by default without fear of affecting
other
users of the same channel; so being able to insert it dynamically on
an existing stack would be very useful, however it sounds like an
unpolished hack: one might add protocols which affect other Channel
users, or create unintended side-effects.
Could we do better and provide a shared base communication channel on
top of differently configured logical channels? Conceptually similar
to the MuxChannel, but moving the split point to a lower point in the
stack.
3:26 p.m.
On 3/6/12 3:22 PM, Mircea Markus wrote:
----- Original Message -----
> From: "Sanne Grinovero"<sanne(a)infinispan.org>
> To: "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 1:41:31 PM
> Subject: Re: [infinispan-dev] TotalOrder and jgroups
>
> I might need COUNTER as well in the stack for certain configurations.
>
> AFAIR, COUNTER would not affect the stack unless invoked explicitly
Same for SEQUENCER
Wait ! SEQUENCER *will* add total order to all multicast messages, so
this does change semantics !
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
3:21 p.m.
----- Original Message -----
From: "Tristan Tarrant" <ttarrant(a)redhat.com>
To: infinispan-dev(a)lists.jboss.org
Sent: Tuesday, March 6, 2012 12:43:02 PM
Subject: Re: [infinispan-dev] TotalOrder and jgroups
On 03/06/2012 01:39 PM, Tristan Tarrant wrote:
> On 03/06/2012 12:58 PM, Mircea Markus wrote:
>> Hi,
>>
>> Total order requires JGroup's SEQEUNCER[1] protocol to be added to
>> the protocol stack. So users that want to switch between e.g.
>> total order and optimistic TX are required to also change the
>> jgroups config (and the other way around). This is not very user
>> friendly, so I'm thinking to try and insert the SEQUENCER if it
>> is missing from the stack and TotalOrder is enabled, together
>> with a log message. Anyone sees any problem with this? Bela?
> What about when Infinispan is not the owner of the JGroups channel,
> i.e.
> in the AS?
in order to use TO the transport *must* have the SEQUENCER. I
don't think that adding the sequencer affects the rest the messages, as the seqeunced
message require an special flag to be passed to into the message header - Bela, can you
please confirm this?
So I think it should be fine even if the channel is modified.
>
Replying to myself: I guess this could be done by offering different
named configurations
Not sure I understand.. (not that the message was intended for
me :D )
3:28 p.m.
On 3/6/12 3:21 PM, Mircea Markus wrote:
----- Original Message -----
> From: "Tristan Tarrant"<ttarrant(a)redhat.com>
> To: infinispan-dev(a)lists.jboss.org
> Sent: Tuesday, March 6, 2012 12:43:02 PM
> Subject: Re: [infinispan-dev] TotalOrder and jgroups
>
> On 03/06/2012 01:39 PM, Tristan Tarrant wrote:
>> On 03/06/2012 12:58 PM, Mircea Markus wrote:
>>> Hi,
>>>
>>> Total order requires JGroup's SEQEUNCER[1] protocol to be added to
>>> the protocol stack. So users that want to switch between e.g.
>>> total order and optimistic TX are required to also change the
>>> jgroups config (and the other way around). This is not very user
>>> friendly, so I'm thinking to try and insert the SEQUENCER if it
>>> is missing from the stack and TotalOrder is enabled, together
>>> with a log message. Anyone sees any problem with this? Bela?
>> What about when Infinispan is not the owner of the JGroups channel,
>> i.e.
>> in the AS?
in order to use TO the transport *must* have the SEQUENCER. I don't think that adding
the sequencer affects the rest the messages, as the seqeunced message require an special
flag to be passed to into the message header - Bela, can you please confirm this?
No, this is not correct: it's actually the other way round, if you add a
flag NO_TOTAL_ORDER, then the message bypasses SEQUENCER. Otherwise, the
message will be sent and delivered in global order
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
2:47 p.m.
No, I think this is a good idea. The algorithm should check if SEQUENCER
is present in the stack, and insert a new instance at startup if not,
otherwise no-op.
This is only for *replication*, correct ? For *distribution*, the
CloudTM folks will send us a different total order protocol (TOM)
soon... but the same mechanism can be applied.
On 3/6/12 12:58 PM, Mircea Markus wrote:
Hi,
Total order requires JGroup's SEQEUNCER[1] protocol to be added to the protocol
stack. So users that want to switch between e.g. total order and optimistic TX are
required to also change the jgroups config (and the other way around). This is not very
user friendly, so I'm thinking to try and insert the SEQUENCER if it is missing from
the stack and TotalOrder is enabled, together with a log message. Anyone sees any problem
with this? Bela?
[1] http://www.jgroups.org/javadoc/org/jgroups/protocols/SEQUENCER.html
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
3:17 p.m.
Hi,
Yes it is for replication.
Actually, when it tries to create a cache with the Total Order based
protocol, it checks if the sequencer is in JGroups' protocol stack. If
it is not, then an exception is thrown.
Cheers,
Pedro
On 3/6/12 1:47 PM, Bela Ban wrote:
No, I think this is a good idea. The algorithm should check if
SEQUENCER
is present in the stack, and insert a new instance at startup if not,
otherwise no-op.
This is only for *replication*, correct ? For *distribution*, the
CloudTM folks will send us a different total order protocol (TOM)
soon... but the same mechanism can be applied.
On 3/6/12 12:58 PM, Mircea Markus wrote:
> Hi,
>
> Total order requires JGroup's SEQEUNCER[1] protocol to be added to the protocol
stack. So users that want to switch between e.g. total order and optimistic TX are
required to also change the jgroups config (and the other way around). This is not very
user friendly, so I'm thinking to try and insert the SEQUENCER if it is missing from
the stack and TotalOrder is enabled, together with a log message. Anyone sees any problem
with this? Bela?
>
> [1] http://www.jgroups.org/javadoc/org/jgroups/protocols/SEQUENCER.html
3:24 p.m.
----- Original Message -----
From: "Pedro Ruivo" <pruivo(a)gsd.inesc-id.pt>
To: infinispan-dev(a)lists.jboss.org
Sent: Tuesday, March 6, 2012 2:17:35 PM
Subject: Re: [infinispan-dev] TotalOrder and jgroups
Hi,
Yes it is for replication.
Actually, when it tries to create a cache with the Total Order based
protocol, it checks if the sequencer is in JGroups' protocol stack.
If
it is not, then an exception is thrown.
That's what we try to change, not throw
an exception but add the seqeuncer on the fly :)
3:24 p.m.
Thanks Bela.
----- Original Message -----
From: "Bela Ban" <bban(a)redhat.com>
To: infinispan-dev(a)lists.jboss.org
Sent: Tuesday, March 6, 2012 1:47:47 PM
Subject: Re: [infinispan-dev] TotalOrder and jgroups
No, I think this is a good idea. The algorithm should check if
SEQUENCER
is present in the stack, and insert a new instance at startup if not,
otherwise no-op.
This is only for *replication*, correct ? For *distribution*, the
CloudTM folks will send us a different total order protocol (TOM)
soon... but the same mechanism can be applied.
On 3/6/12 12:58 PM, Mircea Markus wrote:
> Hi,
>
> Total order requires JGroup's SEQEUNCER[1] protocol to be added to
> the protocol stack. So users that want to switch between e.g.
> total order and optimistic TX are required to also change the
> jgroups config (and the other way around). This is not very user
> friendly, so I'm thinking to try and insert the SEQUENCER if it is
> missing from the stack and TotalOrder is enabled, together with a
> log message. Anyone sees any problem with this? Bela?
>
> [1]
> http://www.jgroups.org/javadoc/org/jgroups/protocols/SEQUENCER.html
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4490
days inactive
4491
days old
infinispan-dev@lists.jboss.org
21 comments
6 participants
participants (6)
-
Bela Ban -
Mircea Markus -
Mircea Markus -
Pedro Ruivo -
Sanne Grinovero -
Tristan Tarrant