Mixing use of Gemfire API & Spring

[JGS]

Are there any code samples that demonstrate the use of the Spring/GemFire libraries and the Gemfire api directly. I would like to use the Gemfire API to programmatically instantiate locators & cache-servers during the startup on my spring application, and then go on to use the Spring-Gemfire namespace to subsequently manage and use the cache and Regions.
Does this mixing of api access cause any problems?
Again, any examples would be a great help

[Costin Leau]

The hello-world sample is a great start. Seems the latest milestones missed on that but you can find in the master (or the 1.0.x distros).

[kiril]

Locators should not be the part of cache server. You should run locator on separate JVM. If you want to run on VM locator and cache server write bash script.

If you use GemFire only as distributed cache. Your cache servers no need any Spring Integration. It will be enough just run cacheserver with cache configurations. On your client side you will have Spring Integration, witch is quite simple.

Client:

<gfe:pool id="gemfire-pool">
  <gfe:locator host="localhost" port="40403"/>
</gfe:pool>
<gfe:client-region id="complex" pool-name="gemfire-pool">
</gfe:client-region>

If you want to have custom code in your cache servers, like listeners, loaders, write-behind, functions...
Your cache configuration should looks like:

<gfe:cache />

<gfe:replicated-region id="complex">
  <gfe:cache-listener>
    <!-- nested cache listener reference -->
    <ref bean="c-listener"/>
    <!-- nested cache listener declaration -->
    <bean class="some.pkg.SimpleCacheListener"/>
  </gfe:cache-listener>
  <!-- loader reference -->
  <gfe:cache-loader ref="c-loader"/>
  <!-- writer reference -->
  <gfe:cache-writer ref="c-writer"/>
</gfe:replicated-region>

Any way for better GemFire understanding. I recommend to start with simple GemFire application and after try to move it to Spring GemFire integration.

The Spring GemFire documentation is very useful: http://static.springsource.org/sprin...-reference.pdf
GemFire tutorial: http://community.gemstone.com/displa...mFire+Tutorial

[JGS]

Thanks for the replies. I had intended to run the locators and cache-servers in separate processes, but to create them using the com.gemstone.gemfire.admin API - the reason for this was to avoid kicking off these separately via batch script (my spring app will be kicked off running on Tomcat).

Just trying to keep the startup simple

My intent is to run a series of Spring apps acting as simple peer-to-peer network, so maybe as you say, I don't really need to use the Spring Integration features?

[kiril]

If you use peer-to-peer, you can use multicasting and do not use locators. But if you run servers in separate networks, multicasting don't work correctly. Data grids have a lot of configurations and tunnigs. If you run your application on 32 bit JVM your tomcat instance can have only 4GB heap maximum. So for cache it's could be only 2GB. Using P2P each time you need to scale your cache you need to add one more tomcat instance. It's better to start with capacity plan and try to understand what you want get at the end.

If your application is written with Spring framework, it's better to use Spring GemFire integration. Easy to create loaders, listeners and get access to caches. For what purpose you need In-Memory Data Grid? Is it L2, session, user level or application level cache.

[JGS]

Looking through the GemFire doc, I was intending to use separate locators/ cache-servers and tcp because this looks to be recommended for HA production systems.

I don't expect to have to cache large amounts of data, but agreed, I do need to start thinking about a capacity plan.

I intend to write a set of business service components within Spring apps that I can horizontally scale across multiple servers, and use GemFire to share data, when required, between these multiple component instances

thanks

[Udo]

@JGS maybe a little late to the party: Multicasting in GemFire is possible. BUT once again in many commercial networks multicasting is not a preferred method. I have not come across a network admin that would let me use multicast on their network.

Using pure clients in a multicast server cluster is quite hard. As you would then have to create a pool pointing to a single server, which would not be HA, as the server might fail and you loose connectivity....

Use locators.. I would say, they are the "recommended" way. You can't go wrong with it It also makes it easier to scale your cluster, as you can just add servers, without the concern of having to reconfigure the client to access the correct data... AND the other big win is that when you access data on partitioned regions, you can use single-hop optimisation, whereas using direct server client pool connections, you would ALWAYS incur a multi-hop data action.

[shahzaibahmed]

The hello-world sample is a great start. Seems the latest milestones missed on that but you can find in the master (or the 1.0.x distros).

[sheridan16]

that may be a good idea