It seems lack of resources due to other running jobs in the same queue. Is there any work around to priorities some jobs over running jobs in tsame queue to execute first?
If you're using YARN to schedule jobs, there is no way to preempt jobs within the same queue. A workaround is to move the jobs to another queue if you need to free up resources in a particular queue.
YARN also supports reservations (mentioned in YARN-1051 YARN Admission Control/Planner: enhancing the resource allocation model with time.) which allows you to reserve vcores for future jobs. This came in 2.6.0 but most of the documentation is in 2.8.0.
Reservation System
Resource Manager REST APIs for Reservations
Related
I have some code execution which will scheduled many jobs at different date-time. So overall I will have lot of jobs to run at specific date-time. I know that there is Spring Scheduler which will execute a job at some time period, but it does not schedule a job dynamically. I can use ActiveMQ with timed delivery or Quartz for my purpose but looking for a little suggestion. Shall I use Quartz or ActiveMQ timed/delayed delivery or something else.
There is another alternative as well in Executor service with timed execution, but if application restarts then the job will be gone I believe. Any help will be appreciated.
While you can schedule message delivery in ActiveMQ it wasn't designed to be used as a job scheduler whereas that's exactly what Quartz was designed for.
In one of your comments you talked about wanting a "scalable solution" and ActiveMQ won't scale well with a huge number of scheduled jobs because the more messages which accumulate in the queues the worse it will perform since it will ultimately have to page those messages to disk rather than keeping them in memory. ActiveMQ, like most message brokers, was meant to hold messages for a relatively short amount of time before they are consumed. It's much different than a database which is better suited for this use-case. Quartz should scale better than ActiveMQ for a large number of jobs for this reason.
Also, the complexity of the jobs you can configure in Quartz is greater. If you go with ActiveMQ and you eventually need more functionality than it supports then that complexity will be pushed down into your application code. However, there's a fair chance could simply do what you want with Quartz since it was designed as a job scheduler.
Lastly, a database is more straight-forward to maintain than a message broker in my opinion and a database is also easy to provision in most cloud providers. I'd recommend you go with Quartz.
You can start by using a cron-expression in order to cover the case when your application will restart. The cron-expression can be stored in the properties file. Also, when your application will be scheduled, you can restart or reschedule your job programatically by creating a new job instance with another cron-expression for example.
I had a question regarding the usage of Pacemaker. We have a currently running Storm cluster on 1.0.2 and are in the process of migrating it to 1.2.2. We also use KafkaSpout to consume data from the KAfka topics.
Now, since this release in for Kafka 0.10 +, most of the load from ZK would be taken off since the offsets won't be stored in ZK.
Considering this, does it make sense for us to also start looking at Pacemaker to reduce load further on ZK?
Our cluster has 70+ supervisor and around 70 workers with a few unused slots. Also, we have around 9100+ executors/tasks running.
Another question I have is regarding the heartbeats and who all send it to whom? From what I have read, workers and supervisors send their heartbeats to ZK, which is what Pacemaker alleviates. How about the tasks? Do they also send heartbeats? If yes, then is it to ZK or where else? There's this config called task.heartbeat.frequency.secs which has led me to some more confusion.
The reason I ask this is that if the task level heartbeats aren't being sent to ZK, then its pretty evident that Pacemaker won't be needed. This is because with no offsets being committed to ZK, the load would be reduced dramatically. Is my assesment correct or would Pacemaker be still a feasible option? Any leads would be appreciated.
Pacemaker is an optional Storm daemon designed to process heartbeats from workers, which is implemented as a in-memory storage. You could use it if ZK become a bottleneck because the storm cluster scaled up
supervisor report heartbeat to nimbusthat it is alive, used for failure tolerance, and the frequency is set via supervisor.heartbeat.frequency.secs, stored in ZK.
And worker should heartbeat to the supervisor, the frequency is set via worker.heartbeat.frequency.secs. These heartbeats are stored in local file system.
task.heartbeat.frequency.secs: How often a task（executor) should heartbeat its status to the master(Nimbus), it never take effect in storm, and has been deprecated for Storm v2.0 RPC heartbeat reporting
This heartbeat stats what executors are assigned to which worker, stored in ZK.
Why chronos is called as distributed and fault-tolerant scheduler? As per my understanding there is only one scheduler instance running that manages job schedules.
As per Chronos doc, internally, the Chronos scheduler main loop is quite simple.
The pattern is as follows:
Chronos reads all job state from the state store (ZooKeeper)
Jobs are registered within the scheduler and loaded into the job graph for tracking dependencies.
Jobs are separated into a list of those which should be run at the current time (based on the clock of the host machine), and those which should not.
Jobs in the list of jobs to run are queued, and will be launched as soon as a sufficient offer becomes available.
Chronos will sleep until the next job is scheduled to run, and begin again from step 1.
Experts please opine?
You can run Chronos as a single node (which is what you are talking about) but Chronos is designed to be run with multiple nodes each on different hosts (achieving HA via Zookeeper quorum). This follows the standard leader/follower methodology where only the leader is active and the follower(s) will redirect traffic to the leader. This is considered to be HA in many open source frameworks, including Mesos as seen here.
Leader abdication or failure can occur, which is where Zookeeper comes in - Chronos leader election will occur after a failure with the leader, assuming quorum has been established and maintained prior to this event.
See reference of multi nodes here and here.
How leader election is specified:
JobSchedulerElectionSpec.scala
Leader redirection:
RedirectFilter.scala
I'm running an API build on Laravel Lumen 5.1, but I can't seem to get the Forge Queue Worker to work properly when using beanstalkd as a driver. It seems to run all the jobs in the queue simultaneously
I'm using the Forge UI to set up the driver
Queue Worker setup
And the .env drivers
The .env drivers
The queue system works fine when running it manually without any worker processing it.
If you need any more informations to help me, please just ask!
The purpose of the message queue is to allow parallel processing. If you have more workers eg: more threads than it will run simultaneously as many jobs.
In order to achieve non simultaneously that is counter intuitive and against the message queue principle. You can achieve that with 1 single worker, but it's not recommended as you don't leverage the power and scalability.
I need some advice. I have to choose between sling events or jobs.
In documentation it is precisely said that events are distributed to all nodes in cluster, so I could handle it in each one separately and thats ok.
But it's stated jobs are more reliable and that's what I want to achieve - reliability.
But there's a catch: job can only be executed in one job consumer.
Is there some similar mechanism as with events I mean if I could consume job in each cluster node and notify sender about success/failure on each node?