[
https://issues.apache.org/jira/browse/STORM-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481344#comment-14481344
]
ASF GitHub Bot commented on STORM-671:
--------------------------------------
Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/442#issuecomment-90122615
Overall things look fairly good. The only issue is that we are adding in
new data to the heartbeat. If we want to be able to do a rolling upgrade we
need to make sure that the new stat change is optional, and that we don't
expect it to always be there when we read. For example there is a topology up
and running. If nimbus is upgraded before any of the workers are, nimbus will
crash because the new data is not there. Similarly if the ui is updated before
nimbus is.
> Measure tuple serialization/deserialization latency.
> ----------------------------------------------------
>
> Key: STORM-671
> URL: https://issues.apache.org/jira/browse/STORM-671
> Project: Apache Storm
> Issue Type: New Feature
> Reporter: Robert Joseph Evans
> Assignee: Kai Sasaki
>
> Some times the serialization/deserialization cost can be very high, and it is
> not currently measured anywhere in storm. We should measure it, at least in
> a similar way to how we do execute and process latency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
