FAQ
I have a timing/configuration issue, and any pointers would be welcome.

The problem: how to handle configuration/system errors by fallback to an
error page.

* I am using Catalyst authentication, but sometimes the database used
for session storage cannot be connected. Under these circumstances, I
want an error page which can be used to display an error suitable for a
system administrator
* The application starts fine, because it does not attempt to connect
initially
* When a request starts, the session system fails during the prepare
stage - calling stuff in Catalyst::Plugin::Session::Store::Delegate, and
usually get_session_data
* The application never gets to finalize, so nothing is ever sent to the
engine - this is the logic in handle_request

Where and how is it best to handle this?

I could do some of this before the first request, and I considered
hacking which controllers were active since I can do that during the
setup stage, but this is probably too late, since by then all the
plugins are set up, and this is where the session management is set.

Alternatively, I could do some work during the request cycle, but it is
not obvious where in the cycle you got to, which makes it hard to decide
whether you can generate an error.

I could just be missing some documentation: maybe this is covered but I
haven't been able to find it.

--S
--
Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100830/a9e485d8/attachment.htm

Search Discussions

  • Eden Cardim at Aug 31, 2010 at 10:03 am
    "Stuart" == Stuart Watt writes:
    Stuart> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
    Stuart> Transitional//EN"> I have a timing/configuration issue, and
    Stuart> any pointers would be welcome.

    Stuart> The problem: how to handle configuration/system errors
    Stuart> by fallback to an error page.

    [snip]

    Stuart> I could just be missing some documentation: maybe this
    Stuart> is covered but I haven't been able to find it.

    Have you read Catalyst::Manual::Cookbook?

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://blog.edencardim.com/ http://www.shadowcat.co.uk/servers/
  • Stuart Watt at Aug 31, 2010 at 1:27 pm

    On 8/31/2010 6:03 AM, Eden Cardim wrote:
    Have you read Catalyst::Manual::Cookbook?
    Yes - that was the first place I looked. Obviously.

    As far as I can tell, from observed behaviour and from inspecting the
    code, an error in the prepare phase does not generate any response. I
    simply get an empty reply. I have checked this using curl as well as a
    browser. Errors later on seem to work fine.

    The Catalyst::Action dispatch method does use the execute wrapper.
    However, I can find no error protection for the prepare phase. Since
    this issue is caused by a plugin failing during that phase, I get no
    error display through the browser. Tried from curl, I get:
    C:\workspace\ARM>curl http://localhost:3000/index
    curl: (52) Empty reply from server
    I suggest this is a serious issue, but I cannot claim to have a strong
    enough grasp of the overall architecture to suggest how to resolve it
    successfully.

    --S

    Stuart Watt
    ARM Product Developer
    Information Balance
    On 8/31/2010 6:03 AM, Eden Cardim wrote:
    "Stuart" == Stuart Watt<swatt@infobal.com> writes:
    Stuart> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
    Stuart> Transitional//EN"> I have a timing/configuration issue, and
    Stuart> any pointers would be welcome.

    Stuart> The problem: how to handle configuration/system errors
    Stuart> by fallback to an error page.

    [snip]

    Stuart> I could just be missing some documentation: maybe this
    Stuart> is covered but I haven't been able to find it.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100831/41c493d5/attachment.htm
  • Bill Moseley at Aug 31, 2010 at 2:08 pm

    On Tue, Aug 31, 2010 at 6:27 AM, Stuart Watt wrote:

    As far as I can tell, from observed behaviour and from inspecting the code,
    an error in the prepare phase does not generate any response. I simply get
    an empty reply. I have checked this using curl as well as a browser. Errors
    later on seem to work fine.
    Even the top-level handle_request is wrapped in an eval, but it tests $@
    instead of the return value of eval like it should. Is it possible
    something is clearing the $@ var?

    It's pretty easy to edit Catalyst.pm to check.



    --
    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100831/7f6f16d6/attachment.htm
  • Stuart Watt at Aug 31, 2010 at 2:50 pm
    Looks like I was wrong in where the error occurred, although the main
    issue is unchanged. The problem is in finalize rather than prepare.
    On 8/31/2010 10:08 AM, Bill Moseley wrote:
    Even the top-level handle_request is wrapped in an eval, but it tests
    $@ instead of the return value of eval like it should. Is it possible
    something is clearing the $@ var?

    It's pretty easy to edit Catalyst.pm to check.
    I hadn't seen the eval return value issue, although you're right. The
    error is reported on the console just fine. The problem is, that is the
    *only* place it is reported. The eval wrapper causes the finalize to be
    partially skipped.

    Here's the stack trace at point of failure (more or less):

    $ = ARM::Model::User::get_session_store_delegate(ref(ARM::Model::User),
    'fbc69cb40a085cae169b26034f64832d12a9c305') called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm' line 56
    $ =
    Catalyst::Plugin::Session::Store::Delegate::get_session_store_delegate(ref(ARM),
    'fbc69cb40a085cae169b26034f64832d12a9c305') called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm' line 40
    $ =
    Catalyst::Plugin::Session::Store::Delegate::session_store_delegate(ref(ARM))
    called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm' line 94
    . =
    Catalyst::Plugin::Session::Store::Delegate::store_session_data(ref(ARM),
    'expires:fbc69cb40a085cae169b26034f64832d12a9c305', 1283271921) called
    from file `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session.pm' line 148
    . = Catalyst::Plugin::Session::_save_session_expires(ref(ARM)) called
    from file `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session.pm' line 106
    . = Catalyst::Plugin::Session::finalize_headers(ref(ARM)) called from
    file `C:/perl/site/5.10.1/lib/Catalyst.pm' line 1762
    $ = Catalyst::finalize(ref(ARM)) called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Compress/Deflate.pm' line 16
    [other plugins here]
    $ = Catalyst::Plugin::Session::PerUser::finalize(ref(ARM)) called from
    file
    `C:/perl/site/5.10.1/lib/MSWin32-x86-perlio/Class/MOP/Method/Wrapped.pm'
    line 48
    ...
    $ = ARM::finalize(ref(ARM)) called from file
    `C:/perl/site/5.10.1/lib/Catalyst.pm' line 1927

    So, the issue is: because I use
    Catalyst::Plugin::Session::Store::Delegate, my model methods are called
    in the finalize. These methods (based on my DBIC model class) die, and
    this drops all feedback, as finalize_headers is never completed and
    finalize_body never called. So I could overcome this by fixing my model
    to never fail - proxying off the DBIC class in some way to fake session
    handling on error. (Although I suspect this might be better part of
    Catalyst::Plugin::Session::Store::Delegate.)

    The problem is: finalize_headers is normally called after
    finalize_error, so even if I detect an error, there seems to be no way
    to go back and display that error. It seems to me that my model code
    ought to be able to fail in a reasonable way and get something displayed.

    --S

    Stuart Watt
    ARM Product Developer
    Information Balance


    --
    Bill Moseley
    moseley@hank.org
    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    <http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=BAC6E2807E.050DF>


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100831/dbe52fd2/attachment.htm
  • Stuart Watt at Aug 31, 2010 at 4:21 pm
    Okay, I managed to rig up something that appears to work. All this
    goes in the main class. The intent is to call validate_components once,
    and use any error it generates as a value for $c->error() in all future
    requests. Any feedback or comments welcome. It could be a little
    cleaner, but any indication about whether the logic is sound would be
    very welcome.

    my $validated = 0;
    my $validation_error;

    sub validate_components {
    my ($c) = @_;
    return if ($validated);
    $validated = 1;

    # Now do the validation. Code that follows should croak if
    something is wrong.
    ...
    }

    around dispatch => sub {
    my ($orig, $c) = @_;
    my $result;
    my $error;
    my $eval_result;

    if (! $validation_error) {
    $eval_result = eval {
    $c->validate_components();
    };
    $error = $@;
    if ($eval_result || ! $error) {
    $result = $c->$orig(@_);
    }
    }

    if ($validation_error || (! $eval_result && $error)) {
    $c->error($validation_error //= $error);
    }
    return $result;
    };


    Stuart Watt
    ARM Product Developer
    Information Balance
    On 8/31/2010 10:50 AM, Stuart Watt wrote:
    Looks like I was wrong in where the error occurred, although the main
    issue is unchanged. The problem is in finalize rather than prepare.
    On 8/31/2010 10:08 AM, Bill Moseley wrote:
    Even the top-level handle_request is wrapped in an eval, but it tests
    $@ instead of the return value of eval like it should. Is it
    possible something is clearing the $@ var?

    It's pretty easy to edit Catalyst.pm to check.
    I hadn't seen the eval return value issue, although you're right. The
    error is reported on the console just fine. The problem is, that is
    the *only* place it is reported. The eval wrapper causes the finalize
    to be partially skipped.

    Here's the stack trace at point of failure (more or less):

    $ =
    ARM::Model::User::get_session_store_delegate(ref(ARM::Model::User),
    'fbc69cb40a085cae169b26034f64832d12a9c305') called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm'
    line 56
    $ =
    Catalyst::Plugin::Session::Store::Delegate::get_session_store_delegate(ref(ARM),
    'fbc69cb40a085cae169b26034f64832d12a9c305') called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm'
    line 40
    $ =
    Catalyst::Plugin::Session::Store::Delegate::session_store_delegate(ref(ARM))
    called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session/Store/Delegate.pm'
    line 94
    . =
    Catalyst::Plugin::Session::Store::Delegate::store_session_data(ref(ARM),
    'expires:fbc69cb40a085cae169b26034f64832d12a9c305', 1283271921) called
    from file `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session.pm' line 148
    . = Catalyst::Plugin::Session::_save_session_expires(ref(ARM)) called
    from file `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Session.pm' line 106
    . = Catalyst::Plugin::Session::finalize_headers(ref(ARM)) called from
    file `C:/perl/site/5.10.1/lib/Catalyst.pm' line 1762
    $ = Catalyst::finalize(ref(ARM)) called from file
    `C:/perl/site/5.10.1/lib/Catalyst/Plugin/Compress/Deflate.pm' line 16
    [other plugins here]
    $ = Catalyst::Plugin::Session::PerUser::finalize(ref(ARM)) called from
    file
    `C:/perl/site/5.10.1/lib/MSWin32-x86-perlio/Class/MOP/Method/Wrapped.pm'
    line 48
    ...
    $ = ARM::finalize(ref(ARM)) called from file
    `C:/perl/site/5.10.1/lib/Catalyst.pm' line 1927

    So, the issue is: because I use
    Catalyst::Plugin::Session::Store::Delegate, my model methods are
    called in the finalize. These methods (based on my DBIC model class)
    die, and this drops all feedback, as finalize_headers is never
    completed and finalize_body never called. So I could overcome this by
    fixing my model to never fail - proxying off the DBIC class in some
    way to fake session handling on error. (Although I suspect this might
    be better part of Catalyst::Plugin::Session::Store::Delegate.)

    The problem is: finalize_headers is normally called after
    finalize_error, so even if I detect an error, there seems to be no way
    to go back and display that error. It seems to me that my model code
    ought to be able to fail in a reasonable way and get something displayed.

    --S

    Stuart Watt
    ARM Product Developer
    Information Balance


    --
    Bill Moseley
    moseley@hank.org >
    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    <http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=BAC6E2807E.050DF>


    _______________________________________________
    List:Catalyst@lists.scsys.co.uk
    Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site:http://dev.catalyst.perl.org/
    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    <http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=339762807E.4BF34>


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100831/c5fe4ab5/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedAug 30, '10 at 8:12p
activeAug 31, '10 at 4:21p
posts6
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase