POJO caching in geronimo

[Xasima Xirohata]

Hi. I want to figure out what is the proper strategy to plug-in POJO cache into geronimo (2.1).
I want to use the different implementation of caching (HashMap,  EHCACHE, JCS) and work in standalone mode  (not explicit clustering support for the first time).

In the existed code we just want to get a cache instance using JNDI, cast this to java.util.Map and  invoke plain put/get methods.
I have explored geronimo docs and found the following possibilities:
    1) use the terracotta (http://www.terracotta.org/confluence/display/orgsite/Distributed+Caches) that exposes such an wrapper around different implementation.
    2) use the wadi and the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class somehow
    3) use the custom gbean as wrapper upon different implementation of caching (as the general solution for any separate custom services).

Unfortunately, the 70Mb size of Terracotta seems too heavy to use for such a use case when I don't plan to work with clustering at once.
I don't found a page to integrate this options with WADI, please provide some details on this..
So I have stopped with the last way. I think that having POJO cache exposed as gbean (instead of using as regular embedded jar) is a right strategy since it is quite naturally to
    1) implement initializing, clearing, storing (if persistence is on) of POJO cache when the correspondent geronimo lifecycle events occur
    2) providing different <attribute > </attribute> in the gbean plan to configure in external manner different  POJO cache parameters
    3) having MBean that reports on state and loads of the cache ( it may be interesting how  much objects are consumes from this and if we need to change expiration policy or allocate more size)

Am I right with the approach? Do you have any predefined gbeans (or prototype in sandbox code area) code for this?
Could I use WADI for this purpose?
--
Best regards,
~ Xasima Xirohata ~

[Gianny Damour-2]

Hello Xasima,

WADI does not yet provide a POJO caching solution.

Regarding the http://incubator.apache.org/wadi/wadi-core/apidocs/org/ 
codehaus/wadi/gridstate/impl/GCache.html class, AFAIK it was more an  
idea than an actual fully working caching implementation.

I know that a Geronimo POJO caching solution, GCache, was implemented  
a while back in the geronimo-sandbox and documented here http://
cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html.  
However, as this caching solution has not been touched for a while, I  
do not think it is in a working state.

The approach you are taking seems to me reasonable and I think it  
would be quite useful for other users to have such GBean services for  
JCS or EHCache.

FYI, I am currently working on the implementation of a hierarchical,  
transactional, distributed, partitioned and replicated cache and data-
grid solution as part of WADI. I hope to have a working solution at  
the end of the month and hopefully before you having the need for it :)

Thanks,
Gianny

On 01/05/2008, at 2:22 AM, Xasima Xirohata wrote:

> Hi. I want to figure out what is the proper strategy to plug-in  
> POJO cache into geronimo (2.1).
> I want to use the different implementation of caching (HashMap,  
> EHCACHE, JCS) and work in standalone mode  (not explicit clustering  
> support for the first time).
>
> In the existed code we just want to get a cache instance using  
> JNDI, cast this to java.util.Map and  invoke plain put/get methods.
> I have explored geronimo docs and found the following possibilities:
>     1) use the terracotta (http://www.terracotta.org/confluence/ 
> display/orgsite/Distributed+Caches) that exposes such an wrapper  
> around different implementation.
>     2) use the wadi and the http://incubator.apache.org/wadi/wadi- 
> core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class  
> somehow
>     3) use the custom gbean as wrapper upon different  
> implementation of caching (as the general solution for any separate  
> custom services).
>
> Unfortunately, the 70Mb size of Terracotta seems too heavy to use  
> for such a use case when I don't plan to work with clustering at once.
> I don't found a page to integrate this options with WADI, please  
> provide some details on this..
> So I have stopped with the last way. I think that having POJO cache  
> exposed as gbean (instead of using as regular embedded jar) is a  
> right strategy since it is quite naturally to
>     1) implement initializing, clearing, storing (if persistence is  
> on) of POJO cache when the correspondent geronimo lifecycle events  
> occur
>     2) providing different <attribute > </attribute> in the gbean  
> plan to configure in external manner different  POJO cache parameters
>     3) having MBean that reports on state and loads of the cache  
> ( it may be interesting how  much objects are consumes from this  
> and if we need to change expiration policy or allocate more size)
>
> Am I right with the approach? Do you have any predefined gbeans (or  
> prototype in sandbox code area) code for this?
> Could I use WADI for this purpose?
> --
> Best regards,
> ~ Xasima Xirohata ~

[Xasima Xirohata]

Hello, Gianny.  I have developed a very simple codebase to install POJO through GBean. It just exposes only java.util.Map as interface and uses HashMap as implementation. It's mainly the yet another example on writing gbean than clear implementation of the pluggable cache. I will put the basic code here (if someone will decide to do the same ) and  I will provide some ideas to enhance this and ask some question in the next letter.

POJOCacheGBean.java
----------------------
package com.w.geronimo.services.test.gbean;

import java.lang.reflect.Method;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.geronimo.gbean.GBeanInfo;
import org.apache.geronimo.gbean.GBeanInfoBuilder;
import org.apache.geronimo.gbean.GBeanLifecycle;

/**
 * POJO Cache GBean
 *
 */
public class POJOCacheGBean extends HashMap  implements GBeanLifecycle, Map {
 
  private static final long serialVersionUID = 1L;
  private static final GBeanInfo GBEAN_INFO;
  //TODO[CORE] figure out an actual object name
  private  String objectName = "CacheGBean";
  private String message;

  private static final Log log = LogFactory.getLog(POJOCacheGBean.class);

  /* --------------- GERONIMO KERNEL REGISTRATION ----------------- */

  static {
    GBeanInfoBuilder infoBuilder = new GBeanInfoBuilder(POJOCacheGBean.class
        .getName(), POJOCacheGBean.class);

    Method[] methods = HashMap.class.getMethods();
    Iterator it = Arrays.asList(methods).iterator();
    while(it.hasNext()) {
      Method m = (Method)it.next();
      infoBuilder.addOperation(m.getName(), m.getParameterTypes(), m.getReturnType().getName());
    }
    infoBuilder.addInterface(Map.class);
   
    infoBuilder.addAttribute("message", String.class.getName(), true);

    GBEAN_INFO = infoBuilder.getBeanInfo();
  }

  public static GBeanInfo getGBeanInfo() {
    return GBEAN_INFO;
  }

 
  public POJOCacheGBean(String message){
    this.message = message;  
  }
  public POJOCacheGBean() {
   
  }

  /* --------------- / GERONIMO KERNEL REGISTRATION ----------------- */

  /* --------------- EXPOSED API -------------------- */
  public String toString() {
    return "GBEAN cache";
  }
  public String getMessage() {
    return message;
  }
 
  /* --------------- / EXPOSED API ------------------ */

  /* --------------- GERONIMO life cycle -------------- */
  public void doFail() {
    log.info(objectName + "failed");

   
  }

  public void doStart() throws Exception {
    log.info("Starting " + objectName);
  }

  public void doStop() throws Exception {
    log.info("Stopping " + objectName);
 
  }
  /* --------------- / GERONIMO life cycle ------------- */

}

w-cache-gbean.xml  (Deployment Plan)
----------------------
<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
  <environment>
    <moduleId>
      <groupId>com.w.core.geronimo.services</groupId>
      <artifactId>pojo-cache</artifactId>
      <version>1.0</version>
      <type>car</type>
    </moduleId>
    <dependencies></dependencies>
  </environment>

  <gbean name="POJOCache" class="com.w.geronimo.services.test.gbean.POJOCacheGBean">
    <attribute name="message">configuration value</attribute>  
  </gbean>
</module>

pom.xml (Project description in terms of maven)
--------------------------
<?xml version="1.0" encoding="UTF-8"?>
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>w-core-geronimo-services</groupId>
  <artifactId>test-gbean</artifactId>
  <name></name>
  <version>1.0</version>
  <description></description>
  <dependencies>
    <dependency>
      <groupId>org.apache.geronimo.framework</groupId>
      <artifactId>geronimo-kernel</artifactId>
      <version>2.1</version>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.3</version>
    </dependency>

    <dependency>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
      <version>1.0.4</version>
    </dependency>
  </dependencies>

</project>


readme
--------------------------

