Return-Path: 
 <dev-return-761-apmail-aurora-dev-archive=aurora.apache.org@aurora.incubator.apache.org>
X-Original-To: apmail-aurora-dev-archive@minotaur.apache.org
Delivered-To: apmail-aurora-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 3E8FF10983
	for <apmail-aurora-dev-archive@minotaur.apache.org>;
 Mon, 27 Jan 2014 06:03:14 +0000 (UTC)
Received: (qmail 87404 invoked by uid 500); 27 Jan 2014 06:03:13 -0000
Delivered-To: apmail-aurora-dev-archive@aurora.apache.org
Received: (qmail 87254 invoked by uid 500); 27 Jan 2014 06:03:11 -0000
Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@aurora.incubator.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@aurora.incubator.apache.org>
List-Post: <mailto:dev@aurora.incubator.apache.org>
List-Id: <dev.aurora.incubator.apache.org>
Reply-To: dev@aurora.incubator.apache.org
Delivered-To: mailing list dev@aurora.incubator.apache.org
Received: (qmail 87020 invoked by uid 99); 27 Jan 2014 06:03:05 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jan 2014 06:03:05 +0000
X-ASF-Spam-Status: No, hits=-2000.5 required=5.0
	tests=ALL_TRUSTED,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3)
    by apache.org (qpsmtpd/0.29) with SMTP; Mon, 27 Jan 2014 06:03:03 +0000
Received: (qmail 86903 invoked by uid 99); 27 Jan 2014 06:02:42 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jan 2014 06:02:42 +0000
Date: Mon, 27 Jan 2014 06:02:41 +0000 (UTC)
From: "Joe Smith (JIRA)" <jira@apache.org>
To: dev@aurora.incubator.apache.org
Message-ID: <JIRA.12691182.1390622759275.17070.1390802561615@arcas>
In-Reply-To: <JIRA.12691182.1390622759275@arcas>
References: <JIRA.12691182.1390622759275@arcas>
Subject: [jira] [Updated] (AURORA-116) Improve efficiency of saving host
 attributes (or avoid saving host attributes)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


     [ https://issues.apache.org/jira/browse/AURORA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joe Smith updated AURORA-116:
-----------------------------

    Component/s: Reliability

> Improve efficiency of saving host attributes (or avoid saving host attributes)
> ------------------------------------------------------------------------------
>
>                 Key: AURORA-116
>                 URL: https://issues.apache.org/jira/browse/AURORA-116
>             Project: Aurora
>          Issue Type: Task
>          Components: Reliability, Scheduler
>            Reporter: Bill Farner
>            Assignee: Bill Farner
>            Priority: Critical
>
> The scheduler performs multiple write operations for every resource offer, to save slave attributes:
> {noformat}
>   public void resourceOffers(SchedulerDriver driver, List<Offer> offers) {
>     Preconditions.checkState(registered, "Must be registered before receiving offers.");
>     for (final Offer offer : offers) {
>       log(Level.FINE, "Received offer: %s", offer);
>       resourceOffers.incrementAndGet();
>       storage.write(new MutateWork.NoResult.Quiet() {
>         @Override protected void execute(MutableStoreProvider storeProvider) {
>           storeProvider.getAttributeStore().saveHostAttributes(Conversions.getAttributes(offer));
>         }
>       });
> {noformat}
> This can unnecessarily block the singly-threaded message dispatch in the scheduler driver.  An incremental improvement would be to aggregate all slave info and save it in one write operation.  Better yet would be to perform writes asynchronously (taking care to not break task scheduling, since attributes are expected to be present).  Even better yet, it would be great to determine if we can avoid storing host attributes.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)