Hi Grainier, Answers to your queries are as follows.
1. What will happen to the events that arrive before, 0th-millisecond of an > hour? And is this 0th-millisecond taken relative to current-time or the > external-time? > The third parameter is taken relative to external time, whereas the events arriving before the 0th millisecond of an hour, would be processed at the next hour. For example, assume that the external time of an event is 10.45. If the third parameter is 0, then the relevant event would be processed at 11. > >> 2. What do you mean by if the value is not provided? Does this introduces > an overload method to externalTimeBatch > The 3rd and 4th parameters of external time batch are optional. Therefore if a time batch is provided as #window.externalTimeBatch(external_time, 2 min), the "external_time" of the 1st event arriving to the relevant stream would be taken as the start time. > > from LoginEvents#window.externalTimeBatch(timestamp, 1 sec, 0, 3 sec) > > 3. With above impl, if an event which belongs to the current batch, > arrives after the given timeout, will it be processed as a new batch? > In such a scenario, we would obtain two outputs for the same batch. One output would be obtained when timeout is elapsed. Another output would be obtained if an event of the same batch arrives after the timeout has expired. However in the second instance, all the events of the relevant batch would be considered. Not just the new events. Thanks, Charini > > Regards, > Grainier. > > On Tue, Jul 12, 2016 at 8:15 AM, Charini Nanayakkara <[email protected]> > wrote: > >> Hi Imesh, >> >> Specifying a timeout is already allowed in Siddhi. An example is as >> follows. >> >> from LoginEvents#window.externalTimeBatch(timestamp, 1 sec, 0, 3 sec) >> select timestamp, ip, count() as total >> insert all events into uniqueIps >> >> In this instance, events would be batched based on "timestamp" value. A >> batch would comprise of events arriving within 1 sec (as per the >> "timestamp"). The third parameter 0 specifies that batching must start from >> the 0th millisecond of an hour. If this value was not provided, the default >> start time would have been the timestamp value of the 1st event. The 4th >> parameter indicates the timeout. When 3rd parameter is not provided, output >> for a 1 sec batch is obtained only if that entire batch is completed (i.e. >> Siddhi learns that data worth of 1 sec has arrived only when it gets an >> event belonging to next batch). However, this timeout allows us to obtain >> an output in 3 seconds (based on UTC time) , even if a 1 sec batch is not >> completed. >> >> The issue with this implementation is, it disallows us to use the timeout >> while using 1st event's timestamp as start time. The suggested solution >> allows us to use either a variable or constant as 3rd parameter. Thus, >> subsequent to the implementation, we should be able to provide "timestamp" >> attribute as the 3rd parameter, from which Siddhi would derive 1st event's >> timestamp value to be used as start time (from >> LoginEvents#window.externalTimeBatch(timestamp, 1 sec, timestamp, 3 sec)). >> However the capability of specifying a constant value (as in the given >> example) too would be retained. >> >> Thank you >> Charini >> >> On Tue, Jul 12, 2016 at 7:24 AM, Imesh Gunaratne <[email protected]> wrote: >> >>> Hi Charini, >>> >>> A great thought! >>> >>> Would it be possible for you to explain this requirement with an example >>> written in Siddhi? Specifically how to generate a custom event on the >>> timeout. >>> >>> Thanks >>> >>> >>> On Monday, July 11, 2016, Charini Nanayakkara <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> I have planned to improve the current implementation of external time >>>> batch window, to allow accepting first event's time as start time, when >>>> specifying a timeout. >>>> >>>> In the current implementation, the 3rd parameter allows user to provide >>>> a user defined start time (whereas the default is to use first event's time >>>> as start time). This value is required to be a constant. The 4th parameter >>>> is reserved for specifying a timeout, which is valuable in an instance >>>> where output needs to be given if events don't arrive for some time. >>>> However, this implementation disallows a user to use the default start time >>>> (first event's start time) and timeout together. >>>> >>>> Therefore, I intend to change the implementation such that user can >>>> either provide a variable or a constant as 3rd parameter. This enables the >>>> external time field to be given as 3rd parameter, from which Siddhi can >>>> retrieve 1st event's time to be used as start time. Alternatively, a >>>> constant value could be given if user defined start time is required. >>>> >>>> Suggestions and comments are most welcome. >>>> >>>> Thank you >>>> Charini >>>> >>>> -- >>>> Charini Vimansha Nanayakkara >>>> Software Engineer at WSO2 >>>> Mobile: 0714126293 >>>> >>>> >>> >>> -- >>> *Imesh Gunaratne* >>> Software Architect >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: https://medium.com/@imesh TW: @imesh >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Charini Vimansha Nanayakkara >> Software Engineer at WSO2 >> Mobile: 0714126293 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Grainier Perera > Software Engineer > Mobile : +94716122384 > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > -- *Charini Vimansha Nanayakkara* Software Engineer at WSO2 Mobile: 0714126293 E-mail: [email protected] Blog: http://www.charini.me/ <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