======================== GERONIMO POJO cache gbean =========================
     @name GERONIMO POJO Cache GBEAN
     @date 1 May 2008
     @modification  {
         @date(1 May 2008) created
     }
     @component core-geronimo-services-test
=====================================================================================


DESCRIPTION
----------

This gbean provide the POJO cache functionality based on simple java.util.hashmap. It seems to
very easy switch the implementation to the more enhanced like EHCACHE and JCS.

TEST
----------
If you use eclipse do the following
1. Do right click on the project and choose MAVEN -> RUN -> Package...
You need to get  test-gbean-1.0.jar at the end of the process in the /target directory

2. We suppose that you use geronimo-2.1, so go to
http://localhost:8080/console/portal/Applications/Deploy%20New
choose the  /target/test-gbean-1.0.jar as Archive and the /target/w-cache-gbean.xml as the plan.
Check 'start app' and press install
You will get this GBEAN installed into geronimo as service successfully.

3. To ensure if everything is ok, just follow the link http://localhost:8080/console/portal/Applications/System%20Modules
You have to find an com.w.core.geronimo.services/pojo-cache/1.0/car  component in running state.

4. If you need to play and test the gbean a little bit more just go to
http://localhost:8080/console/portal/Debug%20Views/JMX%20Viewer
Choose ServiceModuleMBEANS and you find com.w.core.geronimo.services/pojo-cache/1.0/car  configuration gbean in the list. Expand this item and go to the gbean at its own. If you will choose 'operation' tab you will found all exposed operation and can play with them

5. To use the gbean from your application (for example, in WAR)  you need to place the following into geronimo-web.xml deployment plan
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"
  xmlns:security="http://geronimo.apache.org/xml/ns/security-2.0">
  <environment
    xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
    ....
      <dependencies>
      <dependency>
        <groupId>com.w.core.geronimo.services</groupId>
        <artifactId>pojo-cache</artifactId>
        <version>1.0</version>
        <type>car</type>
      </dependency>
    </dependencies>
   
    ...
    </environment>  
    <gbean-ref
    xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1">
    <ref-name>cache</ref-name>
    <ref-type>java.util.Map</ref-type>
    <pattern>
      <name>POJOCache</name>
    </pattern>
  </gbean-ref>
 
And get the cache in the following manner

  cache = (Map<String, Template>) new InitialContext()
          .lookup("java:comp/env/cache");

-----------------------------------

 

On Thu, May 1, 2008 at 6:22 AM, Gianny Damour <gianny.damour@...> wrote:

Hello Xasima,

WADI does not yet provide a POJO caching solution.

Regarding the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class, AFAIK it was more an idea than an actual fully working caching implementation.

I know that a Geronimo POJO caching solution, GCache, was implemented a while back in the geronimo-sandbox and documented here http://cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html. However, as this caching solution has not been touched for a while, I do not think it is in a working state.

The approach you are taking seems to me reasonable and I think it would be quite useful for other users to have such GBean services for JCS or EHCache.

FYI, I am currently working on the implementation of a hierarchical, transactional, distributed, partitioned and replicated cache and data-grid solution as part of WADI. I hope to have a working solution at the end of the month and hopefully before you having the need for it :)

Thanks,
Gianny

On 01/05/2008, at 2:22 AM, Xasima Xirohata wrote:

Hi. I want to figure out what is the proper strategy to plug-in POJO cache into geronimo (2.1).
I want to use the different implementation of caching (HashMap,  EHCACHE, JCS) and work in standalone mode  (not explicit clustering support for the first time).

In the existed code we just want to get a cache instance using JNDI, cast this to java.util.Map and  invoke plain put/get methods.
I have explored geronimo docs and found the following possibilities:
   1) use the terracotta (http://www.terracotta.org/confluence/display/orgsite/Distributed+Caches) that exposes such an wrapper around different implementation.
   2) use the wadi and the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class somehow
   3) use the custom gbean as wrapper upon different implementation of caching (as the general solution for any separate custom services).

