Couldn't Danie's problem also be stated as "forked processes don't inherit their parents environment"? Or is there more stopping WARequestContext from working?
Apart from the fact that they currently don't, is there a good reason they shouldn't? Cheers, Henry On Jul 7, 2011, at 4:56 55PM, Igor Stasenko wrote: > On 7 July 2011 16:43, Danie Roux <[email protected]> wrote: >> Hi all, >> >> We use Announcements in our Seaside app. I've upgraded our Pharo image >> (from an ancient one) and the upgraded image looses the user's >> session. >> >> This issue is here: >> >> AnnouncementSubscription>>deliver: anAnnouncement >> " deliver an announcement to receiver. In case of failure, it will be >> handled in separate process" >> >> ^ (self handles: anAnnouncement class ) ifTrue: [ >> [action cull: anAnnouncement cull: announcer] >> on: Exception fork: [:ex | ex pass ]] >> >> Because of the catch-all, WARequestContext can't do its fancy footwork >> to manage thread-local variables. >> >> What is the rationale behind this? I removed the error handling. >> > > The rationale is that failing handling an announcement by one > subscriber should not prevent it from receiving announcement by > another subscriber. > > Consider that you have two subscribers for same announcement. > and one subscriber is broken and throwing an exception(s) during > handling it. This could prevent other subscriber from receiving > announcement, > and therefore in the end you will have a 'lost events' effect. > > To prevent it, there are #on:fork: which guards against any exceptions > and guarantees that execution at this point will continue normally , > no matter what handler does. > > Maybe Exception is too strict and we should handle only Errors there. > But consider to not use exceptions in announcement handling code, > because this leads to the described scenario, which is certainly adds > fragility to announcements. > > Since we want to use announcements in mission critical places, like > delivering system events and logging compiled sources, and managing > package info, > it is important that for system announcer , any buggy subscribers > won't put system on its knees. > Because from the point of view of subscriber , there nothing should > prevent it from receiving an announcement. There should be no > interference between multiple subscribers subscribed for same > announcement, > because they could even don't know about each other. > > >> -- >> Danie Roux *shuffle* Adore Unix - http://danieroux.com >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >
