[
https://issues.apache.org/jira/browse/STORM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297679#comment-14297679
]
Robert Joseph Evans commented on STORM-634:
-------------------------------------------
I am fine with using a map if we really want to. Even moving heartbeats to a
separate service would not necessarily be that bad. The important thing for me
is not the initial change, but the discipline in future changes to not break
that compatibility. Thrift to me is not as simple to use as a map, and as such
developers will think twice about making changes to it. Also any changes to it
will send up flags compared to adding in a new item in a map. But if we are
very careful in our reviews we don't need to put in artificial pain just to
make people do the right thing. I like the mk-* methods and adding comments to
be sure that everyone knows that these are intended to be forwards/backwards
compatible.
> Storm should support rolling upgrade/downgrade of storm cluster.
> ----------------------------------------------------------------
>
> Key: STORM-634
> URL: https://issues.apache.org/jira/browse/STORM-634
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Parth Brahmbhatt
> Assignee: Parth Brahmbhatt
>
> Currently when a new version of storm is released in order to upgrade
> existing storm clusters users need to backup their existing topologies , kill
> all the topologies , perform the upgrade and resubmit all the topologies.
> This is painful and results in downtime which may not be acceptable for
> "Always alive" production systems.
> Storm should support a rolling upgrade/downgrade deployment process to avoid
> these downtimes and to make the transition to a different version effortless.
> Based on my initial attempt the primary issue seem to be the java
> serialization used to serialize java classes like StormBase, Assignment,
> WorkerHeartbeat which is then stored in zookeeper. When deserializing if the
> serial versions do not match the deserialization fails resulting in processes
> just getting killed indefinitely. We need to change the Utils/serialize and
> Utils/deserialize so it can support non java serialization mechanism like
> json.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
