12:28 p.m.
Hi all,
Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting
[1]. It's complex and buggy, and we'd recommend people to use the Grouping API
instead [2]. Grouping API would allow data to reside together, while the standard map API
would apply per-key locking.
We don't have a timeline for this yet, but we want to get as much feedback on the
topic as possible so that we can evaluate the options.
Cheers,
[1] https://issues.jboss.org/browse/ISPN-3901
[2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping...
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12:32 p.m.
Hi,
On 01/20/2014 11:28 AM, Galder Zamarreño wrote:
Hi all,
Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting
[1]. It's complex and buggy, and we'd recommend people to use the Grouping API
instead [2]. Grouping API would allow data to reside together, while the standard map API
would apply per-key locking.
+1. are we going to dropping the Delta stuff?
We don't have a timeline for this yet, but we want to get as much feedback on the
topic as possible so that we can evaluate the options.
before starting with it, I would recommend to add the following method
to cache API:
/**
* returns all the keys and values associated with the group name. The
Map<K, V> is immutable (i.e. read-only)
**/
Map<K, V> getGroup(String groupName);
Cheers,
Pedro
Cheers,
[1] https://issues.jboss.org/browse/ISPN-3901
[2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping...
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:39 p.m.
Please don't remove the Delta stuff. That's quite useful, especially for
large collections.
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Pedro Ruivo
Sent: Monday, January 20, 2014 6:33 AM
To: infinispan-dev(a)lists.jboss.org
Subject: Re: [infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Hi,
On 01/20/2014 11:28 AM, Galder Zamarreño wrote:
Hi all,
Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the
F2F
meeting [1]. It's complex and buggy, and we'd recommend people to use
the Grouping API instead [2]. Grouping API would allow data to reside
together, while the standard map API would apply per-key locking.
+1. are we going to dropping the Delta stuff?
We don't have a timeline for this yet, but we want to get as much feedback
on
the topic as possible so that we can evaluate the options.
before starting with it, I would recommend to add the following method to
cache API:
/**
* returns all the keys and values associated with the group name. The
Map<K, V> is immutable (i.e. read-only)
**/
Map<K, V> getGroup(String groupName);
Cheers,
Pedro
Cheers,
[1] https://issues.jboss.org/browse/ISPN-3901
[2]
http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_group
ing_api
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:45 p.m.
On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
I agree with Erik here. Deltas are used in M/R and I've never
detected
any problems so far.
On 1/21/2014, 1:39 PM, Erik Salter wrote:
> Please don't remove the Delta stuff. That's quite useful, especially for
> large collections.
+1 to keep DeltaAware. Thanks for the feedbak
>
> Erik
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:27 a.m.
I think it's way too early to discuss removing FineGrainedAtomicMap and
AtomicMap, as long as we don't have a concrete alternative with similar
properties.
Cache.getGroup(groupName) is just a method name at this point, we don't
have any idea how it will compare to AtomicMap/FineGrainedAtomicMap from a
transaction isolation or performance perspective. BTW, do we really need
the group name to be a String?
A good way to prove that the grouping API is a proper replacement for the
atomic maps would be to replace the usage of atomic maps in the Tree module
with the grouping API. Unless we plan to drop the Tree module completely...
Cheers
Dan
On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
> I agree with Erik here. Deltas are used in M/R and I've never detected
> any problems so far.
> On 1/21/2014, 1:39 PM, Erik Salter wrote:
>> Please don't remove the Delta stuff. That's quite useful, especially
for
>> large collections.
+1 to keep DeltaAware. Thanks for the feedbak
>>
>> Erik
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:30 p.m.
On Mon 2014-01-27 12:27, Dan Berindei wrote:
Cache.getGroup(groupName) is just a method name at this point, we
don't
have any idea how it will compare to AtomicMap/FineGrainedAtomicMap from a
transaction isolation or performance perspective. BTW, do we really need
the group name to be a String?
+1 for the name not being a String.
Today in OGM we use a generic Key object to represent associations. A
string version has many drawbacks.
10:02 a.m.
On 27 Jan 2014, at 11:27, Dan Berindei <dan.berindei(a)gmail.com> wrote:
I think it's way too early to discuss removing
FineGrainedAtomicMap and AtomicMap, as long as we don't have a concrete alternative
with similar properties.
You have a point there, but we can’t ignore the feedback that says that atomic maps are
not being used because they are buggy, and instead they are using grouping.
Deeply, I think we have two ways of doing the same thing, which is confusing from my POV,
and one of them is not being used enough, or we’re not fixing the stuff there.
Regardless of whether it’s too early or not, this email is trying to spark a consolidation
of the two technologies into a single solution that works for everyone and we maintained
it actively :)
Cache.getGroup(groupName) is just a method name at this point, we
don't have any idea how it will compare to AtomicMap/FineGrainedAtomicMap from a
transaction isolation or performance perspective. BTW, do we really need the group name to
be a String?
A good way to prove that the grouping API is a proper replacement for the atomic maps
would be to replace the usage of atomic maps in the Tree module with the grouping API.
Unless we plan to drop the Tree module completely…
Tree was only ever meant as a bridge for JBC users to move to Infinispan. Paul F et al
tried to build HTTP sessions on top of that, it didn’t work. Then they tried to do it on
top of Atomic Maps, and it didn’t work either, and finally they’re using grouping and
seems to work?
Cheers,
Cheers
Dan
On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
> I agree with Erik here. Deltas are used in M/R and I've never detected
> any problems so far.
> On 1/21/2014, 1:39 PM, Erik Salter wrote:
>> Please don't remove the Delta stuff. That's quite useful, especially
for
>> large collections.
+1 to keep DeltaAware. Thanks for the feedbak
>>
>> Erik
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
10:57 a.m.
On 10 February 2014 09:02, Galder Zamarreño <galder(a)redhat.com> wrote:
On 27 Jan 2014, at 11:27, Dan Berindei <dan.berindei(a)gmail.com> wrote:
> I think it's way too early to discuss removing FineGrainedAtomicMap and
AtomicMap, as long as we don't have a concrete alternative with similar properties.
You have a point there, but we can’t ignore the feedback that says that atomic maps are
not being used because they are buggy, and instead they are using grouping.
Let's not generalize too much, some are still doing the opposite and
have commented on their good reasons ;-)
Deeply, I think we have two ways of doing the same thing, which is confusing from my POV,
and one of them is not being used enough, or we’re not fixing the stuff there.
+1 but since as you say there is confusion, I'm not sure if they
really are the same thing. I've asked for a detailed comparison but
the discussion derailed. It would probably help a lot if someone from
the Infinispan core team would reimplement the FGAM API on top of
Grouping, making sure to guarantee the same semantics also in terms of
concurrency, isolation and acidity.
That would provide the implementation cleanup you'd all love, a
migration path, and probably some deeper considerations on their
differences; I also suspect there would be some roadblocks,
potentially subtle differences which could then be better documented?
Regardless of whether it’s too early or not, this email is trying to spark a
consolidation of the two technologies into a single solution that works for everyone and
we maintained it actively :)
> Cache.getGroup(groupName) is just a method name at this point, we don't have any
idea how it will compare to AtomicMap/FineGrainedAtomicMap from a transaction isolation or
performance perspective. BTW, do we really need the group name to be a String?
>
> A good way to prove that the grouping API is a proper replacement for the atomic maps
would be to replace the usage of atomic maps in the Tree module with the grouping API.
Unless we plan to drop the Tree module completely…
Tree was only ever meant as a bridge for JBC users to move to Infinispan. Paul F et al
tried to build HTTP sessions on top of that, it didn’t work. Then they tried to do it on
top of Atomic Maps, and it didn’t work either, and finally they’re using grouping and
seems to work?
I don't think that proves that Atomic Maps where not working, if any
it's a statement that grouping is a better fit for this specific use
case?
BTW having a use case which matches way better that the other just
highlights that this is no duplicate functionality, but rather quite
different stuff.
From an Hibernate OGM perspective it would be great to have some more
stability in not so old APIs, at least until there's a clearly
documented migration to grouping.
Sanne
Cheers,
>
> Cheers
> Dan
>
>
>
> On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
>
> > I agree with Erik here. Deltas are used in M/R and I've never detected
> > any problems so far.
> > On 1/21/2014, 1:39 PM, Erik Salter wrote:
> >> Please don't remove the Delta stuff. That's quite useful,
especially for
> >> large collections.
>
> +1 to keep DeltaAware. Thanks for the feedbak
>
> >>
> >> Erik
> >>
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:12 p.m.
Dropping the FGAM API is just an idea and there were valid concerns for not doing it
immediately. Indeed the reason it was considered for removal is in order not to keep
around two APIs that do the same thing. That is if really do the same thing. As a first
step would be good to enhance the grouping API[1] to support group handling methods. Then
see if grouping works for the (FG)AM users: if it does, we can drop FGAM. If it
doesn't we'll fix FGAM.
[1] https://issues.jboss.org/browse/ISPN-3981
On Feb 10, 2014, at 9:57 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 10 February 2014 09:02, Galder Zamarreño <galder(a)redhat.com>
wrote:
>
> On 27 Jan 2014, at 11:27, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
>> I think it's way too early to discuss removing FineGrainedAtomicMap and
AtomicMap, as long as we don't have a concrete alternative with similar properties.
>
> You have a point there, but we can’t ignore the feedback that says that atomic maps
are not being used because they are buggy, and instead they are using grouping.
Let's not generalize too much, some are still doing the opposite and
have commented on their good reasons ;-)
>
> Deeply, I think we have two ways of doing the same thing, which is confusing from my
POV, and one of them is not being used enough, or we’re not fixing the stuff there.
+1 but since as you say there is confusion, I'm not sure if they
really are the same thing. I've asked for a detailed comparison but
the discussion derailed. It would probably help a lot if someone from
the Infinispan core team would reimplement the FGAM API on top of
Grouping, making sure to guarantee the same semantics also in terms of
concurrency, isolation and acidity.
That would provide the implementation cleanup you'd all love, a
migration path, and probably some deeper considerations on their
differences; I also suspect there would be some roadblocks,
potentially subtle differences which could then be better documented?
>
> Regardless of whether it’s too early or not, this email is trying to spark a
consolidation of the two technologies into a single solution that works for everyone and
we maintained it actively :)
>
>> Cache.getGroup(groupName) is just a method name at this point, we don't have
any idea how it will compare to AtomicMap/FineGrainedAtomicMap from a transaction
isolation or performance perspective. BTW, do we really need the group name to be a
String?
>>
>> A good way to prove that the grouping API is a proper replacement for the atomic
maps would be to replace the usage of atomic maps in the Tree module with the grouping
API. Unless we plan to drop the Tree module completely…
>
> Tree was only ever meant as a bridge for JBC users to move to Infinispan. Paul F et
al tried to build HTTP sessions on top of that, it didn’t work. Then they tried to do it
on top of Atomic Maps, and it didn’t work either, and finally they’re using grouping and
seems to work?
I don't think that proves that Atomic Maps where not working, if any
it's a statement that grouping is a better fit for this specific use
case?
BTW having a use case which matches way better that the other just
highlights that this is no duplicate functionality, but rather quite
different stuff.
From an Hibernate OGM perspective it would be great to have some more
stability in not so old APIs, at least until there's a clearly
documented migration to grouping.
Sanne
>
> Cheers,
>
>>
>> Cheers
>> Dan
>>
>>
>>
>> On Wed, Jan 22, 2014 at 2:45 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>
>> On Jan 21, 2014, at 8:42 PM, Vladimir Blagojevic <vblagoje(a)redhat.com>
wrote:
>>
>>> I agree with Erik here. Deltas are used in M/R and I've never detected
>>> any problems so far.
>>> On 1/21/2014, 1:39 PM, Erik Salter wrote:
>>>> Please don't remove the Delta stuff. That's quite useful,
especially for
>>>> large collections.
>>
>> +1 to keep DeltaAware. Thanks for the feedbak
>>
>>>>
>>>> Erik
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder(a)redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:58 a.m.
The delta’s will remain, but they’re each key/value pair.
Example: say you want to store a dehydrated list of three elements (“one”, “two”, “three”)
in Infinispan
Before you’d do (approx):
key=my-list
value=AtomicMap(k=1,v=“one”, k=2,v=“two”, k3=“v3”)
Internally, we’d track deltas and only send those changes.
What I propose we do is:
key=1 (group=“my-list")
value=“one”
key=2 (group=“my-list")
value=“two”
key=3 (group=“my-list")
value=“three”
The delta’s are still there. Each changed key is sent separately, when it changes.
This is not the final product of course. As agreed with Pedro, we’d need a way to have a
view map for all key/value pairs associated with a given group, i.e.
cache.getGroups(“my-list”).
I know Sanne et al also need a way to have coarse grained locking on the entire group
sometimes, as well as fine grained locking, so we’d need to find a way to accomodate
that.
Cheers,
On 21 Jan 2014, at 21:42, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
I agree with Erik here. Deltas are used in M/R and I've never
detected
any problems so far.
On 1/21/2014, 1:39 PM, Erik Salter wrote:
> Please don't remove the Delta stuff. That's quite useful, especially for
> large collections.
>
> Erik
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
9:51 a.m.
On 20 Jan 2014, at 12:32, Pedro Ruivo <pedro(a)infinispan.org> wrote:
Hi,
On 01/20/2014 11:28 AM, Galder Zamarreño wrote:
> Hi all,
>
> Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F
meeting [1]. It's complex and buggy, and we'd recommend people to use the Grouping
API instead [2]. Grouping API would allow data to reside together, while the standard map
API would apply per-key locking.
+1. are we going to dropping the Delta stuff?
The delta would be the k/v pair.
Say you are storing HTTP sessions. With AMs, the key would be the session ID and all its
attributes would be stored in the atomic map. Once you remove that, each session’s
attributes is a single k/v pair in the cache, so that’s your delta.
>
> We don't have a timeline for this yet, but we want to get as much feedback on the
topic as possible so that we can evaluate the options.
before starting with it, I would recommend to add the following method
to cache API:
/**
* returns all the keys and values associated with the group name. The
Map<K, V> is immutable (i.e. read-only)
**/
Map<K, V> getGroup(String groupName);
Yes, I think we’d need this for grouping to be able have a full replacement for atomic
maps. You need a way to retrieve all the data associated with that group without the to
iterate the cache yourself, or the need to add indexing.
In the case of HTTP sessions, you’d give the session ID as key and it’d give you a map
view of all the attributes associated with that session.
Cheers,
Cheers,
Pedro
>
> Cheers,
>
> [1] https://issues.jboss.org/browse/ISPN-3901
> [2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping...
> --
> Galder Zamarreño
> galder(a)redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
1:39 p.m.
Then cf the detailed feedback from that mailing list from the last time
we discussed it :)
There was specifically some feedback on how we use it for OGM and how we
need a way to retrieve all entries for a given group (at least).
Emmanuel
On Mon 2014-01-20 12:28, Galder Zamarreño wrote:
Hi all,
Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting
[1]. It's complex and buggy, and we'd recommend people to use the Grouping API
instead [2]. Grouping API would allow data to reside together, while the standard map API
would apply per-key locking.
We don't have a timeline for this yet, but we want to get as much feedback on the
topic as possible so that we can evaluate the options.
Cheers,
[1] https://issues.jboss.org/browse/ISPN-3901
[2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping...
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:20 p.m.
On Jan 20, 2014, at 11:28 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
Hi all,
Dropping AtomicMap and FineGrainedAtomicMap was discussed last week in the F2F meeting
[1]. It's complex and buggy, and we'd recommend people to use the Grouping API
instead [2]. Grouping API would allow data to reside together, while the standard map API
would apply per-key locking.
We don't have a timeline for this yet, but we want to get as much feedback on the
topic as possible so that we can evaluate the options.
+1
There's been a good discussion on this topic: http://goo.gl/WNs6KY
Cheers,
[1] https://issues.jboss.org/browse/ISPN-3901
[2] http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_the_grouping...
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
3734
days inactive
3755
days old
infinispan-dev@lists.jboss.org
13 comments
8 participants
participants (8)
-
Dan Berindei -
Emmanuel Bernard -
Erik Salter -
Galder Zamarreño -
Mircea Markus -
Pedro Ruivo -
Sanne Grinovero -
Vladimir Blagojevic