Send too soon. A quicker way would be to catch emit happening between
start_window and end_window and flag an error. Catching "another thread"
for every tuple may have a huge performance hit.

Thks
Amol


On Wed, Aug 10, 2016 at 2:31 PM, Amol Kekre <[email protected]> wrote:

>
> Currently user can code it that way. IMHO Apex should catch this and flag
> error.
>
> Thks
> Amol
>
>
> On Wed, Aug 10, 2016 at 2:04 PM, Ashwin Chandra Putta <
> [email protected]> wrote:
>
>> In a separate thread I mean.
>>
>> Regards,
>> Ashwin.
>>
>> On Wed, Aug 10, 2016 at 2:01 PM, Ashwin Chandra Putta <
>> [email protected]> wrote:
>>
>> > + [email protected]
>> > - [email protected]
>> >
>> > This is one of those best practices that we learn by experience during
>> > operator development. It will save a lot of time during operator
>> > development if we can catch and throw validation error when someone
>> emits
>> > tuples in a non separate thread.
>> >
>> > Regards,
>> > Ashwin
>> >
>> > On Wed, Aug 10, 2016 at 1:57 PM, Munagala Ramanath <[email protected]
>> >
>> > wrote:
>> >
>> >> For cases where use of a different thread is needed, it can write
>> tuples
>> >> to a queue from where the operator thread pulls them --
>> >> JdbcPollInputOperator in Malhar has an example.
>> >>
>> >> Ram
>> >>
>> >> On Wed, Aug 10, 2016 at 1:50 PM, [email protected] <[email protected]>
>> >> wrote:
>> >>
>> >>> Hey Vlad,
>> >>>
>> >>> Thanks for bringing this up. Is there an easy way to detect unexpected
>> >>> use of emit method without hurt the performance. Or at least if we can
>> >>> detect this in debug mode.
>> >>>
>> >>> Regards,
>> >>> Siyuan
>> >>>
>> >>> On Wed, Aug 10, 2016 at 11:27 AM, Vlad Rozov <[email protected]
>> >
>> >>> wrote:
>> >>>
>> >>>> The short answer is no, creating worker thread to emit tuples is not
>> >>>> supported by Apex and will lead to an undefined behavior. Operators
>> in Apex
>> >>>> have strong thread affinity and all interaction with the platform
>> must
>> >>>> happen on the operator thread.
>> >>>>
>> >>>> Vlad
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> >
>> > Regards,
>> > Ashwin.
>> >
>>
>>
>>
>> --
>>
>> Regards,
>> Ashwin.
>>
>
>

Reply via email to