[
https://issues.apache.org/jira/browse/STORM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312570#comment-14312570
]
ASF GitHub Bot commented on STORM-634:
--------------------------------------
Github user Parth-Brahmbhatt commented on a diff in the pull request:
https://github.com/apache/storm/pull/414#discussion_r24351380
--- Diff: storm-core/src/clj/backtype/storm/converter.clj ---
@@ -0,0 +1,200 @@
+(ns backtype.storm.converter
--- End diff --
I actually have a version that attempts to use thrift object directly but
in process of doing that I realized I am just writing the converters at several
places or I am writing a custom getter method for thrift objects. The code does
not use these objects but uses the fields inside these objects and passes the
value of the field around different functions. Each function also makes certain
assumptions like a map is always a clojure map and thus its iterable, or some
list is always sorted or the first element of some list is a string and the
second is integer. You can see these assumptions being fulfilled by the
converter right now but in absence of it I had to modify a lot of code all over
the code base. So I decided to focus on just making rolling upgrade possible
first and nailing down the correct thrift structures which it self seemed like
a big enough win.
Here is the code that attempts to do what you are suggesting, its not
complete but kind of gives you an idea why it might not be a good idea to
undertake that task as part of this PR
https://github.com/Parth-Brahmbhatt/incubator-storm/compare/thrift-structures?expand=1
> 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)
