After a little more digging, I noticed that the command ClusteredCacheLoader
was not chained because it issued the command GetCacheDataMap to get data
from remote server, while GetCacheDataMap gets data only from memory by
calling NodeSPI#getDataDirect(). Is this correct observation? If if it is,
could anyone please let me know why ClusteredCacheLoader is designed like
that? If I replace NodeSPI#getDataDirect() with NodeSPI#getData() so
CacheLoaderInterceptor will be used, would I run into any issue? By the way,
ClusteredCacheLoader implements its exits(Fqn fqn) method by issuing a
remote ExistsCommand. May I know why it should know whether a remote server
has data or not? I thought if GetDataMapCommand would suffice because
ClusteredCacheLoader would know a remoter server does not have the request
data if GetDatamapCommand returns null.
Thanks,
Yong
On Fri, Apr 24, 2009 at 7:21 PM, Yong Yuan <yycslab(a)gmail.com> wrote:
Hi,
I have two servers, server A and server B, each running a JBoss cache
instance. Server A uses server B as a far cache. The cache instance on
server B also uses a database as a persistent cache store. Server A has
ClusteredCacheLoader as its only loader, and server B has
ClusteredCacheLoader as its first loader and JDBCCacheLoader as its second
loader. My question is, Can server A get a cached state that is *only* in
the persistent cache store? Below is the flow I imagined:
get cached state
calls ClusteredCacheLoader calls
JDBCCacheLoader
Server A ----------------------------> cache instance on server A
----------------------------------------> cache instance on server B
------------------------------------> persistent cache store
I'm asking this question because I noticed when a cache state was only in
persistent cache store, server A would not be able to get that state. I
turned on the traces on both servers. The log on server A showed
ClusteredCacheLoader did make a remote call with ClusteredGetCommand and
correct fqn being sent to server B. The log on server B showed that server B
did receive the remote call from server A. Server B then executed
ClusteredGetCommand, which in turn executed ExistsCommand first and then
GetDataMapCommand. Since the requested cache was not in the memory, both
commands returned false or null. Unfortunately, the chain execution ended
here. No JDBC call was issued after GetDataMapCommand returned [false, null]
to server A. As a result, server A always got null instead of the state in
the persistent store.
Can I update my configuration files to enable command chaining or something
familiar? That is, when ClusteredGetCommand in server B doesn't get anything
from memory, JDBCCacheLoader will be executed to get the data from database.
Or some customization is needed here? By the way, CommandAwareRpcDispatcher
said ClusteredGetCommand ".. is a non-visitable command - so performing
directly and not via the invoker.", so somehow interceptor chaining was
bypassed.
Any suggestion is greatly appreciated.
Thanks,
Yong