[jira] [Updated] (MESOS-3339) Implement filtering mechanism for (Scheduler API Events) Testing

["Anand Mazumdar (JIRA)" <ji...@apache.org>]

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

Anand Mazumdar updated MESOS-3339:
----------------------------------
    Description: 
Currently, our testing infrastructure does not have a mechanism of filtering/dropping HTTP events of a particular type from the Scheduler API response stream.  We need a {{DROP_HTTP_CALLS}} abstraction that can help us to filter a particular event type.

{code}
// Enqueues all received events into a libprocess queue.
ACTION_P(Enqueue, queue)
{
  std::queue<Event> events = arg0;
  while (!events.empty()) {
    // Note that we currently drop HEARTBEATs because most of these tests
    // are not designed to deal with heartbeats.
    // TODO(vinod): Implement DROP_HTTP_CALLS that can filter heartbeats.
    if (events.front().type() == Event::HEARTBEAT) {
      VLOG(1) << "Ignoring HEARTBEAT event";
    } else {
      queue->put(events.front());
    }
    events.pop();
  }
}
{code}

This helper code is duplicated in at least two places currently, Scheduler Library/Maintenance Primitives tests. The solution can be as trivial as moving this helper function to a common test-header or implement a decorator reader class over {{RecordIOReader}} having the functionality of filtering events. There might be other alternative approaches too.

  was:
Currently, our testing infrastructure does not have a mechanism of filtering/dropping HTTP events of a particular type from the Scheduler API response stream.  We need a {DROP_HTTP_CALLS} abstraction that can help us to filter a particular event type.

{code}
// Enqueues all received events into a libprocess queue.
ACTION_P(Enqueue, queue)
{
  std::queue<Event> events = arg0;
  while (!events.empty()) {
    // Note that we currently drop HEARTBEATs because most of these tests
    // are not designed to deal with heartbeats.
    // TODO(vinod): Implement DROP_HTTP_CALLS that can filter heartbeats.
    if (events.front().type() == Event::HEARTBEAT) {
      VLOG(1) << "Ignoring HEARTBEAT event";
    } else {
      queue->put(events.front());
    }
    events.pop();
  }
}
{code}

This helper code is duplicated in at least two places currently, Scheduler Library/Maintenance Primitives tests. The solution can be as trivial as moving this helper function to a common test-header or implement a decorator reader class over {RecordIOReader} having the functionality of filtering events. There might be other alternative approaches too.


> Implement filtering mechanism for (Scheduler API Events) Testing
> ----------------------------------------------------------------
>
>                 Key: MESOS-3339
>                 URL: https://issues.apache.org/jira/browse/MESOS-3339
>             Project: Mesos
>          Issue Type: Task
>          Components: test
>            Reporter: Anand Mazumdar
>
> Currently, our testing infrastructure does not have a mechanism of filtering/dropping HTTP events of a particular type from the Scheduler API response stream.  We need a {{DROP_HTTP_CALLS}} abstraction that can help us to filter a particular event type.
> {code}
> // Enqueues all received events into a libprocess queue.
> ACTION_P(Enqueue, queue)
> {
>   std::queue<Event> events = arg0;
>   while (!events.empty()) {
>     // Note that we currently drop HEARTBEATs because most of these tests
>     // are not designed to deal with heartbeats.
>     // TODO(vinod): Implement DROP_HTTP_CALLS that can filter heartbeats.
>     if (events.front().type() == Event::HEARTBEAT) {
>       VLOG(1) << "Ignoring HEARTBEAT event";
>     } else {
>       queue->put(events.front());
>     }
>     events.pop();
>   }
> }
> {code}
> This helper code is duplicated in at least two places currently, Scheduler Library/Maintenance Primitives tests. The solution can be as trivial as moving this helper function to a common test-header or implement a decorator reader class over {{RecordIOReader}} having the functionality of filtering events. There might be other alternative approaches too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)