You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lens.apache.org by "Rohit Chatter (JIRA)" <ji...@apache.org> on 2015/02/04 05:52:34 UTC

[jira] [Commented] (LENS-268) Support queries to be scheduled for execution (with repeat)

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

Rohit Chatter commented on LENS-268:
------------------------------------

More 
  * Limit number of schedules per user/app/client
  * Schedule should be aware of data availability
  * Schedule should get retried on non data availability and failures and send appropriate alerts to an end point
  * User will set schedule start time in his/her time zone
  * Ability to expire a schedule
  * Pause and resume of schedule
  * Cancel a running a instance

> Support queries to be scheduled for execution (with repeat)
> -----------------------------------------------------------
>
>                 Key: LENS-268
>                 URL: https://issues.apache.org/jira/browse/LENS-268
>             Project: Apache Lens
>          Issue Type: New Feature
>          Components: api, client, server
>    Affects Versions: 2.1
>            Reporter: Srikanth Sundarrajan
>
> It would be quite handy to support scheduling as a capability in the Lens system to allow users to submit a query with a repeatable schedule. For ex. I should be able to submit a query and expect that to be running the first monday of every month or first day of every month over a moving data window.
> The list of features that need to be supported with this are
> 1. Parameterization of queries to allow fixed, moving time windows
> 2. Allow Cron style scheduling & specific weekday or specific day of month etc
> 3. Allow scheduled queries to be paced in such a way that regular queries that users are submitting point in time don't suffer
> 4. Allow gating of the scheduled queries based on partition availability. It shouldn't happen that ideally query is run in low cost engine and due to data availability delays, the system chooses a higher cost engine because of availability of data earlier in that system. In some cases that may be acceptable as well. But the choice should be conscious.
> 5.Handling query failures in the schedule and being able to run them again through administrative levers
> 6. Administrative levers to repeating the entire schedule due to errors in data, requiring re-publishing the reports.
> 7. Support query stats analysis over scheduled queries



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