Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/748
I committed another change. Everything seems to be working with this
additional fix. Would like @anandsubbu to add his experiences working with
this patch.
This problem started with #660 . I added a conditional to make sure that a
topology is actually running before trying to stop it and similar logic for
starting topologies. This introduced a subtle dependency in that the "is
running" conditional depends on the Storm UI/API. If the Storm UI/API is not
running, then it assumes the topology is already stopped. This is only a
problem if the Storm UI/API is stopped before Metron components.
We then attempted a fix in #680. There we added dependencies to
`STORM_REST_API-STOP` to ensure that all Metron topologies are stopped prior to
the Storm UI. This is necessary since the Metron MPack uses the Storm API to
check the status of topologies before shutting them down.
Unfortunately, this did not fix the problem, at least not in all cases. We
found instances where the Metron MPack was still unable to stop topologies
before Kerberization because the Storm UI/API had already been stopped.
After some sleuthing, it seems that the status checks depend on a process
running on port 8744.
I found that the storm component that listens on port 8744 is actually
called `STORM_UI_SERVER` by Ambari. So it is the `STORM_UI_SERVER` component
that we need to add the dependencies to. And this is what I have added in the
latest commit.
I am assuming that this is needed in addition to `STORM_REST_API`, but I am
not completely sure.
So I left the existing `STORM_REST_API` dependencies.
---
