[
https://issues.apache.org/jira/browse/STORM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312444#comment-14312444
]
ASF GitHub Bot commented on STORM-634:
--------------------------------------
Github user revans2 commented on a diff in the pull request:
https://github.com/apache/storm/pull/414#discussion_r24342731
--- Diff: storm-core/src/clj/backtype/storm/converter.clj ---
@@ -0,0 +1,200 @@
+(ns backtype.storm.converter
--- End diff --
I personally would rather see the code use the Thrift objects directly.
One of the reasons I wanted to have Thrift over just using maps, was that it
would force a developer to think about any changes that make. To me having
this here means that someone will add something to Assignment for example and
not update this. Then it will work just fine in local mode testing, but will
not work in a real cluster, and would be a pain to debug.
> 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)