Sorry for being unclear. I did in fact mean your own configuration source. For example you might pass the location of your configuration source through the storm configuration and then query it during your bolt's operation. As you may imagine you can use almost anything for your configuration store. Zookeeper, MySQL, Redis, etc etc.
On Mon, Feb 22, 2016 at 5:54 PM, Matan Safriel <[email protected]> wrote: > Thanks. And indeed, what you suggest has been my fallback plan. > Just to clarify I take it that you meant refresh their configuration from > whatever configuration mechanism of mine, not something related to Storm > configuration. I'm happy to learn in case you meant something else. > > On Tue, Feb 23, 2016 at 12:34 AM, Nathan Leung <[email protected]> wrote: > >> This isn't part of core storm functionality. You can code your bolts >> such that they refresh configuration periodically, but I'm not sure if that >> covers your use case. >> >> On Mon, Feb 22, 2016 at 4:39 PM, Matan Safriel <[email protected]> >> wrote: >> >>> Hi, >>> >>> I apologize if this has been answered before, but unlike google groups >>> mailing list archives are a bit hard to search in. >>> >>> I would like to learn whether it is possible to update a given bolt type >>> without loosing messages or sustaining any processing outage. >>> >>> In my fantasy, some sort of hot-swap taking place behind the scenes.. >>> while messages on the input stream for the bolts of the type being >>> upgraded, are being transparently queued during the swap ― and then passed >>> to the newly deployed version of the bolts when those become available in >>> their new version. >>> >>> Thanks, >>> Matan >>> >>> *P.S. could not be certain >>> following https://issues.apache.org/jira/browse/STORM-561 >>> <https://issues.apache.org/jira/browse/STORM-561> and existing SO questions >>> predating it.* >>> >>> >>> >> >
