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
<[EMAIL PROTECTED]> 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 ~
