Archive for the ‘java’ tag
If you’re using GemFire in your software, there’s a good chance you’d like to build it using Maven. GemFire is hosted in a Maven repository but the details don’t seem to be documented, so this post is a bit of a “Missing Manual” entry.
It’s pretty easy, you need to set up the GemFire repository and add it as a dependency in your pom.xml.
<repositories> <repository> <id>gemstone</id> <url>http://dist.gemstone.com.s3.amazonaws.com/maven/release/</url> </repository> </repositories>
<dependency> <groupId>com.gemstone.gemfire</groupId> <artifactId>gemfire</artifactId> <version>6.6</version> </dependency>
If you want to see all the versions of GemFire available you can on the repo root page.
I used this in the course of putting together a Continuous Query client for GemFire, which lets you run SQL-like queries against GemFire that returns matches in real-time as data enters GemFire. So you can run something like “SELECT * from /myregion WHERE totalsale > 100″ and any time an object is inserted into GemFire that has a totalsale value greater than 100 you’re immediately notified of it. It’s pretty interesting and the client is a nice way to interactively discover the system’s capabilities.
One other thing that might not be totally obvious is that GemFire is free for development use, there is a non-expiring license to use it for up to 3 connections (clients or members in the distributed system), so feel free to try it out, play around give feedback.
I tried not to get a swelled head when Stu Radnidge conferred divine status upon me some years ago. After all Stu grew up in the Australian wilderness and I suppose riding a kangaroo to school every day could lead to a warped sense of reality.
So it was refreshingly deflating to find that nobody even noticed my VMworld session (2917 vote for me). In fact permit me to helpfully reproduce what you would have seen if you had voted for me as you should.
Elastic Memory for Java is a project I’ve been helping out with for the past year or so that aims to let you run Java apps on ESX without having to give them all their memory all the time. Java apps run great on ESX, so long as they have all the memory they want. If they don’t, things can go south really quick.
This is a big problem because Java likes to be lazy about cleaning up after itself, and prefers to hold on to every piece of trash and dead memory in sight until it nearly collapses under its own weight. It’s sort of like the software world’s answer to the Collyer brothers.
This behavior also explains why traditional ballooning in ESX doesn’t work well with Java. EM4J is different because it’s designed to work within Java and has intimate understanding of what’s happening in the Java app. If you wanna find out more, you gotta come to the session.
Why is VMware doing this you ask?
- Efficiency is in.
- We’re on the precipice of an app explosion. We’ve already seen it in consumer space, more special purpose apps that individually do less than monolithic apps of the past. This is infiltrating enterprise and when it does we need an order-of-magnitude or two more consolidation to cope with it.
- Oh yeah and cloud. Cloud cloud cloud cloud cloud. There I said it.
P.S. If you’re interested in trying Elastic Memory for Java out, we’re running a select beta. Message me on twitter or email me at cshanklin at vmware com and let me know you’re out there.
Otherwise see you in Vegas!