aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: Review Request 59853: Process rescinds in the same thread pool as offers.
Date Wed, 28 Jun 2017 17:39:53 GMT


> On June 28, 2017, 10:22 a.m., David McLaughlin wrote:
> > This change appears to have caused adverse behavior when we deployed it to production.
We are seeing more tasks lost due to being launched in invalid offers.
> > 
> > I think we should revert this change until we root cause it.
> 
> Zameer Manji wrote:
>     This change caused less lost tasks when deployed to production for me. Have you isolated
it 100% to this change? What do you see for the `offer_cancel_failures` metric?
> 
> David McLaughlin wrote:
>     Like 99.9% sure it's this commit. 
>     
>     We'll revert this commit on one cluster and compare the differences.

Note that this code fixes a clear race condition, so if this is causing a problem in production
I feel it is exposing another problem more so than causing another one.

I would like to repeat that the log snippet in the description shows that a rescind can be
processed before the offer it self, which leaves an invalid offer id in the offer manager.
This causes lost tasks with the reason of invalid offer. Reverting this change keeps you open
to this problem.

One thing that you should do, is check the logs for offer ids that are rejected for being
invalid and confirm the times that mesos sent the offer and send the rescind.

It is possible/likely that the rescind came right after the offer which exposes a problem
in Mesos.

I think reverting this change is a bad idea based on the evidence that it is fixing a clear
problem.


- Zameer


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59853/#review179131
-----------------------------------------------------------


On June 6, 2017, 1:56 p.m., Zameer Manji wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59853/
> -----------------------------------------------------------
> 
> (Updated June 6, 2017, 1:56 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Santhosh Kumar Shanmugham.
> 
> 
> Bugs: AURORA-1933
>     https://issues.apache.org/jira/browse/AURORA-1933
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> In a a production environment I was able to observe the following:
> ```
> I0606 00:31:32.510 [Thread-77638, MesosCallbackHandler$MesosCallbackHandlerImpl:229]
Offer rescinded: 81e04cbd-9bce-41cf-bd94-38c911f255e4-O142359552
> I0606 00:31:32.903 [SchedulerImpl-0, MesosCallbackHandler$MesosCallbackHandlerImpl:211]
Received offer: 81e04cbd-9bce-41cf-bd94-38c911f255e4-O142359552
> I0606 00:31:34.815 [TaskGroupBatchWorker, VersionedSchedulerDriverService:123] Accepting
offer 81e04cbd-9bce-41cf-bd94-38c911f255e4-O142359552 with ops [LAUNCH]
> ```
> 
> Notice that the offer rescind was processed before the actual offer. This is
> possible because there is a race in the `MesosCallbackHandlerImpl`. The offer is
> processed in the executor (to prevent blocking) and the rescind is handled
> directly. This means the offer procecssing thread (`SchedulerImpl-0`) is racing
> against the callback thread (`Thread-77638`).
> 
> In normal operation, there will be seconds to minutes between a rescind and an
> offer, but in some cases an offer can be rescinded very quickly in clusters that
> use oversubscription modules.
> 
> To fix this, we move the rescind processing into the same executor as the offer
> processing to ensure they are processed in the order they are received. Without
> fixing this, the rescinded offer exists in the offer manager and can be used
> later to launch a task. This task will immediately fail to launch because the
> offer is invalid.
> 
> In this patch, I have also added a metric and logging to record when we fail to
> remove an offer from the offer manager, and cleaned up the logging to allow
> operators to see when an offer was recieved. With this logging, an operator can
> grep for the offer id and see the entire lifecycle of the offer in the
> scheduler.
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/mesos/MesosCallbackHandler.java 5a5281aeaea1e2a4e0eab67069605838ee809c6c

>   src/main/java/org/apache/aurora/scheduler/mesos/VersionedSchedulerDriverService.java
5e86504c70083065278864e6ab1cc85c83a45a28 
>   src/main/java/org/apache/aurora/scheduler/offers/OfferManager.java 17e577b069df9232d57cde171a078d9f6db707ea

>   src/test/java/org/apache/aurora/scheduler/offers/OfferManagerImplTest.java 97febf25cea2024e0ca43366b3d4578e67734884

> 
> 
> Diff: https://reviews.apache.org/r/59853/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Zameer Manji
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message