We are using DBMS_PARALLEL_EXECUTE in Oracle 11g R2 as following
scheduled job run a procedure which creates and runs parallel task using package DBMS_PARALLEL_EXECUTE. Sometime scheduled job hangs and is needed to be restarted. And my question is how to properly kill executing parallel task?
Using DBMS_PARALLEL_EXECUTE.DROP_TASK or DBMS_PARALLEL_EXECUTE.STOP_TASK procedures do not help - I can see sessions of task processes (it creates the same amount of new processes as parameter parallel_level of DBMS_PARALLEL_EXECUTE.RUN_TASK). The same with killing scheduled job (dbms_job.remove) and killing job session - task sessions still available.
Found a solution myself. I was concetrated on dbms_job package and related view dba_jobs_running. I found that dbms_job is depreciated package. Oracle (11g) use dbms_scheduler package when run parallel task's jobs. They are visible in dba_scheduler_running_jobs and can be stopped by dbms_scheduler.stop_job. This action also stops upper level job and all related sessions. Also parallel task get status Crashed.
Related
I have ASP.NET Core application and I'm using Quartz.NET for reccuring job which ran my TestMethod() every 60 seconds and it works fine.
I need to run this job sometime manually. How to force Quartz.NET to make next reccuring calling 60 seconds after the manual run?
This is what I need to accomplish:
00:01:00 -> Automatic run of TestMethod();
00:02:00 -> Automatic run of TestMethod();
00:02:10 -> Manual run of TestMethod();
00:03:10 -> Automatic run of TestMethod(); (Note: 60 seconds after last run)
...
Maybe is it possible by the Hangfire library?
I guess you can't do that using Quartz or Hangfire. Schedule-based jobs are not affected by manual runs usually. You may also notice that schedule-based jobs do not take into account the execution time, so it may lead to the situation then you have one job still in progress (from the previous run) and another one started by schedule.
Instead of using simple recurring jobs you can use the following pattern:
Schedule a single execution of your job
Re-schedule completed job at the end of the execution.
It will help you to avoid the situation described above and also it will allow you to schedule next run after manual trigger.
I have an airflow instance that had been running with no problem for 2 months until Sunday. There was a blackout in a system on which my airflow tasks depend and some tasks where queued for 2 days. After that we decided it was better to mark all the tasks for that day as failed and just lose that data.
Nevertheless, now all the new tasks get trigger at the proper time but they are never being set to any state (neither queued nor running). I check the logs and I see this output:
Dependencies Blocking Task From Getting Scheduled
All dependencies are met but the task instance is not running. In most cases this just means that the task will probably be scheduled soon unless:
The scheduler is down or under heavy load
The following configuration values may be limiting the number of queueable processes: parallelism, dag_concurrency, max_active_dag_runs_per_dag, non_pooled_task_slot_count
This task instance already ran and had its state changed manually (e.g. cleared in the UI)
I get the impression the 3rd topic is the reason why it is not working.
The scheduler and the webserver were working, however I restarted the scheduler and still I am having the same outcome. I also deleted the data in mysql database for one job and it is still not running.
I also saw a couple of post that said it is not running because the depens_on_past was set to true and if the previous runs failed, the next one will never be executed. I also checked it and it is not my case.
Any input would be really apreciated.
Any ideas? Thanks
While debugging a similar issue i found this setting: AIRFLOW__SCHEDULER__MAX_DAGRUNS_PER_LOOP_TO_SCHEDULE (or http://airflow.apache.org/docs/apache-airflow/2.0.1/configurations-ref.html#max-dagruns-per-loop-to-schedule), checking the airflow code it seems that the scheduler queries for dagruns to examine (consider to run ti's for), this query is limited to that number of rows (or 20 by default). So if you have >20 dagruns that are in some way blocked (in our case because ti's were on up-for-retry), then it won't consider other dagruns even though these could run fine.
I have a task that's scheduled to run hourly, however it's not being triggered. When I look at theTask Instance Details it says:
All dependencies are met but the task instance is not running. In most cases this just means that the task will probably be scheduled soon unless:
- The scheduler is down or under heavy load
- The following configuration values may be limiting the number of queueable processes: parallelism, dag_concurrency, max_active_dag_runs_per_dag, non_pooled_task_slot_count
- This task instance already ran and had its state changed manually (e.g. cleared in the UI)
If this task instance does not start soon please contact your Airflow administrator for assistance.
If I clear the task in the UI I am able to execute it through terminal but it does not run when scheduled.
Why do I have to manually clear it after every run?
One of the github repository is resource for my pipeline. I have 3 parallel jobs in my concourse pipeline which gets triggered when there is any checkin to the github repository. Other jobs in the pipeline is in sequence. I am having the below issues:
1) I want the pipeline to complete full execution then only start new run. I am using pool resource to make sure the execution completes then only new run is triggered. Is there a better way to resolve it.
2) If there are multiple checkins while the pipeline is in progress then is there a way to only execute pipeline on the last checkin. For example 1st instance of pipeline is running and while the pipeline execution completes there are 6 checkins in the repository. Can the pipeline pick only 6th version of the repos and purge the run for previous five checkins?
using the lock pool resource is almost the perfect option but as you have rightly caught, there will be a trigger for each git commit and jobs will start to queue.
It sounds like you want this pipeline to be serialised. Have you considered serial_groups http://concourse-ci.org/single-page.html#job-serial-groups
We are currently using Apache Mesos with Marathon and Chronos to schedule long running and batch processes.
It would be great if we could create more complex workflows like with Oozie. Say for example kicking of a job when a file appears in a location or when a certain application completes or calls an API.
While it seems we could do this with Marathon/Chronos or Singularity, there seems no readily available interface for this.
You can use Chronos' /scheduler/dependency endpoint to specify "all jobs which must run at least once before this job will run." Do this on each of your Chronos jobs, and you can build arbitrarily complex workflow DAGs.
https://airbnb.github.io/chronos/#Adding%20a%20Dependent%20Job
Chronos currently only schedules jobs based on time or dependency triggers. Other events like file update, git push, or email/tweet could be modeled as a wait-for-X job that your target job would then depend on.