Re: [X10-users] [APGAS] Questions about ResilientUTS

2016-07-11 Thread Olivier Tardieu 
Jonas,

A finish always throws an exception of type MultipleException or its 
subtype DeadPlacesException (plural: DeadPlaces) if all the (transitively) 
suppressed exceptions are of type DeadPlaceException.
An asyncAt can throw a DeadPlaceException (singular: DeadPlace) if the 
destination place is dead.
DeadPlaceException and MultipleException are two uncomparable types thrown 
in different contexts.
DeadPlacesException is a subtype of MultipleException intended to make it 
easy to check that nothing went wrong other than places dying in a finish 
block.

In the case you describe catching a DeadPlacesException (plural) should 
work.
Catching a DeadPlaceException (singular) will not.

I suspect the current spelling is too confusing.
I'll do something else.

Olivier

Jonas Posner  wrote on 07/11/2016 10:42:47 AM:

> From: Jonas Posner 
> To: Mailing list for users of the X10 programming language  us...@lists.sourceforge.net>
> Date: 07/11/2016 10:43 AM
> Subject: Re: [X10-users] [APGAS] Questions about ResilientUTS
> 
> Hi Olivier,
> 
> about DeadPlaceException in line 386:
> For testing, I modified the lambda in line 274:
> 
> () -> {
>  if (here().id == 1) {
>  System.exit(42);
>  }
>  return new ResilientUTS(wave, group, power, s, r, resilient);
> });
> 
> In this case, I catch a MultipleException which contains one actual 
> DeadPlaceException and two suppressed DeadPlaceExceptions. However the 
> program continues and the result is correct. Without changing 
> DeadPlaceException to MultipleException the whole program crashes.
> 
> I am playing around with these Exceptions in minimal programs and do not 

> understand the mind of MultipleExceptions. When should a 
> MultipleException be thrown and when a DeadPlaceException?
> 
> 
> Best wishes,
> Jonas
> 
> Am 09.07.2016 um 15:08 schrieb Olivier Tardieu:
> > Hi Jonas,
> >
> > About DeadPlacesException at line 386. I am not sure.
> > What exception other than a DeadPlaceException are you seeing inside 
the
> > MultipleException?
> >
> > About data loss.
> > When I started working with Hazelcast, there was no reliable way to
> > detect data loss.
> > Hazelcast has added an API for data loss events so it should be 
possible
> > now.
> > Have a look at the "Partition Loss Listener" in Hazelcast.
> >
> > About backup counts.
> > Yes this seems reasonable for now.
> > Eventually APGAS should expose a configuration parameter for this.
> >
> > About line 297.
> > Yes, the transaction guarantees that we obtain a consistent view of 
the map.
> > In theory, we need this to preclude delayed map updates coming from 
dead
> > places.
> > We are working toward preventing such spurious updates and make your
> > simpler code correct.
> > For now, your code is very unlikely to fail, but there is no 
consistency
> > guarantee.
> >
> > I have no immediate plan to simplify the resilient map API but I agree
> > this would be nice...
> >
> > Olivier
> >
> >
> >
> >
> >
> > From: Jonas Posner 
> > To: x10-users@lists.sourceforge.net
> > Date: 07/07/2016 08:45 AM
> > Subject: [X10-users] [APGAS] Questions about ResilientUTS
> > 

> >
> >
> >
> > Hi all,
> >
> > I have a few questions about the ResilientUTS example from the APGAS
> > project:
> >
> > In line 386, the DeadPlacesException has to be a MultipleException,
> > right? With DeadPlacesException the program crashes when a places 
crashes.
> >
> > When one place crashes after another, the result is false. The reason 
is
> > probably the backupcount of the map. Is there a way to detect data 
loss?
> >
> > To tolerate two place crashes, I added the following code before
> > initializing the map:
> > MapConfig mapConfig = new MapConfig("map"+wave);
> > mapConfig.setBackupCount(2);
> > hz.getConfig().addMapConfig(mapConfig);
> > Is this the preferred way?
> >
> > In line 297, I don't understand the purpose of:
> > final Collection values = uts.hz((TransactionalTaskContext
> > context) -> { return context. getMap("map" +
> > wave).values(); });
> > With a simple "final Collection values = uts.map.values();" it 
also
> > works in my test cases. What are the advantages of the original?
> > As far as I understand, the purpose of executeTransaction in method
> > transfer is to guarantee data integrity?
> >
> > Are there any plans for the future that APGAS provides more
> > functionalities to the programmer, so that a APGAS programmer does not
> > have to use hazelcast directly?
> >
> >
> > Thanks and cheers
> > Jonas
> >
> >
> > ---
> > Jonas Posner
> > Universitaet Kassel
> > Fachbereich 16 Elektrotechnik/Informatik
> > Fachgebiet Programmiersprachen/-methodik
> > Wilhelmshoeher Allee 71-73
> > 34121 Kassel, Germany
> >
> > Phone:  +49 (0)561 804-6498
> > Fax:+49 (0)561 804-6219
> > mailto:

