Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
On Thu, Dec 11, 2008 at 12:04 PM, Sergio Salvi sergio.li...@salvi.ca wrote: On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer l...@funkreich.de wrote: On 20.11.2008, at 21:16, Sergio Salvi wrote: I still think the final solution (besides finding a way to make find_or_create() atomic), is to store flash data the session row (either on the same column of session or on a new, dedicated column). Sergio++ FWIW, I rolled my own flash mechanism which does exactly that (store the flash value in the session) and haven't looked back since. I've seen about 3 duplicate entry errors in the last 3 months opposed to several hundreds a week with C::P::Session's flash method. I've committed the flash in session patch, please try it out: http://lists.scsys.co.uk/pipermail/catalyst-dev/2008-December/001573.html I've applied both patches into this branch: http://dev.catalyst.perl.org/svnweb/Catalyst/browse/branches/Catalyst-Plugin-Session/both/ This is supposed to fix: - duplicate key issue when using flash() - session finalization order race condition Please try it out :) Sergio Salvi ___ 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/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
On Thu, Nov 20, 2008 at 4:49 PM, Tobias Kremer l...@funkreich.de wrote: On 20.11.2008, at 21:16, Sergio Salvi wrote: I still think the final solution (besides finding a way to make find_or_create() atomic), is to store flash data the session row (either on the same column of session or on a new, dedicated column). Sergio++ FWIW, I rolled my own flash mechanism which does exactly that (store the flash value in the session) and haven't looked back since. I've seen about 3 duplicate entry errors in the last 3 months opposed to several hundreds a week with C::P::Session's flash method. I've committed the flash in session patch, please try it out: http://lists.scsys.co.uk/pipermail/catalyst-dev/2008-December/001573.html Regards, Sergio Salvi --Tobias ___ 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/ ___ 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/
Re: [Catalyst] Catalyst modperl - child process segmentation fault
On Wed, Dec 10, 2008 at 2:20 PM, Terence Monteiro [EMAIL PROTECTED] wrote: How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? Disabled mod_php5 and tried again. Still get the segfaults. Has anyone else faced this problem, with segmentation faults while running their Catalyst app with mod_perl 2.0.4-4 on apache 2.2.9-10 or 2.2.9-11 on debian? Install DBD::mysql 4.006 or try 4.010. Versions 4.007 and 4.008 caused segfaults exactly like the one you got. The changelog of 4.009 says this bug has been fixed, so you could try 4.010: * Fix to re-enable TAKE_IMP_DATA_VERSION. Still have to ensure DBI version 1.607 or higher But I haven't tried this version yet. 4.006 works fine for me and at that time, the latest was 4.008 so I went back to 4.006. Sergio Salvi ___ 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/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL - new findings
On Fri, Sep 26, 2008 at 3:49 PM, Daniel Westermann-Clark [EMAIL PROTECTED] wrote: On 2008-08-26 09:47:59 +0200, Tobias Kremer wrote: a) Patch Catalyst::Plugin::Session::Store::DBIC to wrap the flash functionality in a transaction (of course, this must be configurable). I've released a new version which includes this functionality: 0.07 Wed Sep 24 17:08:34 EDT 2008 - Code was silently truncating storage to MySQL, rendering the session unreadable. Patched to check DBIx::Class size from column_info (if available) - Wrap find_or_create calls in a transaction to (hopefully) avoid issues with duplicate flash rows Thanks for the patch, but unfortunately it does not solve the problem with duplicate flash rows, because just wrapping find_or_create() inside a txn_do() doesn't make it an atomic operation (because find_or_create is simply not atomic, as pointed out in this thread). The biggest problem is that the flash row gets deleted from the database when flash is empty, so we're always doing insert delete and triggering the find_or_create problem. I have a template to display error messages that is included by almost every page, and these error messages are stored in flash. So every request that does *not* have anything in flash and does not add anything to flash, basically inserts the row (because my template did something like FOREACH c.flash.my_error_messages), leaves the flash empty and then decides to delete it. Make this happen too quickly and you're hitting this problem very often (like we were on our application). I've modified Session.pm not to delete flash, even when it's empty. The problem is gone, but it's a temporary hack I did to my local version of Session.pm. I still think the final solution (besides finding a way to make find_or_create() atomic), is to store flash data the session row (either on the same column of session or on a new, dedicated column). I could try coming up with a patch + tests for this. Thoughts? Thanks, Sergio Salvi ___ 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/
[Catalyst] Re: Race condition in Catalyst::Plugin::Session and Catalyst::Engine::Apache (possibly other engines too)
On Wed, Sep 10, 2008 at 6:59 PM, Sergio Salvi [EMAIL PROTECTED] wrote:
There is a race condition in C::P::Session when using
C::Engine::Apache (and probably other engines too):
I have a simple controller action (let's call it /save) that gets data
submitted from an HTML form via POST, process that request, stores
some stuff in the session and flash and then redirects with HTTP 303
to another action (/display).
The /display action then displays the regular submit successful
message that was set on the previous action by using $c-flash. The
problem is that the browser is GETting /display before /save is
finished storing the session and flash rows in the database. Then, of
course, /display thinks nothing has happened and doesn't display the
data from flash.
After a bunch of debugging and stack traces :), I figured out the
problem is that C::P::Session's finalize() calls $c-NEXT::finalize()
before calling $c-finalize_session, so
C::Engine::Apache-finalize_body() gets executed *before* the session
is flushed in the database, making the browser access /display even
though the session may not be stored yet:
# From C::P::Session:
sub finalize {
my $c = shift;
my $ret = $c-NEXT::finalize(@_);
# then finish the rest
$c-finalize_session;
return $ret;
}
I've solved this problem by extending C::P::Session and changing the
behaviour of finalize(), like this:
###
package Catalyst::Plugin::MySession;
use base qw/Catalyst::Plugin::Session/;
use strict;
use warnings;
sub finalize {
my $c = shift;
$c-finalize_session;
my $ret = $c-NEXT::finalize(@_);
return $ret;
}
1;
###
But I realize this may create problems later on if other plugins have
finalize() that modify stuff in the session or flash, because then it
would be too late to modify it as the session/flash was already
stored.
How can I tell Catalyst to call the Engine's finalize() method *last*,
after every other finalize() has been called?
I think that would be the safest way to fix this problem. It is
probably related to C3 MRO, but I'm not sure how to approach this
within Catalyst.
Thank you!
Sergio Salvi
PS: My environment is:
Debian 4.0, stock perl 5.8.8, Apache 2.2.3 with mod_perl 2.0.2
(prefork, no reverse proxy at this moment), MySQL 5.0.32 with InnoDB
and the latest version of major Perl modules:
Catalyst 5.7.014
C::P::Session 0.19
C::P::Session::Store::DBIC 0.06
Bump :)
All I'd like to know is this:
How can I tell Catalyst to call the Engine's finalize() method *last*,
after every other finalize() has been called?
Thanks,
Sergio
___
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/
[Catalyst] Race condition in Catalyst::Plugin::Session and Catalyst::Engine::Apache (possibly other engines too)
There is a race condition in C::P::Session when using
C::Engine::Apache (and probably other engines too):
I have a simple controller action (let's call it /save) that gets data
submitted from an HTML form via POST, process that request, stores
some stuff in the session and flash and then redirects with HTTP 303
to another action (/display).
The /display action then displays the regular submit successful
message that was set on the previous action by using $c-flash. The
problem is that the browser is GETting /display before /save is
finished storing the session and flash rows in the database. Then, of
course, /display thinks nothing has happened and doesn't display the
data from flash.
After a bunch of debugging and stack traces :), I figured out the
problem is that C::P::Session's finalize() calls $c-NEXT::finalize()
before calling $c-finalize_session, so
C::Engine::Apache-finalize_body() gets executed *before* the session
is flushed in the database, making the browser access /display even
though the session may not be stored yet:
# From C::P::Session:
sub finalize {
my $c = shift;
my $ret = $c-NEXT::finalize(@_);
# then finish the rest
$c-finalize_session;
return $ret;
}
I've solved this problem by extending C::P::Session and changing the
behaviour of finalize(), like this:
###
package Catalyst::Plugin::MySession;
use base qw/Catalyst::Plugin::Session/;
use strict;
use warnings;
sub finalize {
my $c = shift;
$c-finalize_session;
my $ret = $c-NEXT::finalize(@_);
return $ret;
}
1;
###
But I realize this may create problems later on if other plugins have
finalize() that modify stuff in the session or flash, because then it
would be too late to modify it as the session/flash was already
stored.
How can I tell Catalyst to call the Engine's finalize() method *last*,
after every other finalize() has been called?
I think that would be the safest way to fix this problem. It is
probably related to C3 MRO, but I'm not sure how to approach this
within Catalyst.
Thank you!
Sergio Salvi
PS: My environment is:
Debian 4.0, stock perl 5.8.8, Apache 2.2.3 with mod_perl 2.0.2
(prefork, no reverse proxy at this moment), MySQL 5.0.32 with InnoDB
and the latest version of major Perl modules:
Catalyst 5.7.014
C::P::Session 0.19
C::P::Session::Store::DBIC 0.06
___
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/
