I need to investigate what may go wrong with calling NodeSPI#getData()
though since it may cause a ping-pong effect between 2 servers both
using a CCL.
Anyway I'll spend some time on this tomorrow, it will be in place in
time for 3.1.0.GA.
On 27 Apr 2009, at 08:15, Yong Yuan wrote:
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
_______________________________________________
jbosscache-users mailing list
jbosscache-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-users