The number of tuples dropping on the window can change dramatically depending on the periodicity of a type of event clients produce, which is configurable. AFAICT, count based windows are not a better fit in this particular use case because theres no warranty whatsoever different clients will produce equal number of messages in the same time frame. When evaluating a window i would want to have at least x number of tuples from each client.
I can need 10minutes windows or 30 minutes windows depending if a user changes some config via the system's backoffice. Btw, i dont have a notion on how many tuples can a tumbling window exec comfortably hold. Ignoring all the computation i can do after i get those tuples, strictly talking about storm, is 1k ok? Are 100k ok? What are the variables to take in consideration to foresee the soft cap here? On Thu, Jun 23, 2016 at 8:10 PM, Satish Duggana <[email protected]> wrote: > Hi Alberto, > What is the use case for changing window duration/count at runtime? > > Thanks, > Satish. > > On Thu, Jun 23, 2016 at 11:56 PM, Alberto São Marcos < > [email protected]> wrote: > >> Thks Satish. >> >> On Thu, Jun 23, 2016 at 7:22 PM, Satish Duggana <[email protected] >> > wrote: >> >>> No, you can not change windowing configuration at runtime. >>> >>> Thanks, >>> Satish. >>> >>> On Thu, Jun 23, 2016 at 11:36 PM, Alberto São Marcos < >>> [email protected]> wrote: >>> >>>> Like the title states, can one change the window bolt length/count in >>>> runtime? >>>> Already tried to do it using BaseWindowedBolt API but a NPE is thrown. >>>> The property *Map<String, Object> windowConfiguration *is transient >>>> and not available in runtime. >>>> >>>> Is there any way to update the window length/count configuration >>>> programmatically after the topology has been bootstrapped? >>>> >>>> >>> >> >
