[
https://issues.apache.org/jira/browse/STORM-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109840#comment-14109840
]
Jason Kania commented on STORM-467:
-----------------------------------
I think that this is an issue of cache cleanup. However, if there is a
possibility for mismatches due to merged classpaths, it would make sense to
actively seek these out and issue a warning given the number of classes that
storm will load on its own. I remember seeing an application sometime back that
just populated a HashMap with the fully qualified class name as the key and the
source directory of the jar as the value. When hashing found a duplicate, a
warning was raised so that a person knew which two jars conflicted. Just a
thought.
> storm jar executes non-existant or old jar files and classes
> ------------------------------------------------------------
>
> Key: STORM-467
> URL: https://issues.apache.org/jira/browse/STORM-467
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Affects Versions: 0.9.2-incubating
> Environment: debian linux wheezy and squeeze with java 1.7.0_67
> Reporter: Jason Kania
> Attachments: Exclamation.jar, Exclamation2.jar, ExclamationBolt.java,
> ExclamationTopology.java
>
>
> When issuing the storm jar command, the command will launch with some cached
> version of the jar contents even if no jar file is now present at the
> location specified on the command line. This should instead cause an error so
> that a user is actually running what they think they are.
> The second part of this is that some part of storm is caching topology
> classes so that when debugging errors, old code is executed instead of the
> new version of a class. I would argue that storm should attempt to destroy
> cached topology classes if presented with a new version or when an active
> topology is terminated. Again this is to avoid running versions of code that
> are not those which have been specified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
