Mailing List Archive

Hi Zdravko,

On Wed, Feb 29, 2012 at 4:09 AM, Zdravko Balorda
<zdravko.balorda@siix.com>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

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

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

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

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

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