Unfortunately, the 70Mb size of Terracotta seems too heavy to use for such a use case when I don't plan to work with clustering at once.
I don't found a page to integrate this options with WADI, please provide some details on this..
So I have stopped with the last way. I think that having POJO cache exposed as gbean (instead of using as regular embedded jar) is a right strategy since it is quite naturally to
   1) implement initializing, clearing, storing (if persistence is on) of POJO cache when the correspondent geronimo lifecycle events occur
   2) providing different <attribute > </attribute> in the gbean plan to configure in external manner different  POJO cache parameters
   3) having MBean that reports on state and loads of the cache ( it may be interesting how  much objects are consumes from this and if we need to change expiration policy or allocate more size)

Am I right with the approach? Do you have any predefined gbeans (or prototype in sandbox code area) code for this?
Could I use WADI for this purpose?
--
Best regards,
~ Xasima Xirohata ~

--
Best regards,
~ Xasima Xirohata ~

[Xasima Xirohata]

Hello, Gianny Damour and team. I want to list my questions and proposals to the possible architecture and features of the Geronimo POJO cache that WADI is going to implement soon.

Assume that we are exposing a POJO cache using GBean, so POJOCache is available through JNDI (new InitialContext().lookup("java:comp/env/cache")) if gbean-ref and dependencies is included into Geronimo specific deployment plan.  The following questions are interesting for me.

1)     I wonder what interfaces need to be exposed to access this POJO Cache. We need to list these interfaces in "implements …" block when declaring GBEAN and in gbean-ref / ref-type section. And developers will use the pojo cache using these (this) interface as well.

I suspect that we need at least the following interfaces: JSR-107 JCache related interfaces, plain java.util.Map, and the specific implementation (ehcache, jcs) if someone needs to use that implementation directly.

First of all I want to consider JCache. JCache standard is far from being a final and it is changing till now.  Here is the list of limitation of the current JSR standard http://ehcache.sourceforge.net/documentation/jsr107.html (see section "Problem and limitation"), so these limitations need to be worked around or just emphasized for the developer if we decided to expose JCache as the primary interface over geronimo pojo cache gbean.

The next question is on plain java.util.Map interface. In theory JCache (JCache.CacheMap) implements Map, so one may do the cast "(Map) jcache" if (s)he prefers plain Map over instantiating JCache or just uses Map in  code already.  However http://shevek.livejournal.com/84313.html complains on a slight incompatibility with the expected usage of Map, so  our pojo gbean might  play as wrapper to resolve this incompatibility as well.

The last issue on getting underline implementation can probably be easily solved with gettingBackingCache() method from JCache, although it quite interesting to figure out (from configuration or JMX) which implementation is tired with now.

2)     The next question is on the number of GBean, that related to the maintenance of pojo caching. Is the PojoCache gbean needs to be the only gbean related to the cache, or (in distributed case) it may act as wrapper to the actual ehcache/tabgosol/terracotta/wadi/jboss-cache-wrapper gbeans. In the later case we just need to raise up the target  gbean and provide all configuration to it, and later just wired the actual GBEAN with the remote (external) one. This may probably help to monitor and configure these caches in more subtle way and allow to remain everything in the target application the same (even a Geronimo-deployment descriptors), while just plug-in (hot-replace) any remote / distributed / multilayered caching solution even in runtime. Example, you just set up the application (war/ear) that have the only dependency o local POJO cache gbean, that is used fast JCS back end while no other authentificated plug-in discovering request occurs, but when this happens your caching solution becomes multi tired (hierarchical) with very light 1level local cache with specific expiration policy and 2level distributed (memcache-d aware) cache.

3)     The third question is on Statistic. We have some pretty tab on the JMX section in Geronimo that seems to be used as viewer some graphics on historical data. Really I don't know how to exposed some data from the Gbean to there, but it seems to be nice to have exposed such a parameters as number of hits per second, or the pluggable one statistic like "how many request in percent to the total are done to the specific part of our cached data" or "how many data are stored in the disk sue to short overflow of overall memory restriction for the given local cache" (when storing is switch on). The result of such a statistic is useful for capacity planning and tuning the system.

It's interesting not only to plug such a statistic and get this from regular Geronimo JMX tabs, but do this easily with no binding to the specific underline implementation. I suppose that this may be done if we just wrap any put / get methods of POJO GBean implements JCache with some JAMON  (*). Concrete interceptors (what collect in very specific cases) may be tired up  with GBean using AOP (**). Probably we need to integrate native JMX support for  such a project as well (***)

