[ 
https://issues.apache.org/jira/browse/MESOS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149956#comment-13149956
 ] 

[email protected] commented on MESOS-56:
----------------------------------------------------



bq.  On 2011-11-14 19:21:12, Benjamin Hindman wrote:
bq.  > src/slave/slave.cpp, line 750
bq.  > <https://reviews.apache.org/r/2669/diff/1/?file=55784#file55784line750>
bq.  >
bq.  >     s/start/start.

Done.


bq.  On 2011-11-14 19:21:12, Benjamin Hindman wrote:
bq.  > src/slave/slave.cpp, line 755
bq.  > <https://reviews.apache.org/r/2669/diff/1/?file=55784#file55784line755>
bq.  >
bq.  >     Let's keep this down by the actual RunTaskMessage for consistency 
with the other RunTaskMessage usage.

Done.


bq.  On 2011-11-14 19:21:12, Benjamin Hindman wrote:
bq.  > src/slave/slave.cpp, lines 758-759
bq.  > <https://reviews.apache.org/r/2669/diff/1/?file=55784#file55784line758>
bq.  >
bq.  >     This is great. But three things: (1) let's tweak this comment to 
include the fact that we are changing the resources _after_ we have accounted 
for the tasks; (2) possibly include a TODO or NOTE that says that given the 
asynchronous nature of the dispatch this still might not be sufficient for 
guaranteeing that the resource limits have been changed before the executor 
starts running the task; and (3) also change the other place in the code where 
we send a RunTaskMessage to a slave to dispatch to the isolation module before 
we send the message.

Done.


bq.  On 2011-11-14 19:21:12, Benjamin Hindman wrote:
bq.  > src/tests/master_tests.cpp, lines 137-138
bq.  > <https://reviews.apache.org/r/2669/diff/1/?file=55785#file55785line137>
bq.  >
bq.  >     Unless I'm mistaken, because of the async nature of the isolation 
module there is no happens-before relationship in the code that guarantees that 
the isolation module will have gotten a "resourcesChanged" before the slave 
gets a status update from the executor that it sends back to the scheduler. I'd 
rather you add a TODO in the code to try and capture the fact that resources 
have been updated then doing it this way for now.

I agree. Changed the test to wait for an resourcesChanged() call, so we have a 
test that resourcesChanged() is eventually called with the correct value.

Added TODOs to both the dispatch(...resourcesChanged) in the slave. I'll also 
file a separate JIRA about this; it probably needs a IsolationModule API change.


- Charles


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


On 2011-11-14 21:34:18, Charles Reiss wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2669/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-11-14 21:34:18)
bq.  
bq.  
bq.  Review request for mesos.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  This calls Executor::addTask to accumulate the usage of queued tasks 
before calling resourcesChanged() to ensure the executor has enough resources 
to run those queued tasks.
bq.  
bq.  
bq.  This addresses bug MESOS-56.
bq.      https://issues.apache.org/jira/browse/MESOS-56
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    src/slave/slave.cpp de5716c 
bq.    src/tests/master_tests.cpp 2438114 
bq.    src/tests/utils.hpp 02772f7 
bq.  
bq.  Diff: https://reviews.apache.org/r/2669/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Modification to MasterTest included.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Charles
bq.  
bq.


                
> Resources of tasks queued during executor launch not always accounted for
> -------------------------------------------------------------------------
>
>                 Key: MESOS-56
>                 URL: https://issues.apache.org/jira/browse/MESOS-56
>             Project: Mesos
>          Issue Type: Bug
>          Components: isolation, slave
>            Reporter: Charles Reiss
>            Assignee: Charles Reiss
>
> When initially launching an executor, the slave queues the tasks sent to the 
> executor until the executor registers itself with the slave. When this 
> happens, the slave calls resourcesChanged() on the isolation module, but 
> before it adds the usage of the queued tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to