The injunction that tuple processing should be "as fast as possible" is based
on anassumption and a fact:
1. In most cases, users want to maximize application throughput.2. If a
callback (like beginWindow(), process(), endWindow(), etc.) takes too long,
the platform deems the operator hung and restarts it.
Neither imposes a hard constraint: If, for a particular class of
applications,it is OK to sacrifice throughput to allow some CPU intensive
computations to occur,that is certainly possible; the constraint of (2) can be
relaxed by simply increasingthe TIMEOUT_WINDOW_COUNT attribute, for some or all
operators.
Secondly, nothing prevents an operator from starting worker threads that
asynchronouslyperform CPU intensive computations. Naturally, careful
synchronization will be necessarybetween the main and worker threads to ensure
correctness and timelydelivery of results.
Ram
On Friday, May 12, 2017 6:38 PM, Ananth G <ananthg.a...@gmail.com> wrote:
I guess the use cases as documented look really compelling. There might be
more comments from code review perspective and below is more from a use case
perspective only.
I was wondering if you have any latency measurements for the tests you ran.
If the image processing calls ( in the process function overridden from the
Toolkit class ) are time consuming it might not be an ideal use case for a
streaming engine? A very old "blog" (2012) talks about latencies anywhere
between tens of milliseconds to almost a second depending on the use case and
image size. Of course there were hardware improvements and those numbers might
no longer hold good and hence the question (of course the latencies depend on
hardware being used as well )
This brings me to the next question in general about Apex to the community :
what is considered an acceptable tolerance level in terms of latencies for
streaming compute engine like Apex. Is there a way to tune the acceptable
tolerance level depending on the use case ? I keep reading from the mailing
lists that the aspect of tuple processing is part of the main thread and hence
should be as fast as possible.
Regards
Ananth
> On 12 May 2017, at 9:05 pm, Aditya gholba <adi...@datatorrent.com> wrote:
>
> Hello,
> I have been working on an image processing library for Malhar and few of
> the operators are ready. I would like to merge them in Malhar contrib. You
> can read about the operators and the applications I have created so far
> here.
> <https://docs.google.com/document/d/19OrqHJ_QzbuB0XZ4bzdQ9yjN2dGfDhsuMX6XUjDpqYw/edit>
>
> Link to my GitHub <https://github.com/adiv2/imIO4>
>
> All suggestions and opinions are welcome.
>
>
> Thanks,
> Aditya.
