本文整理汇总了C++中StatusUpdate::framework_id方法的典型用法代码示例。如果您正苦于以下问题：C++ StatusUpdate::framework_id方法的具体用法？C++ StatusUpdate::framework_id怎么用？C++ StatusUpdate::framework_id使用的例子？那么, 这里精选的方法代码示例或许可以为您提供帮助。您也可以进一步了解该方法所在类StatusUpdate的用法示例。
在下文中一共展示了StatusUpdate::framework_id方法的2个代码示例，这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞，您的评价将有助于系统推荐出更棒的C++代码示例。
示例1: statusUpdate
void statusUpdate(const StatusUpdate& update, const UPID& pid)
{
const TaskStatus& status = update.status();
VLOG(1) << "Status update: task " << status.task_id()
<< " of framework " << update.framework_id()
<< " is now in state " << status.state();
CHECK(frameworkId == update.framework_id());
// TODO(benh): Note that this maybe a duplicate status update!
// Once we get support to try and have a more consistent view
// of what's running in the cluster, we'll just let this one
// slide. The alternative is possibly dealing with a scheduler
// failover and not correctly giving the scheduler it's status
// update, which seems worse than giving a status update
// multiple times (of course, if a scheduler re-uses a TaskID,
// that could be bad.
invoke(bind(&Scheduler::statusUpdate, sched, driver, cref(status)));
if (pid) {
// Acknowledge the message (we do this last, after we invoked
// the scheduler, if we did at all, in case it causes a crash,
// since this way the message might get resent/routed after the
// scheduler comes back online).
StatusUpdateAcknowledgementMessage message;
message.mutable_framework_id()->MergeFrom(frameworkId);
message.mutable_slave_id()->MergeFrom(update.slave_id());
message.mutable_task_id()->MergeFrom(status.task_id());
message.set_uuid(update.uuid());
send(pid, message);
}
}示例2: statusUpdate
void statusUpdate(const StatusUpdate& update, const UPID& pid)
{
const TaskStatus& status = update.status();
if (aborted) {
VLOG(1) << "Ignoring task status update message because "
<< "the driver is aborted!";
return;
}
VLOG(2) << "Received status update " << update << " from " << pid;
CHECK(framework.id() == update.framework_id());
// TODO(benh): Note that this maybe a duplicate status update!
// Once we get support to try and have a more consistent view
// of what's running in the cluster, we'll just let this one
// slide. The alternative is possibly dealing with a scheduler
// failover and not correctly giving the scheduler it's status
// update, which seems worse than giving a status update
// multiple times (of course, if a scheduler re-uses a TaskID,
// that could be bad.
Stopwatch stopwatch;
if (FLAGS_v >= 1) {
stopwatch.start();
}
scheduler->statusUpdate(driver, status);
VLOG(1) << "Scheduler::statusUpdate took " << stopwatch.elapsed();
// Acknowledge the status update.
// NOTE: We do a dispatch here instead of directly sending the ACK because,
// we want to avoid sending the ACK if the driver was aborted when we
// made the statusUpdate call. This works because, the 'abort' message will
// be enqueued before the ACK message is processed.
if (pid > 0) {
dispatch(self(), &Self::statusUpdateAcknowledgement, update, pid);
}
}