[
https://issues.apache.org/jira/browse/STORM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383528#comment-15383528
]
ASF GitHub Bot commented on STORM-634:
--------------------------------------
Github user danny0405 commented on the issue:
https://github.com/apache/storm/pull/414
@revans2 @HeartSaVioR Actually, i have an idea, but i'm not sure if it will
work correctly. Mainly because the compatibility of Supervisor LocalState and
Zookeeper metadata between different version of storm. Also because supervisors
are not start up at the same time, there is a time old and new storm code
worker working together of one topology. So, is there any problem?
1. when a supervisor first start up, write its version to LocalState
2. supervisor check if the LS version is same with current code version
3. if it's same do nothing, if it's different, kill all the workers on this
node
4. sync worker processes from LocalState and ZooKeeper.
> 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: Dependency upgrade
> Components: storm-core
> Reporter: Parth Brahmbhatt
> Assignee: Parth Brahmbhatt
> Fix For: 0.10.0
>
>
> 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)
