Apache Geode (GemFire) in a Docker container

Apache Geode (GemFire) in a Docker container

If you want to play around with geode in docker, try this...

docker run -it apache geode/geode:1.0.0-incubating.M1.RC1 gosh

GemFire - Starting An ApplicationContext on the Gemfire Node

GemFire - Starting An ApplicationContext on the GemFire Node

so in digging around in a use case that a colleague mentioned, there's a feature that is part of GemFire that allows for the invocation of a class after the cache is initialized (on a server).  this is neat little piece of functionality which allows for spooling up of components on the actual cache server side.

why would you do this? startup a spring application context for sharing amongst cache listeners?

so, here's a quick sample; first the cache.xml

  
  
  
   de.incompleteco.gemfire.initializer.Initializer
  

and now the class

package de.incompleteco.gemfire.initializer;

import java.util.Properties;

import com.gemstone.gemfire.cache.Declarable;

public class Initializer implements Declarable {

 public void init(Properties properties) {
  //put some stuff here --> maybe an app context
 }

 
}

Caching, Spring and Reducing the 'first hit' Time

Caching, Spring and Reducing the 'first hit' Time

recently a colleague was working on a Jdbc Caching issue.  The underlying database supporting was of a similar nature to SQLFire; that is, distributed with a cache on top.  What was the pain was that the 'first hit' to the database triggered the underlying service to go and gather all the information from the distribution and cache the query's result set.  This lead to about a 6x performance cost compared to subsequent caches.  The question was, how to reduce this from the poor user who hits it first?


ApplicationListener is feature in Spring that allows you to create your own implementation and received the context just after it's started up.  In this case, this would allow the application context to have all the accessible beans fully populated and initialized.  This allows us, in the case above, to call the respective Service during startup time, triggering the underlying data service to run the 'first hit'.  The end result is that the 'first hit' is taken care of on startup, and, depending on how caching is managed, the user shouldn't experience the 'first hit' lag (as it's already completed) when they access their services.

here's a sample

Spring Integration and GemFire

Spring Integration and GemFire

here's a quick sample of using Spring Integration as a walk-up start to GemFire.  once you get going with this, it's easy to expand and leverage the full potential of it

here's an example of an entity



here's the supporting enum



here's the service to interact with it



now lets setup the gemfire part using the Spring GemFire namespace



and lets setup the Spring Integration to use the GemFire configuration



now, as always, here's a unit test to confirm it's all up and running...



here's the maven that got me across the line; getting GemFire package can be a bit tricky...