Mailing List Archive: bric_queued, publish

bric_queued, publish_another() and the queue

Sep 6, 2011, 2:57 PM

Post #1 of 4 (2035 views)

Hi everybody,

I've been having some trouble with publish_another() in a way that
reminds me strongly of this thread:

http://www.gossamer-threads.com/lists/bricolage/users/39682

Here's how to reproduce my problem:

1. User schedules a publish of a story.
2. bric_queued executes the publish.
3. publish_another() jobs that SHOULD be scheduled in step 2 do not
appear in the job queue.
4. publishing the same story by mod_perl ("now" rather than scheduled,
or via bric_soap) DOES add the expected jobs to the queue.

The nutty thing is that if you repeat steps 1-3, and then have
bric_queued publish something whose template manually calls
flush_another_queue(), all the expected jobs get magically scheduled.

The problem is that if bric_queued handles the initial publish, the
another_queue only gets flushed if you intervene manually.

Obviously this is connected to the
one-burner-doesn't-know-enough-about-the-other-one issue. I see how
Nick's fix can help, but I don't see an easy way to avoid manually
flushing the queue. Can anybody suggest anything?

Thanks so much,

Bret

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

Re: bric_queued, publish_another() and the queue [ In reply to ]

david at kineticode

Sep 6, 2011, 3:57 PM

Post #2 of 4 (1954 views)

Permalink

On Sep 6, 2011, at 2:57 PM, Bret Dawson wrote:

> Hi everybody,
>
> I've been having some trouble with publish_another() in a way that
> reminds me strongly of this thread:
>
> http://www.gossamer-threads.com/lists/bricolage/users/39682
>
> Here's how to reproduce my problem:
>
> 1. User schedules a publish of a story.
> 2. bric_queued executes the publish.
> 3. publish_another() jobs that SHOULD be scheduled in step 2 do not
> appear in the job queue.
> 4. publishing the same story by mod_perl ("now" rather than scheduled,
> or via bric_soap) DOES add the expected jobs to the queue.
>
> The nutty thing is that if you repeat steps 1-3, and then have
> bric_queued publish something whose template manually calls
> flush_another_queue(), all the expected jobs get magically scheduled.
>
> The problem is that if bric_queued handles the initial publish, the
> another_queue only gets flushed if you intervene manually.

So, flush_another_queue() isn't getting called by bric_queued? Hrm…I see that it called it only for publish jobs, as opposed to distribution jobs. Maybe put some debugging statements in bric_queued to see if it's getting called when it ought to be?

> Obviously this is connected to the
> one-burner-doesn't-know-enough-about-the-other-one issue. I see how
> Nick's fix can help, but I don't see an easy way to avoid manually
> flushing the queue. Can anybody suggest anything?

I don't see how this is related to the one-burner-doesn't-know-enough-about-the-other-one issue. But then I probably don't properly understand the issue.

Best,

David

Re: bric_queued, publish_another() and the queue [ In reply to ]

bret at pectopah

Sep 6, 2011, 5:55 PM

Post #3 of 4 (1954 views)

Permalink

Hi David,

> So, flush_another_queue() isn't getting called by bric_queued? Hrmâ€¦I see that it called it only for publish jobs, as opposed to distribution jobs. Maybe put some debugging statements in bric_queued to see if it's getting called when it ought to be?

I think the problem is that the burner object instantiated for flushing
inside bric_queued is a fresh one each time the queue gets checked.

Somehow, though, the previous burner hangs around inside the process, so
if bric_queued runs into a flush_another_queue() statement in the course
of just publishing, everything that's been piling up inside that burner
pours out into the real job queue.

I'm out on a limb here, but bric_queued seems to persist burner objects
in a way that mod_perl does not. That is, on what should be a fresh
burn, notes and the another_queue from a previous burn will still hang
around. (Setting templates to throw errors based on the values of
certain $burner->notes confirms this.)

It's almost as if the cleanup that happens at the end of a mod_perl burn
does not happen under bric_queued.

I'm not sure how to start trying to tidy things up, but I'd be grateful
for ideas.

In over my head, mostly,

Bret

> I don't see how this is related to the one-burner-doesn't-know-enough-about-the-other-one issue. But then I probably don't properly understand the issue.
>
> Best,
>
> David
>
>
>

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

Re: bric_queued, publish_another() and the queue [ In reply to ]

david at kineticode

Sep 6, 2011, 8:32 PM

Post #4 of 4 (1950 views)

Permalink

On Sep 6, 2011, at 5:55 PM, Bret Dawson wrote:

> I think the problem is that the burner object instantiated for flushing
> inside bric_queued is a fresh one each time the queue gets checked.

No, flush_another_queue is a class method called like this:

Bric::Util::Burner->flush_another_queue;

> Somehow, though, the previous burner hangs around inside the process, so
> if bric_queued runs into a flush_another_queue() statement in the course
> of just publishing, everything that's been piling up inside that burner
> pours out into the real job queue.

Yeah, flush_another_queue() will not be called until all publish jobs have been processed. So if you have a bunch of them, it will take a little while.

> I'm out on a limb here, but bric_queued seems to persist burner objects
> in a way that mod_perl does not. That is, on what should be a fresh
> burn, notes and the another_queue from a previous burn will still hang
> around. (Setting templates to throw errors based on the values of
> certain $burner->notes confirms this.)

Hrm. The code is pretty much the same. Notes a copied so that they always get passed to the burner created when a flushed job publishes, but unless your template sticks $burner into its own notes, the burner itself should not persist.

> It's almost as if the cleanup that happens at the end of a mod_perl burn
> does not happen under bric_queued.

It does. They work pretty much the same way.

> I'm not sure how to start trying to tidy things up, but I'd be grateful
> for ideas.

Nor am I, but if you think there's a bug and can describe a simple way to replicate it, please do file a bug report!

Best,

David