Mailing List Archive: Bricolage: users

optimizing publishing

1 2

View All

Index | Next | Previous | View Threaded

leggn at denison

Feb 29, 2012, 4:55 AM

Post #26 of 31 (468 views)
Permalink

Re: optimizing publishing [In reply to]

Hi Zdravko,

On Wed, Feb 29, 2012 at 4:09 AM, Zdravko Balorda
<zdravko.balorda [at] siix>wrote:

> And, Bulk publish via UI should also schedule jobs under lowest priority.
>>>
>> Why lowest priority?
>>
>
> I consider Bulk Publish to be another way of massive publishing. If forced
> to low priority
> it won't interfere with other people working.
>

This concept was posted in the following feature request:
http://bricolage.lighthouseapp.com/projects/29601/tickets/191. Per the
ticket, I would prefer that Bulk Publish allow the user to select a
priority.

It is a parameter to a $burner->publish, but not to publish_another().
> Maybe it's even
> beter, because of proper handling the default priority. For
> publish_another() it's probably the best to always go with calling job
> priority. If not defined otherwise
> it will be the same as the publishing story priority, anyway.
>

You might take a look at some of the commits on my Bricolage fork in GitHub
(see the "Denison" branch) during April 2011:
https://github.com/nlegg/bricolage/commits/denison for some tips here.
David helped us out with a number of publish priority-related patches, and
I implemented a quick fix so publish_another() calls wouldn't use Bric's
internal queue (discussed here:
http://www.gossamer-threads.com/lists/bricolage/users/39682).

Good luck,
Nick

david at justatheory

Feb 29, 2012, 10:50 AM

Post #27 of 31 (470 views)
Permalink

Re: optimizing publishing [In reply to]

On Feb 29, 2012, at 1:09 AM, Zdravko Balorda wrote:

> It is a parameter to a $burner->publish, but not to publish_another(). Maybe it's even
> beter, because of proper handling the default priority. For publish_another() it's probably the best to always go with calling job priority. If not defined otherwise
> it will be the same as the publishing story priority, anyway.

Right.

> I consider Bulk Publish to be another way of massive publishing. If forced to low priority
> it won't interfere with other people working.

Good point.

> And one more thing about publish another: a new job should be created also if an existing
> job has different priority than the calling job. It probably comes from another queue or
> from UI publish.

That makes sense. You also want to look at the publish time carefully, and make sure it's for the same version of the story/media document. If it's too far in the future, you don't want to update it.

> Occasionally I get an error: Cannot change scheduled time on executing job. This seems to be the price for parallel publishing. It should be extremely rare, though.

Yeah, that ought to be avoidable, or at least possible to catch and ignore.

David

zdravko.balorda at siix

Mar 1, 2012, 1:22 AM

Post #28 of 31 (473 views)
Permalink

Re: optimizing publishing [In reply to]

David E. Wheeler wrote:
>
>> And one more thing about publish another: a new job should be created also if an existing
>> job has different priority than the calling job. It probably comes from another queue or
>> from UI publish.
>
> That makes sense. You also want to look at the publish time carefully, and make sure it's
> for the same version of the story/media document. If it's too far in the future, you don't
> want to update it.

Actually it gets simpler. There is no need for pushing the scheduled time. If a job
exitsts, and it comes from the past, and it has the same priority then there is nothing
to do more.
If not, create a new job for a given business asset. That's all. Bric_queued will handle
the job properly, publishing it at the end.

>
>> Occasionally I get an error: Cannot change scheduled time on executing job.
>> This seems to be the price for parallel publishing. It should be extremely rare, though.
>
> Yeah, that ought to be avoidable, or at least possible to catch and ignore.

And, there are no more such errors. A single database lookup covers for another_queue.
I'm not sure if this also solves the circular publishing problem, though.

Best regards, Zdravko

david at justatheory

Mar 1, 2012, 10:26 AM

Post #29 of 31 (470 views)
Permalink

Re: optimizing publishing [In reply to]

On Mar 1, 2012, at 1:22 AM, Zdravko Balorda wrote:

> Actually it gets simpler. There is no need for pushing the scheduled time. If a job exitsts, and it comes from the past, and it has the same priority then there is nothing
> to do more.

And if it is for the same version of the document (story_instance__id).

> If not, create a new job for a given business asset. That's all. Bric_queued will handle
> the job properly, publishing it at the end.

Sounds good to me. How well does it work with bric_dist_mon? I think it�s the same, yes?

> And, there are no more such errors. A single database lookup covers for another_queue.
> I'm not sure if this also solves the circular publishing problem, though.

Great.

David

zdravko.balorda at siix

Mar 1, 2012, 10:21 PM

Post #30 of 31 (469 views)
Permalink

Re: optimizing publishing [In reply to]

David E. Wheeler wrote:
> On Mar 1, 2012, at 1:22 AM, Zdravko Balorda wrote:
>
>> Actually it gets simpler. There is no need for pushing the scheduled time. If a job exitsts, and it comes from the past, and it has the same priority then there is nothing
>> to do more.
>
> And if it is for the same version of the document (story_instance__id).

Right.

>
>> If not, create a new job for a given business asset. That's all. Bric_queued will handle
>> the job properly, publishing it at the end.
>
> Sounds good to me. How well does it work with bric_dist_mon? I think it�s the same, yes?

I don't use dist_mon really, but it seems it should work. flush_another queue becomes
deprecated, notes are stored with the job as they were in %another_queue. If I'm not
missing something everything should be ok. Is it?

Zdravko

david at justatheory

Mar 2, 2012, 9:11 AM

Post #31 of 31 (460 views)
Permalink

Re: optimizing publishing [In reply to]

On Mar 1, 2012, at 10:21 PM, Zdravko Balorda wrote:

> I don't use dist_mon really, but it seems it should work. flush_another queue becomes
> deprecated, notes are stored with the job as they were in %another_queue. If I'm not
> missing something everything should be ok. Is it?

Don�t know. Are you running all the tests? I think there are some for publishing and publish_another() and flush_queue()�

David

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads