Plugin: Sage Job Queue (SJQ) v3

[Slugger]

Originally Posted by Islander

Saturday came around and it seems that it is honoring the OFFDAY settings.

I had another read of the guide and found that all references to OFFHOURS show the time gaps as this:

:OFFHOUR "20-22, 7-10"

were on mine these would be reversed. I copied mine from the medishrink thread as a working setup. Maybe the time blocks have to be presented from higher to lower?

If no one knows for certain I guess I can switch mine around on one of the six clients and see if it makes a difference, or maybe get rid of the one hour block in the morning so that it only has one block each day.

The order shouldn't matter, either way should work. If you can test and let me know your results then I'll take a look at it.

Originally Posted by razrsharpe

@Islander - something just came to me... try

:OFFHOUR "7-8, 16-23"

IIRC i think the 0-23 is the allowable range

Here slugger talks about 23 disabling until 11:59pm

Yes, 0-23 is the allowable range. And a 23 would block until 23:59. Midnight would be hour 0 (not 24).

[KarylFStein]

From what I can tell, my settings are not being saved. The Save button at the bottom of the settings screen isn't clickable. Also, each time I log out of SJQ then back in, there is nothing filled in on the settings page. Before, I thought it was writing the settings anyway, but after having a job failure and not getting an email though SageAlert, I looked closer and saw that my changes to max queue loader sleep and client restrictions didn't seem to be working either. Other things like the password and rules save fine.

I'm using SJQ 3.0.1.704 and Java 1.6.0_19, and tested IE8 on Win7 64 and WinXP.

[Slugger]

Originally Posted by KarylFStein

From what I can tell, my settings are not being saved. The Save button at the bottom of the settings screen isn't clickable. Also, each time I log out of SJQ then back in, there is nothing filled in on the settings page. Before, I thought it was writing the settings anyway, but after having a job failure and not getting an email though SageAlert, I looked closer and saw that my changes to max queue loader sleep and client restrictions didn't seem to be working either. Other things like the password and rules save fine.

I'm using SJQ 3.0.1.704 and Java 1.6.0_19, and tested IE8 on Win7 64 and WinXP.

I've had various reports of this problem in the past, but have never been able to reproduce it locally so I've never been able to track it down. I suggest you try Firefox or Chrome and see if that allows you to load/save settings.

[Islander]

I changed the end of the range on all clients to 23 instead of 24.

As a test I commented out the OFFDAY on one of the clients which leaves only the OFFHOUR to be dealt with as a condition. The current time is within the blocked range and the client has not been assigned any of the stacks sitting in the active que, so far so good. I guess that having 24 (or any erroneous entry on the line) was causing it to ignored [there no errors related to this listed anywhere that I could find]. Hopefully come Monday everything will run as it is supposed to. Thanks for the help.

[Slugger]

Originally Posted by Islander

I changed the end of the range on all clients to 23 instead of 24.

As a test I commented out the OFFDAY on one of the clients which leaves only the OFFHOUR to be dealt with as a condition. The current time is within the blocked range and the client has not been assigned any of the stacks sitting in the active que, so far so good. I guess that having 24 (or any erroneous entry on the line) was causing it to ignored [there no errors related to this listed anywhere that I could find]. Hopefully come Monday everything will run as it is supposed to. Thanks for the help.

Just took a peek at the code and indeed if you used 24 then it would have been rejected (valid range is 0-23 for hour). There should have been error messages in the sjq.log file alerting you of this:

Range must be between 0 and 23!

You should have seen this in the error logs each time a client connected to the server with an invalid hour value.

[Islander]

Yes now that you mention it I saw it but thought it had to do with the number of resources. You live you learn, making a note on my Sjq bible .

[Fuzzy]

the error text seems to need some further clarification, something like:

Error in :OFFHOUR - Range must be between 0 and 23!

[Taddeusz]

Yea, if you've been in the military you'd know that there is no 24:00. Midnight is 00:00.

[bialio]

Hey Slugger - great GREAT tool. I've known it was around forever, just never thought I needed it!

Question about the moving airings - when a show is moved, do all the artifacts that exist with it get moved also? I'm thinking .edl files mainly.

btl.

[Slugger]

Originally Posted by bialio

Hey Slugger - great GREAT tool. I've known it was around forever, just never thought I needed it!

Question about the moving airings - when a show is moved, do all the artifacts that exist with it get moved also? I'm thinking .edl files mainly.

btl.

All artifacts are moved automatically as well.

[tchapin]

Hey guys,

I was thinking that it might be a good idea to have a separate thread where people can look / post for SJQ server and client recipes.

Anyone interested?

Todd

[Fuzzy]

Originally Posted by tchapin

Hey guys,

I was thinking that it might be a good idea to have a separate thread where people can look / post for SJQ server and client recipes.

