FAQ
Hi,



I'm running Catalyst via the scripts\myapp_server.pl script. I have
never configured it to run under a web server, and perhaps that's the
answer to my question.



The issue is that when I call $c->log(), it doesn't output anything
until the "URL call" completes. This makes it difficult to watch a
long-running process, because I don't see anything until it's done, and
I don't know if it's hung up on something because I can't see the log
output.



Has anyone else experienced this, and found a useful workaround or fix?
Like I said, if I have to run it under Apache or IIS in order for this
to work, I'll do so.



Thanks,

--
Ken Beal
Senior Software Engineer, Build/Release

Cross Country Automotive Services
One Cabot Road
Medford, MA 02155
p: (781) 306-3605
m: (978) 423-8977
e: kbeal@crosscountry-auto.com


Confidentiality Note: This e-mail message and any attachments may contain
confidential or privileged information. If you are not the intended recipient,
please notify me immediately by replying to this message and destroy all
copies of this message and any attachments. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101018/beb11ec7/attachment.htm

Search Discussions

  • Toby Corkindale at Oct 18, 2010 at 11:58 pm

    On 19/10/10 10:46, Ken Beal wrote:
    Hi,

    I?m running Catalyst via the scripts\myapp_server.pl script. I have
    never configured it to run under a web server, and perhaps that?s the
    answer to my question.

    The issue is that when I call $c->log(), it doesn?t output anything
    until the ?URL call? completes. This makes it difficult to watch a
    long-running process, because I don?t see anything until it?s done, and
    I don?t know if it?s hung up on something because I can?t see the log
    output.

    Has anyone else experienced this, and found a useful workaround or fix?
    Like I said, if I have to run it under Apache or IIS in order for this
    to work, I?ll do so.
    Hi Ken,
    You will find the same behaviour when running under a web server.
    ie. Log messages are saved up and then emitted all at once at the end of
    the request.

    I'm pretty sure this is By Design in Catalyst's default logger.

    However there is nothing stopping you from installing a different
    logging module into $c->log. I've used a Syslog one in the past.

    Toby
  • Bill Moseley at Oct 19, 2010 at 12:05 am

    On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal wrote:

    The issue is that when I call $c->log(), it doesn�t output anything until
    the �URL call� completes. This makes it difficult to watch a long-running
    process, because I don�t see anything until it�s done, and I don�t know if
    it�s hung up on something because I can�t see the log output.
    maybe try this: $c->log->_flush;

    Or try: warn "I'm stuck in a loop and the web user is wondering why I'm
    taking so long and will likely hit reload any second now!\n";


    --
    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101018/c6094767/attachment.htm
  • Toby Corkindale at Oct 19, 2010 at 1:54 am

    On 19/10/10 11:05, Bill Moseley wrote:

    On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal wrote:

    The issue is that when I call $c->log(), it doesn?t output anything
    until the ?URL call? completes. This makes it difficult to watch a
    long-running process, because I don?t see anything until it?s done,
    and I don?t know if it?s hung up on something because I can?t see
    the log output.


    maybe try this: $c->log->_flush;

    Or try: warn "I'm stuck in a loop and the web user is wondering why I'm
    taking so long and will likely hit reload any second now!\n";
    As a follow-up to Ken's message..

    If you have long-running processes in a web server, then I suspect you
    are Doing It Wrong.
    (Or, naybe you're not, and have some kind of RPC system under Catalyst,
    in which case ignore what I'm about to say.)

    Can I suggest you look at a different model of serving these
    long-running things to the web users? Consider having them hit a page
    which says "Your request is being processed..", which then kicks off the
    actual work in another process, and returns a token of some sort to the
    user's browser. (eg. Cookie or URI parameter)

    You then have the browser either reload the page (including the token
    mentioned above), or better yet, use javascript to do it in the
    background. You have two options here - first option is for this request
    to get hung on the server, waiting for the process to complete, or you
    can have it return quickly with the status or progress info to display
    in the meantime.
    Once this background request detects the long-running process has
    completed, it then directs the browser to reload, and collects the final
    information.

    This has several advantages.
    1) If the user keeps hitting reload, you can detect their work token,
    and avoid starting more long-running processes.
    2) The user doesn't get stuck with a blank screen and a loading....
    status bar. Instead they can get progress info, or at least a message
    saying "we're working on it, hang in there..."
    3) You don't have your web server tied up with long-running processes,
    holding open sockets and using memory.
    4) Logging for your long-running processes is independent of your web
    server messages.



    So the URLs the user would see would be something like:
    /report/megasize
    # server kicks off background process, redirects user onto..
    /report/megasize?token=d11a1658f614401782e8
    # which says "please wait while we prepare your report".
    # The user's browser waits for completion by polling:
    /report/progress.json?token=d11a1658f614401782e8
    # ..and eventually reloads:
    /report/megasize?token=d11a1658f614401782e8
    # which now displays the contents of their report



    at least, this is the way I think it should be done.

    I'm curious to know how other people approach this issue.

    Also, what do you think about the polling approach vs a (background)
    connection that stays connected waiting for the completion signal?

    Cheers,
    Toby
  • Chris at Oct 19, 2010 at 10:19 pm

    I'm curious to know how other people approach this issue.

    Also, what do you think about the polling approach vs a (background)
    connection that stays connected waiting for the completion signal?
    I've found polling much simpler to implement (and test) as it doesn't
    require anything particularly special on either client or server-side.
    It means a bit more delay - the polling period - before the user gets
    the result, but for our use-case (generating reports and download
    files) this hasn't been an issue. I've seen some stuff suggesting that
    polling leads to higher server load, but again it hasn't been an issue
    in our low-traffic web-apps.

    - Chris
  • Toby Corkindale at Oct 20, 2010 at 12:48 am

    On 20/10/10 09:19, Chris wrote:

    I'm curious to know how other people approach this issue.

    Also, what do you think about the polling approach vs a (background)
    connection that stays connected waiting for the completion signal?
    I've found polling much simpler to implement (and test) as it doesn't
    require anything particularly special on either client or server-side.
    It means a bit more delay - the polling period - before the user gets
    the result, but for our use-case (generating reports and download
    files) this hasn't been an issue. I've seen some stuff suggesting that
    polling leads to higher server load, but again it hasn't been an issue
    in our low-traffic web-apps.
    I still haven't played with Comet-style server-push much. Anyone else
    using it?

    What is support like for either multi-part or partial-update in browsers
    like now?

    Although HTML5 will clean it all up, since it actually defines some
    proper transports. Then we just have to wait for HTML5 support to be
    prevalent! :)

    -Toby
  • Charlie Garrison at Oct 20, 2010 at 1:22 am
    Good afternoon,

    On 20/10/10 at 11:48 AM +1100, Toby Corkindale
    wrote:
    I still haven't played with Comet-style server-push much. Anyone else using it?
    I didn't spend much time looking at comet, but I have been
    looking into BOSH and have determined it will work for us. It
    depends on XMPP though (which we were already doing) so it may
    not be the best fit. Since we've already got XMPP we chose to
    use BOSH for pushing page updates to users. Out Cat app (or
    model within Cat) is just an XMPP client (or will be when I
    finish that part of project). Have a look at Strophe for
    javascript implementation of BOSH; makes the whole thing pretty easy.

    Note, XMPP is not just for chat; it's great for all sorts of
    live/push updates.

    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    ? http://www.ietf.org/rfc/rfc1855.txt
  • Mark Beihoffer at Oct 20, 2010 at 5:06 am
    worked. Thants, guise.

    Mark Beihoffer
    Dragonfly Networks
    mbeihoffer@gmail.com
    mark@dragonfly-networks.com
    (612)508-5128

    On Tue, Oct 19, 2010 at 8:22 PM, Charlie Garrison wrote:

    Good afternoon,


    On 20/10/10 at 11:48 AM +1100, Toby Corkindale <
    toby.corkindale@strategicdata.com.au> wrote:

    I still haven't played with Comet-style server-push much. Anyone else
    using it?
    I didn't spend much time looking at comet, but I have been looking into
    BOSH and have determined it will work for us. It depends on XMPP though
    (which we were already doing) so it may not be the best fit. Since we've
    already got XMPP we chose to use BOSH for pushing page updates to users. Out
    Cat app (or model within Cat) is just an XMPP client (or will be when I
    finish that part of project). Have a look at Strophe for javascript
    implementation of BOSH; makes the whole thing pretty easy.

    Note, XMPP is not just for chat; it's great for all sorts of live/push
    updates.

    Charlie

    --
    � Charlie Garrison ♊ <garrison@zeta.org.au>

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    〠 http://www.ietf.org/rfc/rfc1855.txt


    _______________________________________________
    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/20101020/b150e219/attachment.htm
  • Tomas Doran at Oct 23, 2010 at 5:18 pm

    On 20 Oct 2010, at 01:48, Toby Corkindale wrote:

    What is support like for either multi-part or partial-update in
    browsers like now?
    Almost everything will now do MXHR.

    Have a look at Web::Hippie which abstracts the browser-specifics of
    the actual mechanism away.

    However, each user is going to have a persistent connection to the
    server, and if you're running a traditional forked server (e.g. fcgi,
    mod_perl etc) then that can eat a lot of resources for keeping
    (mostly idle) HTTP connections open..

    Cheers
    t0m
  • Mark Beihoffer at Oct 20, 2010 at 5:05 am
    I tried that and it

    Mark Beihoffer
    Dragonfly Networks
    mbeihoffer@gmail.com
    mark@dragonfly-networks.com
    (612)508-5128

    On Mon, Oct 18, 2010 at 7:05 PM, Bill Moseley wrote:


    On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal wrote:

    The issue is that when I call $c->log(), it doesn’t output anything
    until the “URL call� completes. This makes it difficult to watch a
    long-running process, because I don’t see anything until it’s done, and I
    don’t know if it’s hung up on something because I can’t see the log output.
    maybe try this: $c->log->_flush;

    Or try: warn "I'm stuck in a loop and the web user is wondering why I'm
    taking so long and will likely hit reload any second now!\n";


    --
    Bill Moseley
    moseley@hank.org

    _______________________________________________
    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/20101020/79cca6a0/attachment.htm
  • Ken Beal at Oct 20, 2010 at 2:29 pm
    Thanks Bill! Mark’s response was ambiguous; I can clearly state that calling _flush had the desired effect.



    Very timely, as well; we had an out of memory condition this morning, which we did not have the tail end of the log for. Now that I’d added this, we will next time it happens.



    Thanks again,

    --
    Ken Beal
    Senior Software Engineer, Build/Release

    Cross Country Automotive Services
    One Cabot Road
    Medford, MA 02155
    p: (781) 306-3605
    m: (978) 423-8977
    e: kbeal@crosscountry-auto.com

    From: Mark Beihoffer
    Sent: Wednesday, October 20, 2010 1:06 AM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Logging is not immediate



    I tried that and it


    Mark Beihoffer
    Dragonfly Networks
    mbeihoffer@gmail.com
    mark@dragonfly-networks.com
    (612)508-5128



    On Mon, Oct 18, 2010 at 7:05 PM, Bill Moseley wrote:



    On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal wrote:

    The issue is that when I call $c->log(), it doesn’t output anything until the “URL call� completes. This makes it difficult to watch a long-running process, because I don’t see anything until it’s done, and I don’t know if it’s hung up on something because I can’t see the log output.



    maybe try this: $c->log->_flush;



    Or try: warn "I'm stuck in a loop and the web user is wondering why I'm taking so long and will likely hit reload any second now!\n";





    --
    Bill Moseley
    moseley@hank.org

    _______________________________________________
    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/




    Confidentiality Note: This e-mail message and any attachments may contain
    confidential or privileged information. If you are not the intended recipient,
    please notify me immediately by replying to this message and destroy all
    copies of this message and any attachments. Thank you.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101020/d097ac46/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 18, '10 at 11:46p
activeOct 23, '10 at 5:18p
posts11
users7
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase