[
https://issues.apache.org/jira/browse/STORM-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Kania updated STORM-467:
------------------------------
Attachment: ExclamationTopology.java
ExclamationBolt.java
Exclamation2.jar
Exclamation.jar
A simple example to demonstrate the problem is the following:
Use a version of the ExclamationTopology class where the ExclamationBolt is
extracted to its own class. Create one jar, Exclamation.jar, with both classes
included. Create a second jar, Exclamation2.jar, with only the
ExclamationTopology class included.
Run the first jar in storm and then kill it from the UI after a few minutes
from the UI:
storm jar /home/jason/storm/application/Exclamation.jar
com.server.analyzing.test.ExclamationTopology test
Next run the second jar in storm and then kill it from the UI after a few
minutes from the UI:
storm jar /home/jason/storm/application/Exclamation2.jar
com.server.analyzing.test.ExclamationTopology test
The second jar lacks the important ExclamationBolt class but runs in my
installation on debian because it references some cached version of the class.
No error is raised that I see. The storm installation is simply a download and
extract of the tar.gz from the apache storm website.
This is not the only scenario, but a simple one to create. The more difficult
scenario is when a class is updated with new functionality but an old version
of the class runs instead of the updated version. I am running with the Oracle
JDK.
> 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)
