What is the meaning of the below sharepoint 2007 log?
Log:
The previous instance of the timer job 'Config Refresh', id '{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}' for service '{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}' is still running, so the current instance will be skipped. Consider increasing the interval between jobs.
Means a job is schedule to run, say, every 30 minutes, but when the next one was going to run the previous was still running so it could not start and was skipped.
Related
I’m considering pg-boss for running and distributing event-based jobs between the instances of the same service. One of my use cases, apart from event-based, is scheduled jobs. Some of them can take a while and continue running until it’s time to trigger the next invocation - e.g. a job is set to run every 5 minutes but it can take e.g. 8 to complete. In such case I need the system to realize that the previous run is still in progress and not trigger the same job while the previous invocation of it is still in progress, using the example of every 5 minutes and a job taking 8 minutes - I’d like sth like the following to happen:
13:00 job triggered
13:05 job still runs, system sees it and doesn’t trigger once more even though it’s time
13:08 job done
13:10 next job run triggered
Is there an elegant way to achieve it with pg-boss without implementing my own locking mechanism?
I see on the scheduled script deployment screen on Netsuite, the Repeat dropdown starts with a minimum of every 15 minutes. Can the interval be shortened somehow?
The interval of scheduled scripts cannot be shortened to less than 15 minutes.
What you can do is set up a Suitelet that triggers the scheduled script to start. Once you get the External URL of the Suitelet you can plug it into an external cronjob service such as https://cron-job.org and set it to run every 3 minutes.
Note that the scheduled script would be put on a queue either way so it may not start immediately after.
The answer would be No. I think they are trying to prevent choking the queue so they only allow 15mins.
In my code i run a cron job which is run for every five seconds, and I've been getting the same WARNING ever since.
this is the api that i used:
sched.add_cron_job(test_3, second="*/5")
And I get a warning:
WARNING:apscheduler.scheduler:Execution of job "test_3 (trigger: cron[second='*/5'], next run at: 2013-11-28 15:56:30)" skipped: maximum number of running instances reached (1)
I tried giving time gap of 2 minutes it doesn't solve the issue.....
Help me in overcoming this issue..
I used the proc.terminate() to stop the execution of my method. So that the instance of the 1st thread is terminated before a new thread could start again.
Also provide a timing mechanism to complete your process well within the scheduled time say within a minute, hour or day etc. In my application i used *sleep(in_seconds)* for providing the timing mechanism.
I had a similar problem, and it turned out it was just your job 'test_3' lasting too long, more then 5 secs (or 2 minutes as you tried).
APScheduler is trying to re-execute you job, but the previous one is still running.
At SharePoint Saturday in Lisle, IL this weekend, Robert Bogue said there's a difference between active and running workflows. I've looked on the web, but can someone clarify?
If I can have up to millions of active workflows on the server, why can I only have 15 or so running workflows per server?
Yes, there is a difference:
"Running" Workflows are all which currently are doing something (i.e. executing an activity).
"Active" Workflows are simply all which are "running" but currently are not doing anything - e.g. waiting for OnItemChanged or DelayActivity.
The key to understand this is WorkflowEventDeliveryThrottle (here for SP2007, because the documentation for 2010 doesn't exist). The standard value for this is property is 15. That means that there are only 15 concurrent workflow which can run at the same time. After this limit is reached the workflows get queued to the OWSTimer which executes the workflows after some arbitrary time (I think the workflow timer job is set to every 5 minutes).
This Throttle can be changed by using stsadm (AFAIK Powershell doesn't work - you can change the property via code of course setting SPWebService.WorkflowEventDeliveryThrottle):
stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv "20"
Now the maximum number of "running" workflows (better would be "maximum number of workflow events that can be processes simultaneously") would be 20. See some other SO post where someone plays with the parameter.
There is a nice technical blog post to understand Workflow Event Processing: About the “workflow-eventdelivery-throttle” parameter.
Similar to the throttle is the WorkflowEventDeliveryBatchSize which denotes the maximum number of workflow events that are processed in a batch.
Summary:
You can have thousands of active workflows, e.g. all waiting for the workflow item to be changed. They are not running, not finished - simply active.
There is a limited number of workflow events that can be processed at the same time (you called it "running" workflows)
You could also have thousands of running workflows, e.g. all of them might get triggered by a delay activity set to 5 minutes, but only a limited number of them is running simultaneously, the rest of them gets queued for later execution.
I'm currently developing on a project which uses some TimerJobs. One of the jobs should check the MySites of some special users about every 2 minutes. So I create a SPMinuteSchedule object and set the BeginSecond property to 0 and the Interval property to 2. I think the use of both properties seem to be obvious but I'm not really sure how to interpret the EndSecond property.
If EndSecond is set to 30 and BeginSecond to 0, does it mean that the Timer Service will start the job some where within these 30 seconds and the job takes as long as it needs to execute its code? Or does it mean that the job can only run for 30 seconds? What happens if the code executed within the Execute() method needs more time to complete?
Whatever might be the answer, the property's name "EndSecond" was not chosen very well.
Refer to this post for more details to re-iterate below is the info extract from the Post
Notice how the schedule is set for the timer job. The SPMinuteSchedule.BeginSecond property and the SPMinuteSchedule.EndSecond property specify a start window of execution. The SharePoint Timer service starts the timer job at a random time between the BeginSecond property and the EndSecond property. This aspect of the timer service is designed for expensive jobs that execute on all servers in the farm. If all the jobs started at the same time, it could place an unwanted heavy load on the farm. The randomization helps spread the load out across the farm.