Hi,

I’ve just moved to 0.9.2-incubating from 0.9.1-incubating today. The only way 
to be able to make it run was to remove all local data (/var/storm, in my case) 
and zookeeper data. After cluster was up and running, all supervisor nodes 
where visible in Storm UI, I  have redeployed the topologies. I do not think 
that we can name this “upgrade”. However in my case was not problematic to have 
it down for few hours.

The problem that Mike’s is mentioning, is caused by a curator framework used in 
storm, that depends on a older version of netty 3.2.2. Cassandra drive is using 
betty 3.6.3 or 3.9.0, depending on version of driver, but these 2 versions are 
backward compatible, where 3.2.2 is not.

A solution will be to use version 2.5.0 of curator framework that has some bugs 
fixed in the curator framework itself that probably benefit to Storm too. I 
depends on zookeeper 3.4.6 that is depending on netty 3.7.0, that also is 
compatible with 3.6.3 and 3.9.0.


Thanks,
-- 
Gabriel Ciuloaica


On 26 Jun 2014 at 15:20:56, Mike Heffner (m...@librato.com) wrote:

Taylor -

Thanks for the info.

Yeah, it would be great if future storm releases look at supporting mixed 
cluster releases -- where nimbus and/or supervisors can operate with mixed 
patch release versions. That would greatly simply rolling a storm cluster to a 
new release.


Cheers,

Mike


On Wed, Jun 25, 2014 at 7:27 PM, P. Taylor Goetz <ptgo...@gmail.com> wrote:
+dev@

Dependency conflicts can often be an issue when upgrading. Unfortunately we 
have no way to predict dependencies of user code. But there are ways to 
minimize it, so reports like this one are very useful (given a little more 
information about dependency versions).

Andrey, would you mind opening a JIRA ticket for this, and detail the versions 
involved?

Fixing this should just be a matter of shading Storm's Netty dependency.

Mike, the safest way to upgrade, if possible, is to undeploy all topologies, 
clear local state, and redeploy. Obviously it is critical to test this out in a 
pre-prod environment. Another option is to do a "warm swap" between clusters 
running different versions, but attached to the same data source. You basically 
pause one, let it drain, and activate the other. You would need the 
infrastructure to do this, however.

A lot of it depends on your data source and whether or not it can reliably 
handle pending messages during the upgrade.

It should go without saying, but I'll say it anyway: Test a lot in as close a 
facsimile of your prod environment as you can muster. And keep the relationship 
between dev and ops something worthy of a Hallmark card. ;)

There is a lot of interest in rolling upgrades for Storm as well. I'll open up 
JIRA tickets for both so we can track and discuss. We should at least provide 
some documentation, FAQ, etc.

-Taylor

On Jun 25, 2014, at 5:17 PM, Andrey Yegorov <andrey.yego...@gmail.com> wrote :

tried it; now getting NoSuchMethodError errors from netty/v.2.0 datastax's 
driver for cassandra.
fwiw, I rebuilt topology with storm 0.9.2 as dependency. reverting back.

java.lang.NoSuchMethodError: 
org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder.<init>(IIIIIZ)V
 at com.datastax.driver.core.Frame$Decoder.<init>(Frame.java:130) at 
com.datastax.driver.core.Connection$PipelineFactory.getPipeline(Connection.java:796)
 at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:212) 
at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:188) 
at com.datastax.driver.core.Connection.<init>(Connection.java:93) at 
com.datastax.driver.core.Connection$Factory.open(Connection.java:432) at 
com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:215)
 at 
com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:170)
 at 
com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:78) 
at 

----------
Andrey Yegorov


On Wed, Jun 25, 2014 at 1:18 PM, Mike Heffner <m...@librato.com> wrote:
Are there upgrade instructions from previous storm versions to 0.9.2?


On Wed, Jun 25, 2014 at 1:28 PM, P. Taylor Goetz <ptgo...@apache.org> wrote:
The Storm team is pleased to announce the release of Apache Storm version 
0.9.2-incubating. This is our second Apache release.

Storm is a distributed, fault-tolerant, and high-performance realtime 
computation system that provides strong guarantees on the processing of data. 
You can read more about Storm on the project website:

http://storm.incubator.apache.org

Downloads of source and binary distributions are listed in our download
section:

http://storm.incubator.apache.org/downloads.html

You can read more about this release in the following blog post:

http://storm.incubator.apache.org/2014/06/25/storm092-released.html

Distribution artifacts are available in Maven Central at the following 
coordinates:

groupId: org.apache.storm
artifactId: storm-core
version: 0.9.2-incubating

The full list of changes is available here[1]. Please let us know [2] if you 
encounter any problems.

Regards,

The Apache Storm Team

[1]: 
https://github.com/apache/incubator-storm/blob/v0.9.2-incubating/CHANGELOG.md 
(CHANGELOG)
[2]: https://issues.apache.org/jira/browse/STORM



--

  Mike Heffner <m...@librato.com>
  Librato, Inc.





--

  Mike Heffner <m...@librato.com>
  Librato, Inc.

Reply via email to