So we have three questions here: how to expose such a data to JMX statistic tab, how to add user defined interceptors, and how to configure (switch off such a tools on production when deploy or in runtime by JMX value)

4)     The next question is where to locate specific configuration files like ehcache.xml. The more precise question is where it is possible and appropriate to locate such a files. I suppose that local cache parameters (1level local cache gbean) may be located in war/ear, and the parameters for regular distributed cache (2level distributed cache gbean) needs to be located in config.xml  + var/config

5)     The last issue is to provide compact maven build  and maven subproject to easily install specific cache bundle (with no 70 mb of terracota, the WHOLE wadi or something else)

6) What do we  need to get reasonable  from http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/2.2.0.BETA1/userguide_en/html_single/index.html or Glassfish cashing?

 

 
(*) www.jamonapi.com

(**)http://www.ibm.com/developerworks/java/library/j-aopwork10/

(***)http://wiki.burnayev.com/page/JMX+Monitoring+of+Ehcache?t=anon

 

 What do you think on this?

    

On Thu, May 1, 2008 at 6:22 AM, Gianny Damour <gianny.damour@...> wrote:

Hello Xasima,

WADI does not yet provide a POJO caching solution.

Regarding the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class, AFAIK it was more an idea than an actual fully working caching implementation.

I know that a Geronimo POJO caching solution, GCache, was implemented a while back in the geronimo-sandbox and documented here http://cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html. However, as this caching solution has not been touched for a while, I do not think it is in a working state.

The approach you are taking seems to me reasonable and I think it would be quite useful for other users to have such GBean services for JCS or EHCache.

FYI, I am currently working on the implementation of a hierarchical, transactional, distributed, partitioned and replicated cache and data-grid solution as part of WADI. I hope to have a working solution at the end of the month and hopefully before you having the need for it :)

Thanks,
Gianny

On 01/05/2008, at 2:22 AM, Xasima Xirohata wrote:

Hi. I want to figure out what is the proper strategy to plug-in POJO cache into geronimo (2.1).
I want to use the different implementation of caching (HashMap,  EHCACHE, JCS) and work in standalone mode  (not explicit clustering support for the first time).

In the existed code we just want to get a cache instance using JNDI, cast this to java.util.Map and  invoke plain put/get methods.
I have explored geronimo docs and found the following possibilities:
   1) use the terracotta (http://www.terracotta.org/confluence/display/orgsite/Distributed+Caches) that exposes such an wrapper around different implementation.
   2) use the wadi and the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class somehow
   3) use the custom gbean as wrapper upon different implementation of caching (as the general solution for any separate custom services).

Unfortunately, the 70Mb size of Terracotta seems too heavy to use for such a use case when I don't plan to work with clustering at once.
I don't found a page to integrate this options with WADI, please provide some details on this..
So I have stopped with the last way. I think that having POJO cache exposed as gbean (instead of using as regular embedded jar) is a right strategy since it is quite naturally to
   1) implement initializing, clearing, storing (if persistence is on) of POJO cache when the correspondent geronimo lifecycle events occur
   2) providing different <attribute > </attribute> in the gbean plan to configure in external manner different  POJO cache parameters
   3) having MBean that reports on state and loads of the cache ( it may be interesting how  much objects are consumes from this and if we need to change expiration policy or allocate more size)

Am I right with the approach? Do you have any predefined gbeans (or prototype in sandbox code area) code for this?
Could I use WADI for this purpose?
--
Best regards,
~ Xasima Xirohata ~

--
Best regards,
~ Xasima Xirohata ~

[Gianny Damour-2]

Hello Xasima,


On 15/05/2008, at 7:20 AM, Xasima Xirohata wrote:

