Re: Why do Datastax docs recommend Java 6?
Oracle now owns the sun hotspot team, which is inarguably the highest powered java vm team in the world. Its still really the epicenter of all java vm development. Sent from my Verizon Wireless BlackBerry -Original Message- From: "Ilya Grebnov" Date: Tue, 5 Feb 2013 14:09:33 To: Reply-To: user@cassandra.apache.org Subject: RE: Why do Datastax docs recommend Java 6? Also, what is particular reason to use Oracle JDK over Open JDK? Sorry, I could not find this information online. Thanks, Ilya From: Michael Kjellman [mailto:mkjell...@barracuda.com] Sent: Tuesday, February 05, 2013 7:29 AM To: user@cassandra.apache.org Subject: Re: Why do Datastax docs recommend Java 6? There have been tons of threads/convos on this. In the early days of Java 7 it was pretty unstable and there was pretty much no convincing reason to use Java 7 over Java 6. Now that Java 7 has stabilized and Java 6 is EOL it's a reasonable decision to use Java 7 and we do it in production with no issues to speak of. That being said there was one potential situation we've seen as a community where bootstrapping new node was using 3x more CPU and getting significantly less throughput. However, reproducing this consistently never happened AFAIK. I think until more people use Java 7 in production and prove it doesn't cause any additional bugs/performance issues Datastax will update their docs. Until now I'd say it's a safe bet to use Java 7 with Vanilla C* 1.2.1. I hope this helps! Best, Michael From: Baron Schwartz Reply-To: "user@cassandra.apache.org" Date: Tuesday, February 5, 2013 7:21 AM To: "user@cassandra.apache.org" Subject: Why do Datastax docs recommend Java 6? The Datastax docs repeatedly say (e.g. http://www.datastax.com/docs/1.2/install/install_jre) that Java 7 is not recommended, but they don't say why. It would be helpful to know this. Does anyone know? The same documentation is referenced from the Cassandra wiki, for example, http://wiki.apache.org/cassandra/GettingStarted - Baron
Re: higher layer library makes things faster?
Actually its not uncommon at all. Any caching implemented on a higher level
will generally improve speed at a cost in memory.
Beware common wisdom, its seldom very wise
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: "Hiller, Dean"
Date: Wed, 19 Sep 2012 07:35:07
To: user@cassandra.apache.org
Reply-To: user@cassandra.apache.org
Subject: higher layer library makes things faster?
So there is this interesting case where a higher layer library makes things
slower. This is counter-intuitive as every abstraction usually makes things
slower with an increase in productivity.It would be cool if more and more
libraries supported something to help with this scenario I think.
The concept. Once in a while you end up needing a new query into an noSQL
data model that already exists, and you do something like this
UserRow user = fetchUser(rowKey);
List mappings = fetchRoleMappings(user.getRoleMappingIds())
List rowKeys = new ArrayList();
for(RoleMapping m : mappings) {
rowKeys.addAll(m.getGroupIds());
}
List groups = fetchGroupRows(rowKeys);
It turns out if you index stuff, it is much faster in a lot of cases. Instead
you can scan just 2 index rows to find the keys for the groups and read them
in. Basically you do one scan on the RoleMapping where mapping has a FK to
UserRow and you now have a list of primary keys for your RoleMapping. Next,
you do a scan of the GroupRow index feeding in the primary keys of your
RoleMapping which feeds back your GroupRow primary keys that you need to
lookup….in this way, you skip not only a lot of coding that goes into avoiding
getting all the UserRow data back, and can simply scan the indexes.
That said, every time you update a row, you need to remove an old value from
the index and a new one to the index. Inserts only need to add. Removes only
need to remove.
Anyways, I have found this to be quite an interesting paradigm shift as right
now doing the latter manually requires a lot more code (but then, that is why
more and more libraries like playOrm I think will exist in the future as it
makes the above very simple to do yourself).
Later,
Dean
