The presentations from the Cassandra Summit in San Francisco are posted here:
http://www.planetcassandra.org/blog/post/cassandra-summit-2013---use-cases-and-technical-presentations
I listed some of my favourites below.
First would be my own presentation: "Crossing the Chasm - SQL to NoSQL": http://www.youtube.com/watch?v=wIjvZRLUXsE
Here is an awesome presentation on debugging Cassandra: "In Case Of Emergency, Break Glass":
http://www.youtube.com/watch?v=7lY-33_Hn0Q
Titan is an up and coming graph database: "Distributed Graph Computing with Titan and Faunus":
http://www.youtube.com/watch?v=tYAWhBHQiXA
Spotify talks about lessons learned using Cassandra: "How Not to Use Cassandra": http://www.youtube.com/watch?v=0u-EKJBPrj8
Monday, August 12, 2013
Sunday, March 24, 2013
Storm Dependency
Hello, I am Isaac Rieksts a Software Developer.
Today, I wanted to talk briefly about how I worked around a dependency conflict when including storm in a webservice.
Storm 0.8.2 has a direct dependency on commons-io 1.4, but includes compojure 1.1.3, which includes ring-core 1.1.5, which is dependent on commons-io 2.1. This caused a problem when a module I wrote pulled in commons-io 2.1 from an internal module. My module did not include storm.
So the deployment ended up choosing commons-io 1.4 to deploy and got an error: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.write(Ljava/io/File;Ljava/lang/CharSequence;Z)
Looks like this
Deployment bundler 0.0.1
- webservice module 0.0.1
- my module 0.0.1
- internal module 0.0.1
- commons-io 2.1
- storm 0.8.2
- commons-io 1.4
- compojure 1.1.3
- ring-core 1.1.5
- commons-io 2.1
To fix this: I managed commons-io at the web container level:
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>storm</groupId>
<artifactId>storm</artifactId>
<version>0.8.2</version>
<exclusions>
<exclusion>
<artifactId>commons-io</artifactId>
<groupId>commons-io</groupId>
</exclusion>
</exclusions>
</dependency>
Deployment bundler 0.0.1
- webservice module 0.0.1
- commons-io 2.1
- my module 0.0.1
- internal module 0.0.1
- commons-io 2.1
- storm 0.8.2 (Exclude commons-io)
- compojure 1.1.3
- ring-core 1.1.5
Now the deployment works fine with no problems.
Today, I wanted to talk briefly about how I worked around a dependency conflict when including storm in a webservice.
Storm 0.8.2 has a direct dependency on commons-io 1.4, but includes compojure 1.1.3, which includes ring-core 1.1.5, which is dependent on commons-io 2.1. This caused a problem when a module I wrote pulled in commons-io 2.1 from an internal module. My module did not include storm.
So the deployment ended up choosing commons-io 1.4 to deploy and got an error: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.write(Ljava/io/File;Ljava/lang/CharSequence;Z)
Looks like this
Deployment bundler 0.0.1
- webservice module 0.0.1
- my module 0.0.1
- internal module 0.0.1
- commons-io 2.1
- storm 0.8.2
- commons-io 1.4
- compojure 1.1.3
- ring-core 1.1.5
- commons-io 2.1
To fix this: I managed commons-io at the web container level:
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>storm</groupId>
<artifactId>storm</artifactId>
<version>0.8.2</version>
<exclusions>
<exclusion>
<artifactId>commons-io</artifactId>
<groupId>commons-io</groupId>
</exclusion>
</exclusions>
</dependency>
Deployment bundler 0.0.1
- webservice module 0.0.1
- commons-io 2.1
- my module 0.0.1
- internal module 0.0.1
- commons-io 2.1
- storm 0.8.2 (Exclude commons-io)
- compojure 1.1.3
- ring-core 1.1.5
Now the deployment works fine with no problems.
Subscribe to:
Posts (Atom)