> Hello, Gianny Damour and team. I want to list my questions and  
> proposals to the possible architecture and features of the Geronimo  
> POJO cache that WADI is going to implement soon.
>
> Assume that we are exposing a POJO cache using GBean, so POJOCache  
> is available through JNDI (new InitialContext().lookup("java:comp/
> env/cache")) if gbean-ref and dependencies is included into  
> Geronimo specific deployment plan.  The following questions are  
> interesting for me.
>
> 1)     I wonder what interfaces need to be exposed to access this  
> POJO Cache. We need to list these interfaces in "implements …"  
> block when declaring GBEAN and in gbean-ref / ref-type section. And  
> developers will use the pojo cache using these (this) interface as  
> well.
>
> I suspect that we need at least the following interfaces: JSR-107  
> JCache related interfaces, plain java.util.Map, and the specific  
> implementation (ehcache, jcs) if someone needs to use that  
> implementation directly
>
>
>
> First of all I want to consider JCache. JCache standard is far from  
> being a final and it is changing till now.  Here is the list of  
> limitation of the current JSR standard http://
> ehcache.sourceforge.net/documentation/jsr107.html (see section  
> "Problem and limitation"), so these limitations need to be worked  
> around or just emphasized for the developer if we decided to expose  
> JCache as the primary interface over geronimo pojo cache gbean.
>

I am not convinced that JCache will ever be finalized. AFAIK it has  
been dead for couple of years now. I think a clean room caching API  
would have a better mileage than the JCache API.

According to me, if you need to have a caching solution now for your  
application, then I suggest you to take an implementation and  
directly bind your application to its API. It should be easy to  
migrate your application from one caching implementation to another  
one w/o too much changes to your application further down the track  
if the need arises.

>
> 2)     The next question is on the number of GBean, that related to  
> the maintenance of pojo caching. Is the PojoCache gbean needs to be  
> the only gbean related to the cache, or (in distributed case) it  
> may act as wrapper to the actual ehcache/tabgosol/terracotta/wadi/
> jboss-cache-wrapper gbeans. In the later case we just need to raise  
> up the target  gbean and provide all configuration to it, and later  
> just wired the actual GBEAN with the remote (external) one. This  
> may probably help to monitor and configure these caches in more  
> subtle way and allow to remain everything in the target application  
> the same (even a Geronimo-deployment descriptors), while just plug-
> in (hot-replace) any remote / distributed / multilayered caching  
> solution even in runtime. Example, you just set up the application  
> (war/ear) that have the only dependency o local POJO cache gbean,  
> that is used fast JCS back end while no other authentificated plug-
> in discovering request occurs, but when this happens your caching  
> solution becomes multi tired (hierarchical) with very light 1level  
> local cache with specific expiration policy and 2level distributed  
> (memcache-d aware) cache.
>

If you want to move forward with JCS, then you need to identify the  
JCS services you want to turn into GBeans. For instance, you may want  
to define a GBean to configure AuxiliaryCache, another one to access  
a specific cache region from JCS et cetera. The idea is that instead  
of relying on JCS configuration files to configure your cache, you  
configure it by defining GBeans and wiring them together.

>
>
> 3)     The third question is on Statistic. We have some pretty tab  
> on the JMX section in Geronimo that seems to be used as viewer some  
> graphics on historical data. Really I don't know how to exposed  
> some data from the Gbean to there, but it seems to be nice to have  
> exposed such a parameters as number of hits per second, or the  
> pluggable one statistic like "how many request in percent to the  
> total are done to the specific part of our cached data" or "how  
> many data are stored in the disk sue to short overflow of overall  
> memory restriction for the given local cache" (when storing is  
> switch on). The result of such a statistic is useful for capacity  
> planning and tuning the system.
>
> It's interesting not only to plug such a statistic and get this  
> from regular Geronimo JMX tabs, but do this easily with no binding  
> to the specific underline implementation. I suppose that this may  
> be done if we just wrap any put / get methods of POJO GBean  
> implements JCache with some JAMON  (*). Concrete interceptors (what  
> collect in very specific cases) may be tired up  with GBean using  
> AOP (**). Probably we need to integrate native JMX support for  
> such a project as well (***)
>
> So we have three questions here: how to expose such a data to JMX  
> statistic tab, how to add user defined interceptors, and how to  
> configure (switch off such a tools on production when deploy or in  
> runtime by JMX value)
>

I believe it should be up to the underlying cache implementation to  
provide necessary statistics. Our your side, you simply need to wrap  
the underlying implementation and expose the provided statistics as  
GBean attributes. GBean attributes are available as MBean attributes  
so you've got the JMX part sorted out.
>
> 4)     The next question is where to locate specific configuration  
> files like ehcache.xml. The more precise question is where it is  
> possible and appropriate to locate such a files. I suppose that  
> local cache parameters (1level local cache gbean) may be located in  
> war/ear, and the parameters for regular distributed cache (2level  
> distributed cache gbean) needs to be located in config.xml  + var/
> config
>
Configuration files should not be needed as you should configure the  
cache by defining GBeans.

