@Roland,

Indeed it is an interesting discussion, I think it is what some people 
might call a "definition by assumption", basically (as a parallel example):

we were given something that behaves like a car (we were not told that it 
is a car) but it behaves like it and hence we assumed and used it like it,
then in the future we are going to be told (empirically) that it is a plane 
and that it will consistently behave as such which,
will bring problem if people were using actions like "brake", etc, it might 
be painful for systems that treated it like a car.

Cheers,

Guido.

On Thursday, March 31, 2016 at 3:49:14 PM UTC+1, rkuhn wrote:
>
> Another angle on this discussion comes into play when considering Akka 
> Typed: there we make it very obvious that PreStart and PostStop are signals 
> that the actor may react to if it so chooses. In this spirit it would make 
> sense to disregard the outcome of such signal processing if it fails and 
> continue with the actor lifecycle just as if it were any other message that 
> triggered the fault. In other words, Akka Typed might want to implement the 
> newly proposed behavior instead of the current one.
>
> The same reasoning applies if preStart() and postStop() are regarded as 
> lifecycle hooks—i.e. code that is “informed” of some lifecycle events—as 
> opposed to active state transition steps. This view would be consistent 
> with the description of these methods in the JavaDoc/ScalaDoc or reference 
> documentation as well.
>
> The current behavior would be consistent with the view that preStart() 
> transforms the actor into the running state, it is nor merely a “hook”.
>
> Interestingly, I have never pondered these semantics in this light before, 
> thanks for the discussion!
>
> Regards,
>
> Roland
>
> PS: changing this behavior is indeed not trivial since nulling out the 
> actor field is required for proper handling of everything that 
> follows—simply declaring the actor failed would not achieve the right 
> semantics.
>
> 31 mar 2016 kl. 15:34 skrev Endre Varga <endre...@lightbend.com 
> <javascript:>>:
>
> Ok, since the change is not completely trivial either, let's keep the 
> current behavior until someone cries about it again :)
>
> -Endre
>
> On Thu, Mar 31, 2016 at 3:31 PM, Tal Pressman <kir...@gmail.com 
> <javascript:>> wrote:
>
> Hmm, I guess I wasn't very clear... What I was trying to say is, let's say 
> I have something like this:
> preStart {
>   allocate resource
>   something that can fail
> }
>
> I can wrap the part that can fail with a try catch, and release the 
> resource that was allocated. Because I am still in preStart I have the 
> context of what was and wasn't initialized. But if preStart finished 
> successfully, then I know for sure all the resources were acquired and have 
> to be released.
> Granted, this isn't the most elegant code (takes me back to my C days, all 
> that's missing are goto's), but I really dislike the double-failure 
> solution.
>
> Tal
>
>
>
> On Thursday, March 31, 2016 at 4:23:19 PM UTC+3, drewhk wrote:
>
>
>
> On Thu, Mar 31, 2016 at 3:10 PM, Tal Pressman <kir...@gmail.com> wrote:
>
>
> Here's my (unimportant and unsolicited ^_^) opinion.
> I think this should be left as is for a couple of reasons.
> 1. In the case you mentioned where a file is opened in the c'tor, 
>
>
> But what I was arguing is if you allocate the file in preStart(). We 
> cannot do anything with ctor failures.
>  
>
> the file could have been opened during preStart. That way if you allocate 
> the resource, you will get to postStop
>
>
> But this is exactly what is not true here. If preStart fails, you don't 
> get to postStop.
>
> Basically there is no contention on that once an actor is considered 
> running, postStop should be called. The contention is when should an actor 
> considered to be running, just before the invocation of preStart, of after 
> the successful invocation of preStart.
>  
>
> , and if you fail in preStart you haven't allocated resources (or you know 
> how far along the initialization you are so you can clean up the resources 
> that were actually allocated).
> 2. I generally think of preStart and postStop as being associated, like a 
> constructor and destructor (in languages that have them). In such cases, if 
> the constructor fails the destructor isn't called, and I think this case is 
> similar.
>
>
> Interesting, for me preStart is being associated in my head in a 
> completely different way: if preStart has been called, then postStop will 
> be called, too, independently of exceptions thrown.
>  
>
> 3. And finally, of course, there's the backwards-compatibility issue that 
> was already mentioned here. I doubt it'll cause many issues, but the ones 
> it will cause will probably be fairly hard to detect (most projects don't 
> have tests for every object failing initialization).
>
>
> This wouldn't be in a minor anyway as we discussed before, and majors can 
> and do break semantics from time to time.
>
> Anyway, seems like apart from the original poster and me, noone is 
> interested in this change. Stream stages do call postStop even after 
> preStart failures though, so be aware of it.
>
> Also, consider that after an actor restart postRestart() is called, which 
> will call preStart(), which, if fails will cause postStop to be called if 
> the actor is stopped - unlike the normal startup scenario. This is 
> inconsistent in a sense.
>  
>
>
> Tal
>
>
> On Thursday, March 31, 2016 at 3:50:00 PM UTC+3, drewhk wrote:
>
> That is an orthogonal concern in my eyes. The following options are 
> possible now
>  - init fails
>  - init; preStart fails
>  - init; preStart; postStop (fails)?
>
> The above contract is basically: "If any initialization fails, postStop is 
> never called"
>
> It can be changed to
>  - init fails
>  - init; preStart (fails)?; postStop (fails)?
>
> The above contract is basically: "If initialization succeeds, preStart and 
> postStop are attempted to be called eventually, independently of thrown 
> exceptions"
>
> I proposed the second as it makes postStop a new line of defense which it 
> hasn't been before. For example stream stages *do* attempt to call postStop 
> even if preStart throws.
>
> -Endre
>
>
>
> On Thu, Mar 31, 2016 at 2:41 PM, Viktor Klang <viktor...@gmail.com> wrote:
>
> PostStop would never be called if the constructor fails. Which could be 
> said to be similar to preStart?
>
> -- 
> Cheers,
> √
> On Mar 31, 2016 2:39 PM, "Endre Varga" <endre...@lightbend.com> wrote:
>
>
>
> On Thu, Mar 31, 2016 at 2:36 PM, Guido Medina <oxy...@gmail.com> wrote:
>
> it gets worse if I failed starting "b" because  now "a" is started and it 
> won't be stopped, 
>
>
> I don't understand this question. If we failed starting "b" then it will 
> not be running, this is not changed by calling postStop() on the retreat 
> before nulling out the actor. 
>  
>
> such cases IMHO should be handled by the user 
>
> and
> instead just stick to the contract which is, "stop if was started" which 
> will lead to less 
>
>
> The contract will be here just as simple first preStart and eventually 
> postStop will be attempted to be called, after which the actor is GC-able. 
> This is also a simple contract.
>  
>
> confusion and easier to maintain the exceptional cases.
>
>
> On Thursday, March 31, 2016 at 1:23:39 PM UTC+1, Guido Medina wrote:
>
> so, say:
>
> Object a = null, Object b = null;
>
> preStart():
>
>   a = new something(); a.start(); *<= say I failed here.*
>   b = new somethingElse(); b start();
>
> postStop():
>
>   b.stop(); boom NPE.
>   a.stop();
>
> That's why the word transaction exist right? A unit is considered started 
> or valid of all its parts are valid and started...
> But go ahead, make legacy code life miserable...the decision is yours.
>
> Try catch is there for a reason but somehow magic exists.
>
> Guido.
>
> On Thursday, March 31, 2016 at 1:15:27 PM UTC+1, drewhk wrote:
>
>
>
> On Thu, Mar 31, 2016 at 2:10 PM, Guido Medina <oxy...@gmail.com> wrote:
>
> I haven't seen any system stopping something consciously that it was 
> unable to start, the created instance is just an instance like another 
> other object which will be GCed.
>
>
> I don't agree, you might have opened a file or socket in the constructor 
> or parts of preStart() before the exception.
>  
>
> If you look at it from a state machine perspective Status: CREATED => CALL 
> START (or preStart don't worry about details) => Status: Started
>
> It is more destructive to call postStop if it didn't actually started 
> because then you will get NPE for stopping things that are part of the 
> actor that weren't instantiated. 
>
> Now I have to protect my code from Akka calling postStop...see my point?
>
>
> Nope, Akka should just swallow the double-fault at that point. I still 
> think it should at least attempt to call postStop() to mitigate resource 
> leaks.
>
> -Endre
>  
>
>
> Guido.
>
> On Thursday, March 31, 2016 at 9:19:15 AM UTC+1, drewhk wrote:
>
> That description suits me ;)
>
> On Thu, Mar 31, 2016 at 10:18 AM, Patrik Nordwall <patrik....@gmail.com> 
> wrote:
>
> From the source: "Only change this if you're very confident and lucky" :-)
>
> On Thu, Mar 31, 2016 at 9:30 AM, Endre Varga <endre...@lightbend.com> 
> wrote:
>
> Shouldn't we all postStop there if preStart has been at least invoked 
> (i.e. there is already an instance)? It does not seem to be hard, just 
> shuffling that code a bit around (famous last words?).
>
> On Thu, Mar 31, 2016 at 9:25 AM, Patrik Nordwall <patrik....@gmail.com> 
> wrote:
>
> I think that is how it is implemented. Exception from preStart results in 
> clearing the actor field and throwing ActorInitializationException:
>
> https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/ActorCell.scala#L599
>
> Default supervision will result in stop, but postStop is not called 
> because the actor field was cleared: 
> https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/dungeon/FaultHandling.scala#L210
>
> On Wed, Mar 30, 2016 at 10:59 AM, Endre Varga <endre...@lightbend.com> 
> wrote:
>
>
>
> On Sun, Mar 27, 2016 at 5:52 PM, Stanislav Savulchik <s.sav...@gmail.com> 
> wrote:
>
> Hi, everyone! 
>
> I've discovered that Actor's postStop method doesn't get invoked if 
> exception occurs during actor initialization via preStart method. Does 
> anyone know if it is the correct behavior? I expected that the failed actor 
> could close some resources in postStop.
>
>
> Do you have a reproducer for this? I would also expect postStop to be at 
> least attempted to be called.
>  
>
> P.S. The behavior differs when a failure occurs during regular vs. system 
> message processing and supervisor decides to Stop the failed child. It 
> seems inconsistent to me.
>
>
> What do you mean here? Can you provide a small example to show this?
>  
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] <http://www.lightbend.com/>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
> [image: Lightbend] <http://www.lightbend.com/>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at 
>
> ...

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to