http://www.perlmonks.org?node_id=1026052


in reply to [solved] Parallel::ForkManager memory mixup?

If that is really your code, and $ff_port is the same for all Firefox instances, you will only be using one instance, and I would expect such mixups.
  • Comment on Re: Parallel::ForkManager memory mixup?

Replies are listed 'Best First'.
Re^2: Parallel::ForkManager memory mixup?
by Anonymous Monk on Mar 29, 2013 at 02:11 UTC

    No this was just pseudo code to try to set an example. I have pre-created 64 FireFox profiles each with Mozrepl running on a different port. $ff_profile is picked in a DBI call and $ff_port is a sum of that and equals the Mozrepl setting.

    I've watched it run. It visually appears as if it is running perfectly. I've limited the number of forks to 25 (5x5) and WWW::Mechanize::Firefox appears to do every method properly. Except that when a set of forks goes to work on cases with the same $url, the $html for each fork is a jumble of the $html of other forks. This result in a temporary html with a mix of case details, which end up in the proper PDF.
[reply]
Re^2: Parallel::ForkManager memory mixup?
by ground0 (Novice) on Mar 29, 2013 at 02:19 UTC

    I update the pseudo code to address the fact I am indeed using multiple unique instances/profiles of FireFox.

    Tonight I'm going to run a test where I write the temp HTML file immediately after each $html = $mech->content; and see if that has any effect.
[reply]
[d/l]

      Didn't effect anything, meh. :(

      If anyone has a recommended test URL with a few different elements to grab I can tune up the pseudo-code above into something runnable that replicates the issue (assuming this is interesting enough hah).

[reply]

        So I woke up this morning and tried this kludge:

        $temp = $mech->uri;
(undef, $uri) = split (/(\?.*)/, $temp);

        [download]
        I next concatenate session ID in $uri with $url: 
        $url .= $uri;

        [download]

        Now when I $mech->get($url); etc. and follow with $html = $mech->content; etc. my temporary HTML has proper snippet per fork child!

        At Corion's request I did some more debugging, and with FireBug plugin I found this to be an edge case. When a site issues a default, non-random session ID on loading a page, and then links to itself without passing a real session ID... the result is each fork that goes to work on the same offending URL gets jumbled on the next $mech->get($url);

        I'm going to mark this solved since each fork was getting the same default fake session ID, and my kludge should be adaptable to any site doing this. With the obvious caveat being you'll need to $mech->get() something that issues you a valid session ID prior to the kludge!
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom