Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Bricolage: users

optimizing publishing

 

 

First page Previous page 1 2 Next page Last page  View All Bricolage users RSS feed   Index | Next | Previous | View Threaded


leggn at denison

Feb 29, 2012, 4:55 AM

Post #26 of 31 (949 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 (953 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 (954 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 (951 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 (951 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 (941 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

First page Previous page 1 2 Next page Last page  View All Bricolage users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.