Re: [X10-users] [APGAS] Questions about ResilientUTS

2016-07-11 Thread Jonas Posner 
Hi Olivier,

about DeadPlaceException in line 386:
For testing, I modified the lambda in line 274:

() -> {
 if (here().id == 1) {
 System.exit(42);
 }
 return new ResilientUTS(wave, group, power, s, r, resilient);
});

In this case, I catch a MultipleException which contains one actual 
DeadPlaceException and two suppressed DeadPlaceExceptions. However the 
program continues and the result is correct. Without changing 
DeadPlaceException to MultipleException the whole program crashes.

I am playing around with these Exceptions in minimal programs and do not 
understand the mind of MultipleExceptions. When should a 
MultipleException be thrown and when a DeadPlaceException?


Best wishes,
Jonas

Am 09.07.2016 um 15:08 schrieb Olivier Tardieu:
> Hi Jonas,
>
> About DeadPlacesException at line 386. I am not sure.
> What exception other than a DeadPlaceException are you seeing inside the
> MultipleException?
>
> About data loss.
> When I started working with Hazelcast, there was no reliable way to
> detect data loss.
> Hazelcast has added an API for data loss events so it should be possible
> now.
> Have a look at the "Partition Loss Listener" in Hazelcast.
>
> About backup counts.
> Yes this seems reasonable for now.
> Eventually APGAS should expose a configuration parameter for this.
>
> About line 297.
> Yes, the transaction guarantees that we obtain a consistent view of the map.
> In theory, we need this to preclude delayed map updates coming from dead
> places.
> We are working toward preventing such spurious updates and make your
> simpler code correct.
> For now, your code is very unlikely to fail, but there is no consistency
> guarantee.
>
> I have no immediate plan to simplify the resilient map API but I agree
> this would be nice...
>
> Olivier
>
>
>
>
>
> From: Jonas Posner 
> To: x10-users@lists.sourceforge.net
> Date: 07/07/2016 08:45 AM
> Subject: [X10-users] [APGAS] Questions about ResilientUTS
> 
>
>
>
> Hi all,
>
> I have a few questions about the ResilientUTS example from the APGAS
> project:
>
> In line 386, the DeadPlacesException has to be a MultipleException,
> right? With DeadPlacesException the program crashes when a places crashes.
>
> When one place crashes after another, the result is false. The reason is
> probably the backupcount of the map. Is there a way to detect data loss?
>
> To tolerate two place crashes, I added the following code before
> initializing the map:
> MapConfig mapConfig = new MapConfig("map"+wave);
> mapConfig.setBackupCount(2);
> hz.getConfig().addMapConfig(mapConfig);
> Is this the preferred way?
>
> In line 297, I don't understand the purpose of:
> final Collection values = uts.hz((TransactionalTaskContext
> context) -> { return context. getMap("map" +
> wave).values(); });
> With a simple "final Collection values = uts.map.values();" it also
> works in my test cases. What are the advantages of the original?
> As far as I understand, the purpose of executeTransaction in method
> transfer is to guarantee data integrity?
>
> Are there any plans for the future that APGAS provides more
> functionalities to the programmer, so that a APGAS programmer does not
> have to use hazelcast directly?
>
>
> Thanks and cheers
> Jonas
>
>
> ---
> Jonas Posner
> Universitaet Kassel
> Fachbereich 16 Elektrotechnik/Informatik
> Fachgebiet Programmiersprachen/-methodik
> Wilhelmshoeher Allee 71-73
> 34121 Kassel, Germany
>
> Phone:  +49 (0)561 804-6498
> Fax:+49 (0)561 804-6219
> mailto: jonas.pos...@uni-kassel.de
> www.uni-kassel.de
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> X10-users mailing list
> X10-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/x10-users
>
>
>
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
>
>
>
> ___
> X10-users mailing list
> X10-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/x10-users
>

-- 
---
Jonas Posner
Universitaet Kassel
Fachbereich 16 Elektrotechnik/Informatik
Fachgebiet Programmiersprachen/-methodik
Wilhelmshoeher Allee 71-73
34121 Kassel,