[
https://issues.apache.org/jira/browse/SOLR-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15788401#comment-15788401
]
Joel Bernstein commented on SOLR-9684:
--------------------------------------
It think it makes sense for the *executor* to wrap a *scheduler*. The
semantics of this is nice. We can also use the schedule function as a facade to
build out more scheduling capabilities by passing a scheduling algorithm. for
example:
executor(schedule(COST, topic())))
executor(schedule(CRON, search())))
executor(schedule(PRIORITY, topic(), topic())))
The initial release is simple, but a nice first step.
> Add schedule Streaming Expression
> ---------------------------------
>
> Key: SOLR-9684
> URL: https://issues.apache.org/jira/browse/SOLR-9684
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Joel Bernstein
> Assignee: Joel Bernstein
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9684.patch, SOLR-9684.patch, SOLR-9684.patch
>
>
> SOLR-9559 adds a general purpose *parallel task executor* for streaming
> expressions. The executor() function executes a stream of tasks and doesn't
> have any concept of task priority.
> The scheduler() function wraps two streams, a high priority stream and a low
> priority stream. The scheduler function emits tuples from the high priority
> stream first, and then the low priority stream.
> The executor() function can then wrap the scheduler function to see tasks in
> priority order.
> Pseudo syntax:
> {code}
> daemon(executor(schedule(topic(tasks, q="priority:high"), topic(tasks,
> q="priority:low"))))
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
