[
https://issues.apache.org/jira/browse/STORM-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878592#comment-17878592
]
Hugo Abreu commented on STORM-3720:
-----------------------------------
Hello [~agresch],
While fixing this issue, we have introduced one a bit more tricky to find (see:
[https://issues.apache.org/jira/projects/STORM/issues/STORM-4077]).])
Essentially, by using the modTime as the version, we have found that, while
using the {{{}LocalFsBlobStoreFile{}}}, everytime the the Nimbus leader goes
down the following occurs:
# Nimbus (1) leader goes down and a new Nimbus (2) picks up the leadership.
# If blobs in Nimbus (2) have a different modTime workers are restarted (even
though they might be the same).
# Nimbus (1) comes back up, syncs the blobs in the startup and updates the
modTime, as it downloads the blobs again.
# If Nimbus (2) leader goes down, all the workers will be restarted again as
Nimbus (1) has new modTime again.
# This can be repeated endless as the modTime will always be different in each
Nimbus leader.
We'll try and open a new PR that instead of using the modTime as the version
we'll try to make a hashCode of the file itself (or a hashCode of the SHA1 of
the contents of the file).
> BlobStoreFile getModTime() never updates after first call
> ---------------------------------------------------------
>
> Key: STORM-3720
> URL: https://issues.apache.org/jira/browse/STORM-3720
> Project: Apache Storm
> Issue Type: Bug
> Reporter: Aaron Gresch
> Assignee: Aaron Gresch
> Priority: Minor
> Fix For: 2.3.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If a blobstore file gets updated after a call to getModTime(), it will get an
> incorrect result
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
