[Pharo-project] Pharo Announcements and WADynamicVariable do not play nice
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. -- Danie Roux *shuffle* Adore Unix - http://danieroux.com
On 7 July 2011 16:43, Danie Roux <lists+pharo@danieroux.com> 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.
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 <lists+pharo@danieroux.com> 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.
participants (3)
-
Danie Roux -
Henrik Johansen -
Igor Stasenko