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 
> <javascript:>> 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 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 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 <javascript:>.
>> To post to this group, send email to akka...@googlegroups.com 
>> <javascript:>.
>> 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+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