In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
If the user does not have VIEW_APP
access then the following
fields in the report will be set to stubbed values:
If the user does not have VIEW_APP
access for an application
then the corresponding report will be filtered as described in
{@link #getApplicationReport(ApplicationId)}.
In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
ResourceManager
. New containers assigned to the master are
retrieved. Status of completed containers and node health updates are also
retrieved. This also doubles up as a heartbeat to the ResourceManager and
must be made periodically. The call may not always return any new
allocations of containers. App should not make concurrent allocate
requests. May cause request loss.
Note : If the user has not removed container requests that have already been satisfied, then the re-register may end up sending the entire container requests to the RM (including matched requests). Which would mean the RM could end up giving it a lot of new allocated containers.
@param progressIndicator Indicates progress made by the master @return the response of the allocate request @throws YarnException @throws IOException]]>addContainerRequest
earlier in the lifecycle. For performance,
the AMRMClient may return its internal collection directly without creating
a copy. Users should not perform mutable operations on the return value.
Each collection in the list contains requests with identical
Resource
size that fit in the given capability. In a
collection, requests will be returned in the same order as they were added.
@return Collection of request matching the parameters]]>
AMRMClient
If a NM token cache is not set, the {@link NMTokenCache#getSingleton()}
singleton instance will be used.
@param nmTokenCache the NM token cache to use.]]>
AMRMClient
.
If a NM token cache is not set, the {@link NMTokenCache#getSingleton()}
singleton instance will be used.
@return the NM token cache.]]>
checkEveryMillis
ms.
See also {@link #waitFor(com.google.common.base.Supplier, int, int)}
@param check user defined checker
@param checkEveryMillis interval to call check
]]>
checkEveryMillis
ms. In the main loop, this method will log
the message "waiting in main loop" for each logInterval
times
iteration to confirm the thread is alive.
@param check user defined checker
@param checkEveryMillis interval to call check
@param logInterval interval to log for each]]>
The ApplicationMaster
or other applications that use the
client must provide the details of the allocated container, including the
Id, the assigned node's Id and the token via {@link Container}. In
addition, the AM needs to provide the {@link ContainerLaunchContext} as
well.
NodeManager
to launch the
container
@return a map between the auxiliary service names and their outputs
@throws YarnException
@throws IOException]]>
NodeManager
@throws YarnException
@throws IOException]]>
NodeManager
@return the status of a container
@throws YarnException
@throws IOException]]>
NMClient
If a NM token cache is not set, the {@link NMTokenCache#getSingleton()}
singleton instance will be used.
@param nmTokenCache the NM token cache to use.]]>
NMClient
If a NM token cache is not set, the {@link NMTokenCache#getSingleton()}
singleton instance will be used.
@return the NM token cache]]>
NMTokenCache nmTokenCache = new NMTokenCache(); AMRMClient rmClient = AMRMClient.createAMRMClient(); NMClient nmClient = NMClient.createNMClient(); nmClient.setNMTokenCache(nmTokenCache); ...
NMTokenCache nmTokenCache = new NMTokenCache(); AMRMClient rmClient = AMRMClient.createAMRMClient(); NMClient nmClient = NMClient.createNMClient(); nmClient.setNMTokenCache(nmTokenCache); AMRMClientAsync rmClientAsync = new AMRMClientAsync(rmClient, 1000, [AMRM_CALLBACK]); NMClientAsync nmClientAsync = new NMClientAsync("nmClient", nmClient, [NM_CALLBACK]); ...
NMTokenCache nmTokenCache = new NMTokenCache(); ... ApplicationMasterProtocol amPro = ClientRMProxy.createRMProxy(conf, ApplicationMasterProtocol.class); ... AllocateRequest allocateRequest = ... ... AllocateResponse allocateResponse = rmClient.allocate(allocateRequest); for (NMToken token : allocateResponse.getNMTokens()) { nmTokenCache.setToken(token.getNodeId().toString(), token.getToken()); } ... ContainerManagementProtocolProxy nmPro = ContainerManagementProtocolProxy(conf, nmTokenCache); ... nmPro.startContainer(container, containerContext); ...
AMRMClient
or
NMClient
, or the async versions of them) with a protocol proxy (
ContainerManagementProtocolProxy
or
ApplicationMasterProtocol
).]]>
YARN.
It is a blocking call - it
will not return {@link ApplicationId} until the submitted application is
submitted successfully and accepted by the ResourceManager.
Users should provide an {@link ApplicationId} as part of the parameter {@link ApplicationSubmissionContext} when submitting a new application, otherwise it will throw the {@link ApplicationIdNotProvidedException}.
This internally calls {@link ApplicationClientProtocol#submitApplication (SubmitApplicationRequest)}, and after that, it internally invokes {@link ApplicationClientProtocol#getApplicationReport (GetApplicationReportRequest)} and waits till it can make sure that the application gets properly submitted. If RM fails over or RM restart happens before ResourceManager saves the application's state, {@link ApplicationClientProtocol #getApplicationReport(GetApplicationReportRequest)} will throw the {@link ApplicationNotFoundException}. This API automatically resubmits the application with the same {@link ApplicationSubmissionContext} when it catches the {@link ApplicationNotFoundException}
@param appContext {@link ApplicationSubmissionContext} containing all the details needed to submit a new application @return {@link ApplicationId} of the accepted application @throws YarnException @throws IOException @see #createApplication()]]>
In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
If the user does not have VIEW_APP
access then the following
fields in the report will be set to stubbed values:
If the user does not have VIEW_APP
access for an application
then the corresponding report will be filtered as described in
{@link #getApplicationReport(ApplicationId)}.
If the user does not have VIEW_APP
access for an application
then the corresponding report will be filtered as described in
{@link #getApplicationReport(ApplicationId)}.
If the user does not have VIEW_APP
access for an application
then the corresponding report will be filtered as described in
{@link #getApplicationReport(ApplicationId)}.
If the user does not have VIEW_APP
access for an application
then the corresponding report will be filtered as described in
{@link #getApplicationReport(ApplicationId)}.
In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
In secure mode, YARN
verifies access to the application, queue
etc. before accepting the request.
The client packages all details of its request in a {@link ReservationSubmissionRequest} object. This contains information about the amount of capacity, temporal constraints, and gang needs. Furthermore, the reservation might be composed of multiple stages, with ordering dependencies among them.
In order to respond, a new admission control component in the {@code ResourceManager} performs an analysis of the resources that have been committed over the period of time the user is requesting, verify that the user requests can be fulfilled, and that it respect a sharing policy (e.g., {@code CapacityOverTimePolicy}). Once it has positively determined that the ReservationRequest is satisfiable the {@code ResourceManager} answers with a {@link ReservationSubmissionResponse} that includes a {@link ReservationId}. Upon failure to find a valid allocation the response is an exception with the message detailing the reason of failure.
The semantics guarantees that the {@link ReservationId} returned, corresponds to a valid reservation existing in the time-range request by the user. The amount of capacity dedicated to such reservation can vary overtime, depending of the allocation that has been determined. But it is guaranteed to satisfy all the constraint expressed by the user in the {@link ReservationDefinition}
@param request request to submit a new Reservation @return response contains the {@link ReservationId} on accepting the submission @throws YarnException if the reservation cannot be created successfully @throws IOException]]>The allocation is attempted by virtually substituting all previous allocations related to this Reservation with new ones, that satisfy the new {@link ReservationDefinition}. Upon success the previous allocation is atomically substituted by the new one, and on failure (i.e., if the system cannot find a valid allocation for the updated request), the previous allocation remains valid.
@param request to update an existing Reservation (the {@link ReservationUpdateRequest} should refer to an existing valid {@link ReservationId}) @return response empty on successfully updating the existing reservation @throws YarnException if the request is invalid or reservation cannot be updated successfully @throws IOException]]>checkEveryMillis
ms.
See also {@link #waitFor(com.google.common.base.Supplier, int, int)}
@param check user defined checker
@param checkEveryMillis interval to call check
]]>
checkEveryMillis
ms. In the main loop, this method will log
the message "waiting in main loop" for each logInterval
times
iteration to confirm the thread is alive.
@param check user defined checker
@param checkEveryMillis interval to call check
@param logInterval interval to log for each]]>
{@code class MyCallbackHandler implements AMRMClientAsync.CallbackHandler { public void onContainersAllocated(ListThe client's lifecycle should be managed similarly to the following:containers) { [run tasks on the containers] } public void onContainersCompleted(List statuses) { [update progress, check whether app is done] } public void onNodesUpdated(List updated) {} public void onReboot() {} } }
{@code AMRMClientAsync asyncClient = createAMRMClientAsync(appAttId, 1000, new MyCallbackhandler()); asyncClient.init(conf); asyncClient.start(); RegisterApplicationMasterResponse response = asyncClient .registerApplicationMaster(appMasterHostname, appMasterRpcPort, appMasterTrackingUrl); asyncClient.addContainerRequest(containerRequest); [... wait for application to complete] asyncClient.unregisterApplicationMaster(status, appMsg, trackingUrl); asyncClient.stop(); }]]>
{@code class MyCallbackHandler implements NMClientAsync.CallbackHandler { public void onContainerStarted(ContainerId containerId, MapThe client's life-cycle should be managed like the following:allServiceResponse) { [post process after the container is started, process the response] } public void onContainerStatusReceived(ContainerId containerId, ContainerStatus containerStatus) { [make use of the status of the container] } public void onContainerStopped(ContainerId containerId) { [post process after the container is stopped] } public void onStartContainerError( ContainerId containerId, Throwable t) { [handle the raised exception] } public void onGetContainerStatusError( ContainerId containerId, Throwable t) { [handle the raised exception] } public void onStopContainerError( ContainerId containerId, Throwable t) { [handle the raised exception] } } }
{@code NMClientAsync asyncClient = NMClientAsync.createNMClientAsync(new MyCallbackhandler()); asyncClient.init(conf); asyncClient.start(); asyncClient.startContainer(container, containerLaunchContext); [... wait for container being started] asyncClient.getContainerStatus(container.getId(), container.getNodeId(), container.getContainerToken()); [... handle the status in the callback instance] asyncClient.stopContainer(container.getId(), container.getNodeId(), container.getContainerToken()); [... wait for container being stopped] asyncClient.stop(); }]]>
NodeManager
are
available.
Once a callback happens, the users can chose to act on it in blocking or non-blocking manner. If the action on callback is done in a blocking manner, some of the threads performing requests on NodeManagers may get blocked depending on how many threads in the pool are busy.
The implementation of the callback function should not throw the unexpected exception. Otherwise, {@link NMClientAsync} will just catch, log and then ignore it.
]]>