Thanks,
Gianny

> 5)     The last issue is to provide compact maven build  and maven  
> subproject to easily install specific cache bundle (with no 70 mb  
> of terracota, the WHOLE wadi or something else)
>
> 6) What do we  need to get reasonable  from http://www.jboss.org/ 
> file-access/default/members/jbosscache/freezone/docs/2.2.0.BETA1/
> userguide_en/html_single/index.html or Glassfish cashing?
>
>
> (*) www.jamonapi.com
>
> (**)http://www.ibm.com/developerworks/java/library/j-aopwork10/
>
> (***)http://wiki.burnayev.com/page/JMX+Monitoring+of+Ehcache?t=anon
>
>
>  What do you think on this?
>
>
>
>
> On Thu, May 1, 2008 at 6:22 AM, Gianny Damour  
> <gianny.damour@...> wrote:
> Hello Xasima,
>
> WADI does not yet provide a POJO caching solution.
>
> Regarding the http://incubator.apache.org/wadi/wadi-core/apidocs/ 
> org/codehaus/wadi/gridstate/impl/GCache.html class, AFAIK it was  
> more an idea than an actual fully working caching implementation.
>
> I know that a Geronimo POJO caching solution, GCache, was  
> implemented a while back in the geronimo-sandbox and documented  
> here http://cwiki.apache.org/GMOxDEV/geronimo-clustering-with- 
> gcache.html. However, as this caching solution has not been touched  
> for a while, I do not think it is in a working state.
>
> The approach you are taking seems to me reasonable and I think it  
> would be quite useful for other users to have such GBean services  
> for JCS or EHCache.
>
> FYI, I am currently working on the implementation of a  
> hierarchical, transactional, distributed, partitioned and  
> replicated cache and data-grid solution as part of WADI. I hope to  
> have a working solution at the end of the month and hopefully  
> before you having the need for it :)
>
> Thanks,
> Gianny
>
>
> On 01/05/2008, at 2:22 AM, Xasima Xirohata wrote:
>
> Hi. I want to figure out what is the proper strategy to plug-in  
> POJO cache into geronimo (2.1).
> I want to use the different implementation of caching (HashMap,  
> EHCACHE, JCS) and work in standalone mode  (not explicit clustering  
> support for the first time).
>
> In the existed code we just want to get a cache instance using  
> JNDI, cast this to java.util.Map and  invoke plain put/get methods.
> I have explored geronimo docs and found the following possibilities:
>    1) use the terracotta (http://www.terracotta.org/confluence/ 
> display/orgsite/Distributed+Caches) that exposes such an wrapper  
> around different implementation.
>    2) use the wadi and the http://incubator.apache.org/wadi/wadi- 
> core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html class  
> somehow
>    3) use the custom gbean as wrapper upon different implementation  
> of caching (as the general solution for any separate custom services).
>
> Unfortunately, the 70Mb size of Terracotta seems too heavy to use  
> for such a use case when I don't plan to work with clustering at once.
> I don't found a page to integrate this options with WADI, please  
> provide some details on this..
> So I have stopped with the last way. I think that having POJO cache  
> exposed as gbean (instead of using as regular embedded jar) is a  
> right strategy since it is quite naturally to
>    1) implement initializing, clearing, storing (if persistence is  
> on) of POJO cache when the correspondent geronimo lifecycle events  
> occur
>    2) providing different <attribute > </attribute> in the gbean  
> plan to configure in external manner different  POJO cache parameters
>    3) having MBean that reports on state and loads of the cache  
> ( it may be interesting how  much objects are consumes from this  
> and if we need to change expiration policy or allocate more size)
>
> Am I right with the approach? Do you have any predefined gbeans (or  
> prototype in sandbox code area) code for this?
> Could I use WADI for this purpose?
> --
> Best regards,
> ~ Xasima Xirohata ~
>
>
>
>
> --
> Best regards,
> ~ Xasima Xirohata ~