And here bugtracker creation & initialization is postponed up to the moment when request needs to be processed. (Hence bugtracker is created per each request). * This patch a little bit depends on the earlier patch where BugtrackerFactory is implemented.
Regards, Yavor On Tue, Mar 22, 2011 at 01:01, Yavor Nikolov <[email protected]>wrote: > Hi, > > Got some confirmations for Bugzilla - USAGE_MODE_CMDLINE & not being > fork-safe nor thread-safe ( > https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/h-a4WOJZTkY > ) > > * scmbug_bugzilla_usage_mode.patch - explicitly set usage_mode to cmdline > (since it wasn't the default mode before Bugzilla 3.4.1) > * scmbug_tie_stdout_to_trapper.patch - tie stdout to Trapper (this is > alternative/replacement of scmbug_bugzilla_reset_encoding.patch) > > Regards, > Yavor > > > On Sun, Mar 20, 2011 at 18:51, Yavor Nikolov <[email protected]>wrote: > >> Hi, >> >> One more thing towards moving daemonization earlier: Bugzilla is not >> fork-safe. (Not even safe to spawn a child and close the parent immediately >> - database handles are messed up). >> >> Currently we're "lucky" that Bugzilla is using lazy initialization of its >> database handles and that Scmbug is not touching anything which needs >> databae access within init() and init_specific(). I just tried to do so to >> dump some diagnostic info -> and this breaks Scmbug after daemonization (at >> least this is the case with PostgreSQL). >> >> Regards, >> Yavor >> >> >> On Sat, Mar 19, 2011 at 11:56, Yavor Nikolov <[email protected]>wrote: >> >>> OK, that's just kind of workaround until something better is invented. >>> >>> Actually - I think it would be better to tie STDOUT in the same way >>> STDERR is tied >>> >>> There are several things related to this issue: >>> 1) Perl crash in particular circumstances. Root cause I think is Perl bug >>> #41121. >>> - Bug still seems to be open. >>> - In fact I don't think Scmbug needs to get into these circumstances at >>> all. I.e. bug could be workarounded relatively easy: >>> a) either don't "pollute" standard outputs with problematic encodings; >>> and/or >>> b) don't call call fork() AFTER Bugzilla initialization: i.e. Scmbug >>> to daemonize early forking BEFORE loading Bugzilla. >>> >>> 2) Bugzilla is trying to modify STDOUT, STDERR encoding (calling binmode) >>> - No real issue with Bugzilla here - it's just trying to adapt to >>> console (running in USAGE_MODE_CMDLINE). >>> - No straightforward way to skip this yet. (That has been designed for >>> single-threaded console-mode usage). >>> ---- >>> >>> So both 1a) and 1b) seem good idea to implement, though 1a) would be >>> enough (tying STDOUT and noop BINMODE) >>> >>> Regards, >>> Yavor >>> >>> >>> On Mon, Mar 14, 2011 at 01:54, Kristis Makris <[email protected]> wrote: >>> >>>> I don't see how doing anything other than calling a Bugzilla function >>>> is the right thing to do. >>>> >>>> I won't apply this patch. >>>> >>>> On Mon, 2011-03-14 at 01:06 +0200, Yavor Nikolov wrote: >>>> > Hello guys, >>>> > >>>> > Here is a patch for this issue: >>>> > 1) I'm just resetting stdout & stderr encodings to utf8 after Bugzilla >>>> > module has been loaded. >>>> > 2) I'm explicitly setting usage mode to ..CMDLINE just in case. (Th >>>> > other modes which are currently available seem to be less >>>> > appropriate). >>>> > * 3) As I've already suggested - setting SERVER_SOFTWARE doesn't seem >>>> > a good idea: it triggers cgi-specific responses (like http 301 >>>> > Redirect and who knows what). >>>> > >>>> > Regards, >>>> > Yavor >>>> > >>>> > >>>> >>> >>> >> >
scmbug_daemon_late_bugtracker_creation.patch.gz
Description: GNU Zip compressed data
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