Anyone interested?

Todd

Just go ahead and make one.. :-)

[bialio]

Is there a way for SJQ to realize that a job it has in the queue is no longer valid and clear it out?

For instance, if there isn't any client available for a job and then the underlying media file is deleted - it seems like the job just hangs in the queue forever.

I'm seeing this with a job that I don't have any clients configured for at the moment - I suspect if it tried to run one on a non-existent file it would clear out.

btl.

[Slugger]

Originally Posted by bialio

Is there a way for SJQ to realize that a job it has in the queue is no longer valid and clear it out?

For instance, if there isn't any client available for a job and then the underlying media file is deleted - it seems like the job just hangs in the queue forever.

I'm seeing this with a job that I don't have any clients configured for at the moment - I suspect if it tried to run one on a non-existent file it would clear out.

btl.

If there is no configured client for a task type then the task will sit in the queue forever - that's by design because eventually a client configured for that task type might call home and get assigned the task. You can clear items out of the queue manually by clicking on them.

When a task is about to be assigned to a client, the server ensures that the media file still exists. If it doesn't then the task is silently dropped from the queue (and the task is not assigned to the client).

[bialio]

So I understand what you are saying, but I think a periodic check by the server for tasks that are in the queue that no longer have a media file would not defeat your intention, and keep the queue a little cleaner.

btl.

[Slugger]

Originally Posted by bialio

So I understand what you are saying, but I think a periodic check by the server for tasks that are in the queue that no longer have a media file would not defeat your intention, and keep the queue a little cleaner.

btl.

Hmm... I think we already have that. Presumably a task whose media file has been deleted will be assigned to a client within 5 minutes of being added to the queue (because, by default, task clients call the server every 5 minutes looking for work to do). So basically every 5 minutes (or so, depending on your task client config) tasks with deleted media files will be removed from the queue. The exception to this rule is tasks that have no clients configured to run them. Those will be stuck in the queue indefinitely. I can see the argument for a "QueueCleaner" thread that goes in and wipes these out for you, but on the other hand, I like leaving them in the queue as a reminder to users that they may have something wrong in their setup (namely, they've queued tasks that have no chance of being consumed by a task client, usually due to a typo in the ruleset or the client config).

[Fuzzy]

Originally Posted by Slugger

Hmm... I think we already have that. Presumably a task whose media file has been deleted will be assigned to a client within 5 minutes of being added to the queue (because, by default, task clients call the server every 5 minutes looking for work to do). So basically every 5 minutes (or so, depending on your task client config) tasks with deleted media files will be removed from the queue. The exception to this rule is tasks that have no clients configured to run them. Those will be stuck in the queue indefinitely. I can see the argument for a "QueueCleaner" thread that goes in and wipes these out for you, but on the other hand, I like leaving them in the queue as a reminder to users that they may have something wrong in their setup (namely, they've queued tasks that have no chance of being consumed by a task client, usually due to a typo in the ruleset or the client config).

Or a change to their setup that no longer includes said task. I think this is the situation he's trying to cover.

[Slugger]

Originally Posted by Slugger

Hmm... I think we already have that. Presumably a task whose media file has been deleted will be assigned to a client within 5 minutes of being added to the queue (because, by default, task clients call the server every 5 minutes looking for work to do). So basically every 5 minutes (or so, depending on your task client config) tasks with deleted media files will be removed from the queue. The exception to this rule is tasks that have no clients configured to run them. Those will be stuck in the queue indefinitely. I can see the argument for a "QueueCleaner" thread that goes in and wipes these out for you, but on the other hand, I like leaving them in the queue as a reminder to users that they may have something wrong in their setup (namely, they've queued tasks that have no chance of being consumed by a task client, usually due to a typo in the ruleset or the client config).

Originally Posted by Fuzzy

Or a change to their setup that no longer includes said task. I think this is the situation he's trying to cover.

Ok, in that case, clear the entire active queue (two clicks) and manually trigger a run of the QueueLoader. I guess to sum up, I don't see a need to have another thread running in the background for this specific task.

[Fuzzy]

haven't bug reported it, but in my experience, it's a LOT more than 2 clicks to clear the queue. When I choose clear all, it clears maybe 75% of the queue... each time... so it's one of those things where I'm stepping 75% closer to the door each time.. takes a while to get through...

[Slugger]

Originally Posted by Fuzzy

haven't bug reported it, but in my experience, it's a LOT more than 2 clicks to clear the queue. When I choose clear all, it clears maybe 75% of the queue... each time... so it's one of those things where I'm stepping 75% closer to the door each time.. takes a while to get through...

Yeah, that's a bug (please open a ticket for it b/c I keep forgetting to look at it). One click actually does wipe the queue, the bug is simply with the UI refreshing before it receives the updated queue listing from the server and therefore loading stale/partial data.