Yes slowness is my concern, my consumer process in the spout will be
stopped and start on after submitting the topology. So it is treated as a
downtime.

On Sat, Sep 21, 2024 at 9:33 PM Rui Abreu <rui.ab...@gmail.com> wrote:

> >
> > If I add all dependencies in the topology jar it's size is too large
> around
> > 350MB.
> >
>
> Do you get an error when uploading the uber jar? Or is it just slow?
>
> I believe the most practical process is indeed the submission of all
> dependencies on a single bundle. That's how I've always been using Storm.
>
>
> On Sat, 21 Sept 2024 at 06:41, Karthick <ibmkarthickma...@gmail.com>
> wrote:
>
> > Thanks for the reply Aaron, Rui
> >
> > Why do you need to update dependencies on external-lib on both Nimbus
> > > and Supervisor?
> >
> >
> > Like we may use jackson, kafka client, apache commons, other internal
> > frameworks jars and other third parties jars, so we do have those in the
> > external-lib, on the jar version changes we do change those jars in
> > external-lib.
> >
> >
> > Are you not submitting an uber-jar with all your dependencies plus
> > > your topology?
> >
> > If I add all dependencies in the topology jar it's size is too large
> around
> > 350MB.
> >
> >
> > Announce deployment well ahead of time - allowing users to plan switches
> to
> > > other clusters if desired.
> >
> >
> >  Aaron, i'm asking for the topology code changes and internal jar version
> > changes update. Not for upgrading the Storm version, sorry for not
> setting
> > proper questions here.
> >
> > On Fri, Sep 20, 2024 at 8:57 PM Rui Abreu <rui.ab...@gmail.com> wrote:
> >
> > > Hello  Karthick,
> > > Why do you need to update dependencies on external-lib on both Nimbus
> > > and Supervisor?
> > > Are you not submitting an uber-jar with all your dependencies plus
> > > your topology?
> > >
> > >
> > >
> > > On Fri, 20 Sept 2024 at 08:10, Karthick <ibmkarthickma...@gmail.com>
> > > wrote:
> > > >
> > > > Dear Apache Storm Community,
> > > >
> > > > I am currently managing an Apache Storm cluster with 38 nodes: 3
> > > dedicated
> > > > to ZooKeeper, 1 to Nimbus and the UI, and 34 nodes running Supervisor
> > and
> > > > Logviewer processes. Each node has 2 Workers.
> > > >
> > > > At present, our topology update process involves the following steps:
> > > >
> > > >    1. Killing the existing topology.
> > > >    2. Changing dependency JARs under the external-lib dir and
> > restarting
> > > >    Nimbus.
> > > >    3. Changing dependency JARs  under the external-lib dir and
> > restarting
> > > >    Supervisors.
> > > >    4. Submitting the new topology.
> > > >
> > > > Each operation takes about 2–3 minutes. As the number of Supervisor
> > nodes
> > > > increases, the overall time for topology updates is becoming a
> concern.
> > > >
> > > > I am reaching out to seek advice on how to optimize this process, as
> I
> > > > believe there are more efficient ways to handle topology updates in
> > > > large-scale Storm deployments. Specifically:
> > > >
> > > >    - Is there a more efficient process to handle code changes without
> > > >    having to manually restart Nimbus and Supervisors?
> > > >    - How can I reduce the overall time for topology updates,
> especially
> > > as
> > > >    our cluster continues to grow?
> > > >    - Are there industry-standard practices for implementing rolling
> > > updates
> > > >    or automating the deployment process?
> > > >
> > > > Any insights, recommendations, or best practices that could help
> > > streamline
> > > > our update process would be greatly appreciated.
> > > >
> > > > Thank you for your time, and I look forward to your suggestions!
> > >
> >
>

Reply via email to