I don't use the jsp program from a Servlet, but I use the JCSAdminBean
from the command line and it does work...It's probably simpler to try
this from a standalone program first.
/** Remove an item from the cache.
* @param regionName Name of the cache region
* @param key for this cache.
*/
public void removeItem(String regionName, String key)
throws IOException, RemoteException {
JCSAdminBean bean = new JCSAdminBean();
bean.removeItem(regionName, key);
}
On 27/09/2007, Niall Gallagher <[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
> I believe RemoteCacheFactory is a class inside JCS. We don't have any
> direct interaction with this class, but we have set up a remote cache
> server - so that class is probably used by the remote server.
>
> Our remote cache server is configured with very simple parameters:
>
> # "cache.ccf" for the remote server
> jcs.default=
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> registry.port=1102
> remote.cache.service.port=1103
>
> We don't have anything else configured on the remote cache server,
> because we have found that the remote server is able to configure itself
> on-the-fly with regions specified on client machines.
>
> Our client machines configure the regions they use with
> RemoveUponRemotePut=true. If two client machines both retrieve the same
> object from the cache, and client A puts a modified version of it into
> the cache with the same key, it gets sent to the remote cache server and
> the remote cache server sends a remove command to client B which removes
> client B's local copy of the old version of the object. Subsequently if
> client B tries to retrieve the object again, it will retrieve the new
> copy from the remote server. The problem is if we use JCSAdmin.jsp on
> the remote server to remove an object from the remote cache directly,
> clients (e.g. client A and client B above) are not told about it, and
> continue to use their old locally-cached copies of the object.
>
> It seems that JCSAdmin.jsp does not broadcast remove commands to client
> machines. Is anybody using JCSAdmin.jsp to administer the cache
> centrally like this?
>
> Regards,
> Niall
>
> On Thu, 2007-09-27 at 09:16 +0100, Horton Simon wrote:
>
> > Hi Niall,
> >
> > If you are using an auxiliary RemoteCacheFactory make sure you set
> > RemoveUponRemotePut=true otherwise the data in a different cache will
> > only get the latest changes after it expires from its local cache and is
> > forced to check the remote cache. When RemoveUponRemotePut=true, as soon
> > as it changes, all the local caches will have their objects removed for
> > the given key.
> >
> > e.g. for my RemoteCacheFactory called RFailover:
> >
> > jcs.auxiliary.RFailover.attributes.RemoveUponRemotePut=true
> >
> > Regards,
> > Simon
> >
> > -----Original Message-----
> > From: Niall Gallagher [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, September 26, 2007 7:39 PM
> > To: JCS Users List
> > Subject: JCSAdmin.jsp doesn't broadcast removes?
> >
> > Hi,
> >
> > Not sure if this has been asked before..
> >
> > We have found that the JCSAdmin.jsp running on our central cache server,
> > does not seem to broadcast removes to client machines when we clear
> > regions via this JSP on the central server. Is this expected behaviour
> > or a bug?
> >
> > We have gotten around the problem by writing our own custom JSPs based
> > on the JCSAdmin.jsp and JCSAdmin bean, and deploying them in the same
> > webapp as the JCSAdmin.jsp and jcs jar file (let's call this the "jcs
> > webapp"). Our custom JSPs don't actually clear regions themselves, they
> > POST the requests to another webapp we have written.
> >
> > The other webapp we have written (let's call it "jcs assistant")
> > contains just a simple servlet which listens for HTTP POSTs asking it to
> > clear certain regions or elements. This servlet clears the requested
> > region using the normal JCS API as if it was a normal client machine
> > (note that we only use string keys, so we can send them in the POST).
> >
> > Both webapps are deployed to JBoss 4.2.1GA. We found that we had to
> > configure Isolated -> true in the ear-deployer.xml file, to force JBoss
> > to load a separate copy of JCS for both webapps.
> >
> > Basically- we've found that when a client puts an object in the cache it
> > gets sent to the central server and shows up on both our JSPs and the
> > JCSAdmin.jsp.
> > If we remove the object from the cache via JCSAdmin.jsp, it disappears
> > from both sets of JSPs, but if the client then tries to retrieve the
> > same object from the cache again it unexpectedly *succeeds* (this is
> > without the client shutting down between runs).
> > If we remove the object from the cache via our "JCS assistant" webapp,
> > it disappears from both sets of JSPs, and if the client then tries to
> > retrieve the same object from the cache again it gets null as expected.
> >
> > Has anyone seen this behaviour before? Is there anything we can do to
> > fix it? Obviously having to hack JSPs and deploy two webapps isn't a
> > very good solution to this problem.
> >
> > Thanks in advance,
> >
> > Niall
> >
> >
> > This message and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they are
> > addressed. If you have received this message in error please delete it and
> > any files transmitted with it, after notifying [EMAIL PROTECTED]
> > Any opinions expressed in this message may be those of the author and not
> > necessarily those of the company. The company accepts no responsibility for
> > the accuracy or completeness of any information contained herein. This
> > message is not intended to create legal relations between the company and
> > the recipient.
> > Recipients should please note that messages sent via the Internet may be
> > intercepted and that caution should therefore be exercised before
> > dispatching to the company any confidential or sensitive information.
> > Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA.
> > TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd.
> > Member of Mizuho Financial Group. Authorised and regulated by the Financial
> > Services Authority. Member of the London Stock Exchange.
> >
> > Registered in England No. 1203696. Registered office as above.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ____________________________________
> Niall Gallagher
>
> Technical Architect
> Switchfire Ltd.
> phone:
> + 44 (0)20 7798 2807
> fax:
> + 44 (0)20 7798 2801
> email:
> [EMAIL PROTECTED]
> web:
> www.switchfire.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
