Author: asmuts
Date: Fri Dec 4 15:30:24 2009
New Revision: 887227
URL: http://svn.apache.org/viewvc?rev=887227&view=rev
Log:
Fixing JCS-69 - https://issues.apache.org/jira/browse/JCS-69
Modified:
jakarta/jcs/trunk/src/java/org/apache/jcs/utils/access/JCSWorker.java
Modified: jakarta/jcs/trunk/src/java/org/apache/jcs/utils/access/JCSWorker.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/utils/access/JCSWorker.java?rev=887227&r1=887226&r2=887227&view=diff
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/utils/access/JCSWorker.java (original)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/utils/access/JCSWorker.java Fri Dec 4 15:30:24
2009
@@ -287,11 +287,11 @@
{
map.remove( getRegion() + aKey );
}
- synchronized ( this )
+ synchronized ( aHelper )
{
aHelper.setFinished( true );
// Wake everyone waiting on us
- notifyAll();
+ aHelper.notifyAll();
}
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Is there any chance we could get this code into the trunk?
We're running off our own build now, and it would be nice to keep in sync
with any changes going forward.
We've implemented this code change and the fix is working great.
Thanks,
Scott
https://issues.apache.org/jira/browse/JCS-69
When using the JCSWorker threads lock indefinitely.
I believe the synchronized block in the finally block is synchronizing on
and notifying the wrong object.
Once a thread locks it never unlocks.
Class: org.apache.jcs.utils.access.JCSWorker
Method: private Object run( Serializable aKey, String aGroup,
JCSWorkerHelper aHelper ) throws Exception
Bad Code (in finally block):
synchronized ( this )
{
aHelper.setFinished( true );
// Wake everyone waiting on us
notifyAll();
}
Suggested Fix:
synchronized ( aHelper )
{
aHelper.setFinished( true );
// Wake everyone waiting on aHelper
aHelper.notifyAll();
}
jcs-1.3.3.5-RC.jar compiled with JDK 1.4 and when we use the same in JDK 1.5.x environment
the Garbage collection doesnt look good
----------------------------------------------------------------------------------------------------------------------------------
Key: JCS-70
URL: https://issues.apache.org/jira/browse/JCS-70
Project: JCS
Issue Type: Bug
Affects Versions: jcs-1.3
Environment: Solaris 10, SUN web server 6.x
Reporter: Parthiban
Assignee: Aaron Smuts
Fix For: jcs-1.3
Currently we are using JCS 1.2.x older version of the JCS and trying to upgrade the version
but the latest version "jcs-1.3.3.5-RC" is compiled with JDK 1.4 and seems to be because of
the JDK 1.4 compilation the garbage collection doesnt look good so please help me to get the
"jcs-1.3.3.5-RC" version compiled with JDK 1.5.x.
The JCS jar downloaded path:
http://svn.apache.org/repos/asf/jakarta/jcs/tempbuilds/
jcs-1.3.3.5-RC.jar
================
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: Apache Maven
Built-By: SG0894751
Package: org.apache.jcs
Build-Jdk: 1.4.2_18
Extension-Name: jcs
Specification-Title: Cache
Specification-Vendor: Apache Software Foundation
Implementation-Title: org.apache.jcs
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 1.3.3.5-RC
X-Compile-Source-JDK: 1.4
X-Compile-Target-JDK: 1.4
this version "jcs-1.3.3.2-RC.jar" was compiled with the right JDK 1.5
================
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: Apache Maven
Built-By: SG0894751
Package: org.apache.jcs
Build-Jdk: 1.5.0_15
Extension-Name: jcs
Specification-Title: Cache
Specification-Vendor: Apache Software Foundation
Implementation-Title: org.apache.jcs
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 1.3.3.2-RC
X-Compile-Source-JDK: 1.4
X-Compile-Target-JDK: 1.4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
The existing development mailing lists for Jakarta subprojects (BCEL, BSF, Cactus, ECS, JCS, JMeter, ORO, Regexp and retired subproject Slide) are merging. Two new lists will be soon be created, one for development discussions and another for notifications (such as SVN, Bugzilla, JIRA, Gump). Subscribers to any of the existing development lists mentioned above (also see CC header of this message) will be subscribed to the two new lists automatically. The existing lists that appear in the CC header of this message will subsequently be closed, with appropriate forwards in place to point to the merged list. The shared development discussions mailing list will use the convention of identifying the subproject associated with the posting in the email subject using square brackets. For example, a recent email sent to the jmeter-dev list had the subject: Exposing run info with JMX Once the shared mailing list is set up, the convention would be to use the following email subject instead: [JMeter] Exposing run info with JMX As a reminder, unsubscribing from a mailing list called list@jakarta.apache.org can be done by sending an email to list-unsubscribe@jakarta.apache.org (replace "list" with actual name of the mailing list to unsubscribe from). -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Hi, Pardon my ignorance. I am not very familiar caching mechanisms. Please go through the following scenario and help me *Scenario: * * * There are two servers A and B (say). A has to fetch the data from database and put it in its cache. This cache has to be replicated to server B. In case of failure, B should take the responsibility of fetching the data from database and putting in cache. When "A" comes up then again "A" should be the master server and it should fetch the data from DB and put it in cache and replicate the cache to B. One more thing is, we are planning to expose the data in the cache as a webservice. When the client access the webservice, then it should get the cached data in the form of XML. Please tell me how to implement the above scenario using *JCS* cache and provide any useful url's that I can go through. Even if you have any POC's please share. What I want to know in particular is " how to replicate cache over cluster using JCS?" and " What has to be done in case of master server failure?" Thanks and Regards, Sri Kanth
>It simply replaces all strange characters and spaces with underscores.
Why spaces if the os supports it or even strange chars if the os
supports non ascii encodings?
You can end up causing collisions with that type of replace.
-----Original Message-----
From: Aaron Smuts (JIRA) [mailto:jira@apache.org]
Sent: Monday, October 26, 2009 3:53 PM
To: jcs-dev@jakarta.apache.org
Subject: [jira] Commented: (JCS-58) disc file cache
[
https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plu
gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770189#act
ion_12770189 ]
Aaron Smuts commented on JCS-58:
--------------------------------
Please send questions like this to the mailing list.
Read the documentation. This disk cache is like any other. You
configure JCS to use it in the cache.ccf file just like any other disk
cache.
If you want to create files outside of JCS, we'll have to expose a
utility for creating the names. The algorithm is simply though. It
simply replaces all strange characters and spaces with underscores.
Please post to the user mailing list.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java,
DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is
stored as a single file and the filename is based on the key. This way,
several jvms can share the same cache and the cache can be rsynced
between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770189#action_12770189
]
Aaron Smuts commented on JCS-58:
--------------------------------
Please send questions like this to the mailing list.
Read the documentation. This disk cache is like any other. You configure JCS to use it in
the cache.ccf file just like any other disk cache.
If you want to create files outside of JCS, we'll have to expose a utility for creating the
names. The algorithm is simply though. It simply replaces all strange characters and spaces
with underscores.
Please post to the user mailing list.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770179#action_12770179
]
Chopin Hu commented on JCS-58:
------------------------------
Aaron,
I am still not getting it right. Seems that I put an ascii file into the file disk as a separate
file. But when it is an binary file. It does not work. Though I set the jvm to a bigger size
(1560MBs) to handle a 12 MBs binary file, it still fails. Do you have an sample code to show
how to make it work? If you need, I can send you a copy of the binary file I used for testing.
Thanks.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770178#action_12770178
]
Chopin Hu commented on JCS-58:
------------------------------
Aaron,
I am still not getting it right. Seems that I put an ascii file into the file disk as a
separate file. But when it is an binary file. It does not work. Though I set the jvm
to a bigger size (1560MBs) to handle a 12 MBs binary file, it still fails. Do you have an
sample code to show how to make it work? If you need, I can send you a copy of the binary
file I used for testing.
Thanks.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769968#action_12769968
]
Chopin Hu commented on JCS-58:
------------------------------
Figured out how to use it. Thanks.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[Relaying result to all lists] The vote to merge dev lists at Jakarta has passed with the following binding votes cast: 5 +1s: Felipe Leme Daniel Savarese Vadim Gritsenko Rahul Akolkar Stephen Colebourne 2 +0s: Sebastian Bazley Rony Flatscher 2 -1s: Thomas Vandahl Torsten Curdt I also count 4 non-binding +1s (Mark Murphy, Venkat Krishnamurthy, Henri Yandell, Jörg Schaible) and 3 non-binding -1s (Hanson Char, Giuseppe, Tim Cronin). Two non-binding +1s were cast by folks who until recently were on the PMC (bayard, joehni) so perhaps not giving their votes enough credit is getting too technical here. We'll encourage simple conventions (as Commons was mentioned, for example) to make filtering email, searching archives etc. as convenient as we can on a shared list. Hope is that will alleviate to some extent the primary concern of those who've voted against. I will open an INFRA ticket for this merge in a week or so (after I post another heads up note with more details, dev mailing list conventions etc. to the lists). Thanks to everyone who voted. -Rahul On Mon, Oct 19, 2009 at 4:02 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote: > [Suggestion is to please reply to the general@jakarta list only] > > This is a vote to consolidate the development lists at Jakarta into > one development and one notifications list. For background including > timing, anticipated benefits and some discussion, see proposal [1] > thread. > > [ ] +1 > [ ] -1 > > While not required, it'd be nice if anyone voting against could > briefly state the reason(s). And you're ofcourse welcome to vote +/-0 > if you really want. > > Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. > > TIA. > -Rahul > > [1] (long, possibly fragmented URL below) > http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769351#action_12769351
]
Chopin Hu commented on JCS-58:
------------------------------
Aaron,
Great. I just got a chance to check out the release-1.3.3.5-RC, which looks the Disk File
Cache
Now, my question is how to cache a file to the disk using a key as the file name. Is this
a config issue? If not, can you please provide a sample code showing how to use it?
Thank you so much.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
-1 The reasons Rahul explained are certainly valid for developers subscribed to more than one dev list. In my case, being subscribed to only JMeter dev list, I don't see advantages in having all prjs in the same list; on the contrary, I'll get more "useless" messages. But of course this is only my opinion. Whatever decision will be taken, I'll be part of the dev list. Giuseppe Rahul Akolkar wrote: > [Suggestion is to please reply to the general@jakarta list only] > > This is a vote to consolidate the development lists at Jakarta into > one development and one notifications list. For background including > timing, anticipated benefits and some discussion, see proposal [1] > thread. > > [ ] +1 > [ ] -1 > > While not required, it'd be nice if anyone voting against could > briefly state the reason(s). And you're ofcourse welcome to vote +/-0 > if you really want. > > Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. > > TIA. > -Rahul > > [1] (long, possibly fragmented URL below) > http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org > > . > > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
-1 Too much noise to signal ratio - not everyone is interested in every Jakarta projects. Notification list consolidation seems fine, but probably not dev. On Mon, Oct 19, 2009 at 1:02 PM, Rahul Akolkar <rahul.akolkar@gmail.com>wrote: > [Suggestion is to please reply to the general@jakarta list only] > > This is a vote to consolidate the development lists at Jakarta into > one development and one notifications list. For background including > timing, anticipated benefits and some discussion, see proposal [1] > thread. > > [ ] +1 > [ ] -1 > > While not required, it'd be nice if anyone voting against could > briefly state the reason(s). And you're ofcourse welcome to vote +/-0 > if you really want. > > Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm > EST. > > TIA. > -Rahul > > [1] (long, possibly fragmented URL below) > > http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: jcs-dev-help@jakarta.apache.org > >
[Suggestion is to please reply to the general@jakarta list only] This is a vote to consolidate the development lists at Jakarta into one development and one notifications list. For background including timing, anticipated benefits and some discussion, see proposal [1] thread. [ ] +1 [ ] -1 While not required, it'd be nice if anyone voting against could briefly state the reason(s). And you're ofcourse welcome to vote +/-0 if you really want. Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. TIA. -Rahul [1] (long, possibly fragmented URL below) http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Archer updated JCS-69:
----------------------------
Attachment: cache.ccf
JCSTest.java
This class reproduces the problem.
> Synchronization Problem in JCSWorker
> ------------------------------------
>
> Key: JCS-69
> URL: https://issues.apache.org/jira/browse/JCS-69
> Project: JCS
> Issue Type: Bug
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: Linux 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009
x86_64 GNU/Linux
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Reporter: Scott Archer
> Assignee: Aaron Smuts
> Attachments: cache.ccf, JCSTest.java
>
>
> When using the JCSWorker threads lock indefinitely.
> I believe the synchronized block in the finally block is synchronizing on and notifying
the wrong object.
> Once a thread locks it never unlocks.
> Class: org.apache.jcs.utils.access.JCSWorker
> Method: private Object run( Serializable aKey, String aGroup, JCSWorkerHelper aHelper
) throws Exception
> Bad Code (in finally block):
> synchronized ( this )
> {
> aHelper.setFinished( true );
> // Wake everyone waiting on us
> notifyAll();
> }
> Suggested Fix:
> synchronized ( aHelper )
> {
> aHelper.setFinished( true );
> // Wake everyone waiting on aHelper
> aHelper.notifyAll();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Archer updated JCS-69:
----------------------------
Description:
When using the JCSWorker threads lock indefinitely.
I believe the synchronized block in the finally block is synchronizing on and notifying the
wrong object.
Once a thread locks it never unlocks.
Class: org.apache.jcs.utils.access.JCSWorker
Method: private Object run( Serializable aKey, String aGroup, JCSWorkerHelper aHelper ) throws
Exception
Bad Code (in finally block):
synchronized ( this )
{
aHelper.setFinished( true );
// Wake everyone waiting on us
notifyAll();
}
Suggested Fix:
synchronized ( aHelper )
{
aHelper.setFinished( true );
// Wake everyone waiting on aHelper
aHelper.notifyAll();
}
was:
When using the JCSWorker threads lock indefinitely.
I believe the synchronized block in the finally block is synchronizing on the wrong object.
Once a thread locks it never unlocks.
Class: org.apache.jcs.utils.access.JCSWorker
Method: private Object run( Serializable aKey, String aGroup, JCSWorkerHelper aHelper ) throws
Exception
Bad Code (in finally block):
synchronized ( this )
{
aHelper.setFinished( true );
// Wake everyone waiting on us
notifyAll();
}
Suggested Fix:
synchronized ( aHelper )
{
aHelper.setFinished( true );
// Wake everyone waiting on aHelper
aHelper.notifyAll();
}
> Synchronization Problem in JCSWorker
> ------------------------------------
>
> Key: JCS-69
> URL: https://issues.apache.org/jira/browse/JCS-69
> Project: JCS
> Issue Type: Bug
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: Linux 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009
x86_64 GNU/Linux
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Reporter: Scott Archer
> Assignee: Aaron Smuts
>
> When using the JCSWorker threads lock indefinitely.
> I believe the synchronized block in the finally block is synchronizing on and notifying
the wrong object.
> Once a thread locks it never unlocks.
> Class: org.apache.jcs.utils.access.JCSWorker
> Method: private Object run( Serializable aKey, String aGroup, JCSWorkerHelper aHelper
) throws Exception
> Bad Code (in finally block):
> synchronized ( this )
> {
> aHelper.setFinished( true );
> // Wake everyone waiting on us
> notifyAll();
> }
> Suggested Fix:
> synchronized ( aHelper )
> {
> aHelper.setFinished( true );
> // Wake everyone waiting on aHelper
> aHelper.notifyAll();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Synchronization Problem in JCSWorker
------------------------------------
Key: JCS-69
URL: https://issues.apache.org/jira/browse/JCS-69
Project: JCS
Issue Type: Bug
Affects Versions: jcs-1.3, jcs-1.4-dev
Environment: Linux 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64
GNU/Linux
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Reporter: Scott Archer
Assignee: Aaron Smuts
When using the JCSWorker threads lock indefinitely.
I believe the synchronized block in the finally block is synchronizing on the wrong object.
Once a thread locks it never unlocks.
Class: org.apache.jcs.utils.access.JCSWorker
Method: private Object run( Serializable aKey, String aGroup, JCSWorkerHelper aHelper ) throws
Exception
Bad Code (in finally block):
synchronized ( this )
{
aHelper.setFinished( true );
// Wake everyone waiting on us
notifyAll();
}
Suggested Fix:
synchronized ( aHelper )
{
aHelper.setFinished( true );
// Wake everyone waiting on aHelper
aHelper.notifyAll();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765724#action_12765724
]
Aaron Smuts commented on JCS-58:
--------------------------------
Use the latest temp build. It's production ready. I'm using it in prod. You don't need
a formal release build. 1.3 is way out of date. We'll issue a new release in a couple of
months, but there is no need to wait.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[Out of necessity, this is heavily cross-posted. Suggestion is to send any replies to the general@jakarta list only to keep any discussion in one place.] We currently have 8 active development lists at Jakarta, each devoted to a subproject. I've been subscribed to all for a while and based on my observations and the overall benefits of doing so, I think its time to consolidate them into a single development list at Jakarta. Motivations (not in any order): * Flattens and simplifies oversight - Not much else to be said on that. * Communication - Subprojects can often have various touch points. So, Rony's surprise today at the BSF taglib being retired is one example. Lets have all dev discussions on one list. * Cross-pollination - Most subprojects are at the point where it certainly wouldn't hurt to have the active folks from all of Jakarta around for dev discussions, votes etc. * Manageable overhead - More on this later, but we have a number of usual suspects showing up on many of the dev lists, they'd barely notice a difference. Others can manage, IMO/hopefully. Operationally: * The combined list traffic will obviously be more than any one of the separate lists. However, development tends to be in spurts on these lists and the probabilistic chances of more than a couple of subproject spurts happening at the same time seems quite low. Overall, combined traffic is not at all overpowering IMO. * The proposal will include closing current dev lists and adding all subscribers to the one new dev list. We'll post a heads up on these lists before that. Throw in site-cvs@ as well for good measure. * We could repurpose general@ as the one dev list, but OTOH, seems worthwhile to maintain the dev / general separation. * No changes proposed to the user lists. Thoughts? Lets say a little over a week (10 days, which should give us two weekends) for initial feedback and opinions please. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764043#action_12764043
]
Chopin Hu commented on JCS-58:
------------------------------
That is exactly what I am looking for. But is the release 1.4 available yet? I don't care
to use JDK 1.5+. that's not an issue to me and to my project.
Currently, I am evaluating JCS 1.3. If I can put this feature (one key, and use the key
as a filename for cache) into function with the version 1.3, it is great. If not, then where
to find the version JCS 1.4?
By the way, the files I am going to cache are binary data. I hope it will work out.
Thanks a lot.
> disc file cache
> ---------------
>
> Key: JCS-58
> URL: https://issues.apache.org/jira/browse/JCS-58
> Project: JCS
> Issue Type: New Feature
> Affects Versions: jcs-1.3
> Reporter: Tore Halset
> Assignee: Aaron Smuts
> Fix For: jcs-1.4-dev
>
> Attachments: DiskFileCache.java, DiskFileCacheAttributes.java, DiskFileCacheFactory.java
>
>
> It would be nice to have a file based cache in jcs where each item is stored as a single
file and the filename is based on the key. This way, several jvms can share the same cache
and the cache can be rsynced between nodes while running the application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Sinha updated JCS-48:
----------------------------
Attachment: JCSDataSourceHelper.java
JDBCDiskCache.java
I have added one class JCSDataSourceHelper and modified the existing class JDBCDiskCache.
I have tried to keep it as low risk, and jcs code will behave as it used to do if we revert
back to old configuration in cache.ccf.
For the datasource to work, the only change required in cache.ccf is:
jcs.auxiliary.JDBC.attributes.url=jdbc/jcsDataSource
that is, specify datasource jndi instead of DB url
But I do have the dependency in the code that datasource jndi name should start with "jdbc/"
just to identify thats its datasource jndi name and not the DB url.
Regards
Vishal Sinha
> JDBC Disk Auxiliary Cache Configuration -> support JNDI datasource in Appservers
> --------------------------------------------------------------------------------
>
> Key: JCS-48
> URL: https://issues.apache.org/jira/browse/JCS-48
> Project: JCS
> Issue Type: Improvement
> Components: JDBC Disk Cache
> Affects Versions: jcs-1.4-dev
> Reporter: hanasaki jiji
> Assignee: Aaron Smuts
> Priority: Minor
> Attachments: JCSDataSourceHelper.java, JDBCDiskCache.java
>
>
> JDBC Disk Auxiliary Cache Configuration -> support JNDI datasource in Appservers
> http://jakarta.apache.org/jcs/JDBCDiskCacheProperties.html
> Allow property "url" to be used (or add URI) so that tomcat and other appservers providing
JNDI datasources can be used to specific the table and id/pass and connection information.
In this case several other properties would be ignored: tableName, userName, password.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Hi Aaron, Good to know, thanks for the info. Never mind- since this is the designed behaviour (which works in normal network environments) then this isn't really a problem with JCS, the root problem is our insane network architecture. I was just hoping there might be some trivial tweak we could make in JCS to work around our network issue. Anyway we will be migrating to a new data centre soon, and in the meantime we'll be careful. Thanks, Niall -----Original Message----- From: Aaron Smuts <asmuts@yahoo.com> Reply-to: "JCS Developers List" <jcs-dev@jakarta.apache.org> To: JCS Developers List <jcs-dev@jakarta.apache.org> Subject: Re: JCS remote cache client shutdown behaviour Date: Wed, 9 Sep 2009 07:30:15 -0700 (PDT) I don't think that shutdown will properly kill the event queues on the server side. The server will queue and retry 10 times before killing the queue and marking it non functional. If you have a large number of items and lots of clients that keep going down, then you could see a memory spike. We should look into the client shutdown process. Aaron --- On Mon, 9/7/09, Niall Gallagher <niall@switchfire.com> wrote: > From: Niall Gallagher <niall@switchfire.com> > Subject: JCS remote cache client shutdown behaviour > To: "JCS Developers List" <jcs-dev@jakarta.apache.org> > Date: Monday, September 7, 2009, 7:50 AM > Hi, > > I'm wondering if anyone can explain the sequence of steps > the JCS client > code is supposed to follow when > CompositeCacheManager.shutDown() is > called client-side? We are intermittently seeing high > memory usage in > our JCS remote server, which appears to be caused by large > backlogs of > event objects queued for delivery to client machines which > have been > shut down, even though we are shutting down our client > machines > gracefully using the method above. This is certainly > aggravated by our > network's architecture, but I'm not sure if the root cause > might be a > bug in JCS or I'm not understanding what should happen > properly. > > When we call CompositeCacheManager.shutDown() on a client > machine, from > our client-side logs it appears that the dispose() method > in this object > is getting called correctly for each cache region: > http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/RemoteCacheListener.java?view=markup > > However that method appears to just unexport the RMI > RemoteCacheListener > object for each region client-side; basically terminating > the > client-side end of the event delivery connection. Before > disconnecting > though, shouldn't this method notify the server that the > client is about > to disconnect? > > Subsequently we often see errors like this in the remote > server log: > > > 07-Sep 13:52:13,347 INFO [jcs.engine.CacheEventQueue] > Error while running event from Queue: RemoveEvent for [GAN: > groupId=[groupId=<region name>, defaultGroup], > attrName=<cache key>]. Retrying... > 07-Sep 13:52:13,747 WARN [jcs.engine.CacheEventQueue] > java.rmi.ConnectException: Connection refused to host: > <client machine ip address>; nested exception is: > java.net.ConnectException: > Connection refused > 07-Sep 13:52:13,748 WARN [jcs.engine.CacheEventQueue] > Error while running event from Queue: RemoveEvent for [GAN: > groupId=[groupId=<region name>, defaultGroup], > attrName=<cache key>]. Dropping Event and marking > Event Queue as non-functional. > > > ...this implies the remote server continues to try to > deliver events to > the JCS client which disconnected, as if the client didn't > de-register > itself before disconnecting. > > Perhaps I've missed something in the code. > > I see that the RemoteCacheServer API (to which clients > connect) does in > fact have a server-side dispose() method which (on initial > investigation) would "de-register" the client from the > server's list of > event listeners. Could it be that JCS clients are simply > not calling > this method?.. > http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/server/RemoteCacheServer.java?view=markup > > > This issue is a problem for us depending on which network > subnet the > client machine is in. Basically our network is divided into > 2 subnets, > with a fairly rubbish (or overly-strict) router/firewall > between the two > subnets. This router does not relay networking errors (ICMP > error > messages) between the two subnets. When a machine in one > subnet goes > offline and a machine in the other subnet tries to connect > to it, our > router does not notify the source machine that the target > machine is > offline, and so the source machine waits indefinitely (i.e. > with a > socket in the open wait state) for a response from the > target machine. > On the other hand when both machines are in the same > subnet, the source > machine gets a "host not reachable" exception immediately > when a target > machine is offline. > > Anyway... the problem is when we shut down a client machine > in a > different subnet, the JCS remote server builds up a large > backlog of > cache event objects, presumably trying to connect to a > disconnected > client, and eventually runs out of memory. We determine > this using the > JDK's jmap command - we find a large number of PutEvent and > RemoveEvent > objects in the remote server's memory. We don't have the > issue when both > machines are in the same subnet, but I wonder if that's > because JCS > remote server is relying on the networking errors, and is > de-registering > clients automatically after a certain number of failed > attempts to > connect to the client. i.e. perhaps clients are not > de-registering > themselves gracefully from the remote server in the first > place. > > Does anyone have any experience with this- anyone regularly > see "Error > while running event from Queue" in the remote server logs? > I realise our > network setup is partly to blame here, but perhaps the root > cause is > that client's are not de-registering properly. > > Many thanks in advance, > > Niall > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Nope. There is a putSafe method, but it won't do what you want. Are you worried about redundant puts? --- On Tue, 9/8/09, Marvin-Chin-Pang.Leung@ubs.com <Marvin-Chin-Pang.Leung@ubs.com> wrote: > From: Marvin-Chin-Pang.Leung@ubs.com <Marvin-Chin-Pang.Leung@ubs.com> > Subject: Any operation in JCS cache similar to ConcurrentHashMap.putIfAbsent() ? > To: jcs-dev@jakarta.apache.org > Date: Tuesday, September 8, 2009, 8:30 PM > > > > > > Any operation in JCS cache similar to > ConcurrentHashMap.putIfAbsent() ? > > > > > Hi JCS Dev, > > > I am trying to use > JCS cache in concurrent environment. Wonder if there any > function in JCS cache similar to that of putIfAbsent() in > ConcurrentHashMap? > > Rdgs, > > > Marvin > > > > > -----Inline Attachment Follows----- > > Visit our website at http://www.ubs.com > > This message contains confidential information and is > intended only > for the individual named. If you are not the named > addressee you > should not disseminate, distribute or copy this > e-mail. Please > notify the sender immediately by e-mail if you have > received this > e-mail by mistake and delete this e-mail from your system. > > E-mails are not encrypted and cannot be guaranteed to be > secure or > error-free as information could be intercepted, corrupted, > lost, > destroyed, arrive late or incomplete, or contain > viruses. The sender > therefore does not accept liability for any errors or > omissions in the > contents of this message which arise as a result of e-mail > transmission. > If verification is required please request a hard-copy > version. This > message is provided for informational purposes and should > not be > construed as a solicitation or offer to buy or sell any > securities > or related financial instruments. > > > UBS reserves the right to retain all messages. Messages are > protected > and accessed only in legally justified cases. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: jcs-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
I don't think that shutdown will properly kill the event queues on the server side. The server will queue and retry 10 times before killing the queue and marking it non functional. If you have a large number of items and lots of clients that keep going down, then you could see a memory spike. We should look into the client shutdown process. Aaron --- On Mon, 9/7/09, Niall Gallagher <niall@switchfire.com> wrote: > From: Niall Gallagher <niall@switchfire.com> > Subject: JCS remote cache client shutdown behaviour > To: "JCS Developers List" <jcs-dev@jakarta.apache.org> > Date: Monday, September 7, 2009, 7:50 AM > Hi, > > I'm wondering if anyone can explain the sequence of steps > the JCS client > code is supposed to follow when > CompositeCacheManager.shutDown() is > called client-side? We are intermittently seeing high > memory usage in > our JCS remote server, which appears to be caused by large > backlogs of > event objects queued for delivery to client machines which > have been > shut down, even though we are shutting down our client > machines > gracefully using the method above. This is certainly > aggravated by our > network's architecture, but I'm not sure if the root cause > might be a > bug in JCS or I'm not understanding what should happen > properly. > > When we call CompositeCacheManager.shutDown() on a client > machine, from > our client-side logs it appears that the dispose() method > in this object > is getting called correctly for each cache region: > http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/RemoteCacheListener.java?view=markup > > However that method appears to just unexport the RMI > RemoteCacheListener > object for each region client-side; basically terminating > the > client-side end of the event delivery connection. Before > disconnecting > though, shouldn't this method notify the server that the > client is about > to disconnect? > > Subsequently we often see errors like this in the remote > server log: > > > 07-Sep 13:52:13,347 INFO [jcs.engine.CacheEventQueue] > Error while running event from Queue: RemoveEvent for [GAN: > groupId=[groupId=<region name>, defaultGroup], > attrName=<cache key>]. Retrying... > 07-Sep 13:52:13,747 WARN [jcs.engine.CacheEventQueue] > java.rmi.ConnectException: Connection refused to host: > <client machine ip address>; nested exception is: > java.net.ConnectException: > Connection refused > 07-Sep 13:52:13,748 WARN [jcs.engine.CacheEventQueue] > Error while running event from Queue: RemoveEvent for [GAN: > groupId=[groupId=<region name>, defaultGroup], > attrName=<cache key>]. Dropping Event and marking > Event Queue as non-functional. > > > ...this implies the remote server continues to try to > deliver events to > the JCS client which disconnected, as if the client didn't > de-register > itself before disconnecting. > > Perhaps I've missed something in the code. > > I see that the RemoteCacheServer API (to which clients > connect) does in > fact have a server-side dispose() method which (on initial > investigation) would "de-register" the client from the > server's list of > event listeners. Could it be that JCS clients are simply > not calling > this method?.. > http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/server/RemoteCacheServer.java?view=markup > > > This issue is a problem for us depending on which network > subnet the > client machine is in. Basically our network is divided into > 2 subnets, > with a fairly rubbish (or overly-strict) router/firewall > between the two > subnets. This router does not relay networking errors (ICMP > error > messages) between the two subnets. When a machine in one > subnet goes > offline and a machine in the other subnet tries to connect > to it, our > router does not notify the source machine that the target > machine is > offline, and so the source machine waits indefinitely (i.e. > with a > socket in the open wait state) for a response from the > target machine. > On the other hand when both machines are in the same > subnet, the source > machine gets a "host not reachable" exception immediately > when a target > machine is offline. > > Anyway... the problem is when we shut down a client machine > in a > different subnet, the JCS remote server builds up a large > backlog of > cache event objects, presumably trying to connect to a > disconnected > client, and eventually runs out of memory. We determine > this using the > JDK's jmap command - we find a large number of PutEvent and > RemoveEvent > objects in the remote server's memory. We don't have the > issue when both > machines are in the same subnet, but I wonder if that's > because JCS > remote server is relying on the networking errors, and is > de-registering > clients automatically after a certain number of failed > attempts to > connect to the client. i.e. perhaps clients are not > de-registering > themselves gracefully from the remote server in the first > place. > > Does anyone have any experience with this- anyone regularly > see "Error > while running event from Queue" in the remote server logs? > I realise our > network setup is partly to blame here, but perhaps the root > cause is > that client's are not de-registering properly. > > Many thanks in advance, > > Niall > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Hi JCS Dev, I am trying to use JCS cache in concurrent environment. Wonder if there any function in JCS cache similar to that of putIfAbsent() in ConcurrentHashMap? Rdgs, Marvin
Hi,
I'm wondering if anyone can explain the sequence of steps the JCS client
code is supposed to follow when CompositeCacheManager.shutDown() is
called client-side? We are intermittently seeing high memory usage in
our JCS remote server, which appears to be caused by large backlogs of
event objects queued for delivery to client machines which have been
shut down, even though we are shutting down our client machines
gracefully using the method above. This is certainly aggravated by our
network's architecture, but I'm not sure if the root cause might be a
bug in JCS or I'm not understanding what should happen properly.
When we call CompositeCacheManager.shutDown() on a client machine, from
our client-side logs it appears that the dispose() method in this object
is getting called correctly for each cache region:
http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/RemoteCacheListener.java?view=markup
However that method appears to just unexport the RMI RemoteCacheListener
object for each region client-side; basically terminating the
client-side end of the event delivery connection. Before disconnecting
though, shouldn't this method notify the server that the client is about
to disconnect?
Subsequently we often see errors like this in the remote server log:
07-Sep 13:52:13,347 INFO [jcs.engine.CacheEventQueue] Error while running event from Queue:
RemoveEvent for [GAN: groupId=[groupId=<region name>, defaultGroup], attrName=<cache
key>]. Retrying...
07-Sep 13:52:13,747 WARN [jcs.engine.CacheEventQueue] java.rmi.ConnectException: Connection
refused to host: <client machine ip address>; nested exception is:
java.net.ConnectException: Connection refused
07-Sep 13:52:13,748 WARN [jcs.engine.CacheEventQueue] Error while running event from Queue:
RemoveEvent for [GAN: groupId=[groupId=<region name>, defaultGroup], attrName=<cache
key>]. Dropping Event and marking Event Queue as non-functional.
...this implies the remote server continues to try to deliver events to
the JCS client which disconnected, as if the client didn't de-register
itself before disconnecting.
Perhaps I've missed something in the code.
I see that the RemoteCacheServer API (to which clients connect) does in
fact have a server-side dispose() method which (on initial
investigation) would "de-register" the client from the server's list of
event listeners. Could it be that JCS clients are simply not calling
this method?..
http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/server/RemoteCacheServer.java?view=markup
This issue is a problem for us depending on which network subnet the
client machine is in. Basically our network is divided into 2 subnets,
with a fairly rubbish (or overly-strict) router/firewall between the two
subnets. This router does not relay networking errors (ICMP error
messages) between the two subnets. When a machine in one subnet goes
offline and a machine in the other subnet tries to connect to it, our
router does not notify the source machine that the target machine is
offline, and so the source machine waits indefinitely (i.e. with a
socket in the open wait state) for a response from the target machine.
On the other hand when both machines are in the same subnet, the source
machine gets a "host not reachable" exception immediately when a target
machine is offline.
Anyway... the problem is when we shut down a client machine in a
different subnet, the JCS remote server builds up a large backlog of
cache event objects, presumably trying to connect to a disconnected
client, and eventually runs out of memory. We determine this using the
JDK's jmap command - we find a large number of PutEvent and RemoveEvent
objects in the remote server's memory. We don't have the issue when both
machines are in the same subnet, but I wonder if that's because JCS
remote server is relying on the networking errors, and is de-registering
clients automatically after a certain number of failed attempts to
connect to the client. i.e. perhaps clients are not de-registering
themselves gracefully from the remote server in the first place.
Does anyone have any experience with this- anyone regularly see "Error
while running event from Queue" in the remote server logs? I realise our
network setup is partly to blame here, but perhaps the root cause is
that client's are not de-registering properly.
Many thanks in advance,
Niall
[ https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750574#action_12750574
]
Aaron Smuts commented on JCS-68:
--------------------------------
Yes. We can restrict the constructor (if needed) and not the class.
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's
used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse the objects stored
in our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove an object, the
object is successfully removed from the JCS remote server, but the 'remove' event for that
object is not broadcast to all client machines. Client machines which start up after we remove
the object get 'null' when they try to retrieve the object (the desired behaviour). However
client machines which were already running and using this object continue to see the object
in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in
JCS to remove objects from the cache when it's running on the remote cache server. It calls
the CompositeCache API, which is intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
> The fix involves replacing 3 methods in org.apache.jcs.admin.JCSAdminBean as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears all regions via
the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears all
regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each cacheName...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> }
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from all
cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears the region via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes the item via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
> // actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
> // we iterate through all keys stored in the memory cache until we find
one whose toString matches
> // the string supplied...
> Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was already found...
> throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" + keyToRemove + ",
" + keyToRemove.getClass() + "] in cache matching key specified, however key found in cache
is unexpectedly not serializable.");
> }
> // At this point, we have retrieved the matching Serializable key.
> // Call remoteCacheServer.remove(String, Serializable)...
> // Note: We must fo this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility = removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName,
keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove element with key ["
+ key + ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749878#action_12749878
]
Niall Gallagher commented on JCS-68:
------------------------------------
We had to use reflection because the RemoteCacheServer class is package-private, the reflection
bypasses the access restriction. Re: Tim's question on the mailing list- I'm not sure but
this might also be why RemoteCacheServer is missing from the JavaDocs.
Can we make the RemoteCacheServer API public? This would allow us to call it without reflection.
In fact without reflection these patches would be fairly simple indeed.
Here's the relevant class in trunk..
http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/auxiliary/remote/server/RemoteCacheServer.java?revision=727172
It looks like the required 'removeXXX' methods are already public. It's just the class that's
not public. So we just need to add the keyword 'public' to the class declaration. Can we do
this?
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's
used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse the objects stored
in our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove an object, the
object is successfully removed from the JCS remote server, but the 'remove' event for that
object is not broadcast to all client machines. Client machines which start up after we remove
the object get 'null' when they try to retrieve the object (the desired behaviour). However
client machines which were already running and using this object continue to see the object
in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in
JCS to remove objects from the cache when it's running on the remote cache server. It calls
the CompositeCache API, which is intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
> The fix involves replacing 3 methods in org.apache.jcs.admin.JCSAdminBean as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears all regions via
the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears all
regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each cacheName...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> }
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from all
cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears the region via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes the item via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
> // actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
> // we iterate through all keys stored in the memory cache until we find
one whose toString matches
> // the string supplied...
> Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was already found...
> throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" + keyToRemove + ",
" + keyToRemove.getClass() + "] in cache matching key specified, however key found in cache
is unexpectedly not serializable.");
> }
> // At this point, we have retrieved the matching Serializable key.
> // Call remoteCacheServer.remove(String, Serializable)...
> // Note: We must fo this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility = removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName,
keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove element with key ["
+ key + ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
I have no idea. Strange.
But to make a patch, you have to checkout the code. . . .
--- On Mon, 8/31/09, Tim Cronin <Tim.Cronin@autonomy.com> wrote:
> From: Tim Cronin <Tim.Cronin@autonomy.com>
> Subject: RE: [jira] Commented: (JCS-68) Admin.jsp on remote cache server does not broadcast
removes - patch
> To: "JCS Developers List" <jcs-dev@jakarta.apache.org>
> Date: Monday, August 31, 2009, 8:22 AM
> Any reason that the RemoteCacheServer
> class is not exposed in the
> Javadocs?
>
> http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/auxiliary/remote/se
> rver/RemoteCacheServerFactory.html
>
>
> -----Original Message-----
> From: Aaron Smuts (JIRA) [mailto:jira@apache.org]
> Sent: Monday, August 31, 2009 8:29 AM
> To: jcs-dev@jakarta.apache.org
> Subject: [jira] Commented: (JCS-68) Admin.jsp on remote
> cache server
> does not broadcast removes - patch
>
>
> [
> https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plu
> gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749487#act
> ion_12749487 ]
>
> Aaron Smuts commented on JCS-68:
> --------------------------------
>
> Thanks, this is a good idea. Why are you calling the
> remove method via
> reflection? That's too fragile. Especially
> without any unit tests. I
> need unit tests for all changes.
>
> > Admin.jsp on remote cache server does not broadcast
> removes - patch
> >
> -------------------------------------------------------------------
> >
> >
> Key: JCS-68
> >
> URL: https://issues.apache.org/jira/browse/JCS-68
> >
> Project: JCS
> > Issue Type: Bug
> > Components: RMI
> Remote Cache
> > Affects Versions: jcs-1.3, jcs-1.4-dev
> > Environment:
> All
> > Reporter:
> Niall Gallagher
> > Assignee:
> Aaron Smuts
> > Priority:
> Minor
> > Original Estimate: 0.5h
> > Remaining Estimate: 0.5h
> >
> > We'd like to contribute some patches to fix an issue
> with the
> JCSAdmin.jsp when it's used on a JCS remote cache server.
> > We use this JSP on our remote cache server. This
> allows us to browse
> the objects stored in our distributed cache (i.e. uploaded
> by the client
> servers), and allows us to remove arbitrary objects from
> the distributed
> cache by clicking 'remove' next to the key of the relevant
> object
> displayed on the JSP.
> > The issue is: when we use the unmodified version of
> the code to remove
> an object, the object is successfully removed from the JCS
> remote
> server, but the 'remove' event for that object is not
> broadcast to all
> client machines. Client machines which start up after we
> remove the
> object get 'null' when they try to retrieve the object (the
> desired
> behaviour). However client machines which were already
> running and using
> this object continue to see the object in their view of the
> cache.
> > This problem occurs because the JCSAdminBean (used by
> this JSP) calls
> the wrong API in JCS to remove objects from the cache when
> it's running
> on the remote cache server. It calls the CompositeCache
> API, which is
> intended for use client-side only.
> > Our patches update JCSAdminBean to call this same API
> when its running
> on a client machine, BUT if it's running on a machine on
> which the JCS
> remote server is enabled, it calls the RemoteCacheServer
> API instead.
> > The fix involves replacing 3 methods in
> org.apache.jcs.admin.JCSAdminBean as follows:
> > /**
> > * Clears all regions in the
> cache.
> > * <p/>
> > * If this class is running within
> a remote cache server, clears
> all regions via the
> <code>RemoteCacheServer</code>
> > * API, so that removes will be
> broadcast to client machines.
> Otherwise clears all regions in the cache directly via
> > * the usual cache API.
> > */
> > public void clearAllRegions()
> throws IOException {
> > if
> (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> > //
> Not running in a remote cache server.
> > //
> Remove objects from the cache directly, as no need to
> broadcast removes to client machines...
> >
> String[] names =
> cacheHub.getCacheNames();
> >
> for (int i = 0; i < names.length; i++)
> {
> >
> cacheHub.getCache(names[i]).removeAll();
> > }
> > }
> > else {
> > //
> Running in a remote cache server.
> > //
> Remove objects via the RemoteCacheServer API, so that
> removes will be broadcast to client machines...
> >
> try {
> >
> String[] cacheNames =
> CompositeCacheManager.getInstance().getCacheNames();
> >
> // Call
> remoteCacheServer.removeAll(String) for each
> cacheName...
> >
> // Note: We must do this using reflection
> to bypass
> its package-private access...
> >
> Object remoteCacheServerObject =
> RemoteCacheServerFactory.getRemoteCacheServer();
> >
> Method removeAllMethod =
> remoteCacheServerObject.getClass().getMethod("removeAll",
> new
> Class[]{String.class});
> >
> boolean previouslyAccessibility =
> removeAllMethod.isAccessible();
> >
> removeAllMethod.setAccessible(true);
> >
> for (int i = 0; i < cacheNames.length;
> i++) {
> >
> String cacheName = cacheNames[i];
> >
>
> removeAllMethod.invoke(remoteCacheServerObject,
> new Object[]{cacheName});
> >
> }
> >
> removeAllMethod.setAccessible(previouslyAccessibility);
> > }
> >
> catch (Exception e) {
> >
> throw new IllegalStateException("Failed to
> remove all
> elements from all cache regions: " + e, e);
> > }
> > }
> > }
> > /**
> > * Clears a particular cache
> region.
> > * <p/>
> > * If this class is running within
> a remote cache server, clears
> the region via the
> <code>RemoteCacheServer</code>
> > * API, so that removes will be
> broadcast to client machines.
> Otherwise clears the region directly via the usual
> > * cache API.
> > */
> > public void clearRegion(String
> cacheName) throws IOException {
> > if (cacheName ==
> null) {
> >
> throw new IllegalArgumentException("The
> cache name
> specified was null.");
> > }
> > if
> (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> > //
> Not running in a remote cache server.
> > //
> Remove objects from the cache directly, as no need to
> broadcast removes to client machines...
> >
> cacheHub.getCache(cacheName).removeAll();
> > }
> > else {
> > //
> Running in a remote cache server.
> > //
> Remove objects via the RemoteCacheServer API, so that
> removes will be broadcast to client machines...
> >
> try {
> >
> // Call
> remoteCacheServer.removeAll(String)...
> >
> // Note: We must do this using reflection
> to bypass
> its package-private access...
> >
> Object remoteCacheServerObject =
> RemoteCacheServerFactory.getRemoteCacheServer();
> >
> Method removeAllMethod =
> remoteCacheServerObject.getClass().getMethod("removeAll",
> new
> Class[]{String.class});
> >
> boolean previouslyAccessibility =
> removeAllMethod.isAccessible();
> >
> removeAllMethod.setAccessible(true);
> >
> removeAllMethod.invoke(remoteCacheServerObject,
> new
> Object[]{cacheName});
> >
> removeAllMethod.setAccessible(previouslyAccessibility);
> > }
> >
> catch (Exception e) {
> >
> throw new IllegalStateException("Failed to
> remove all
> elements from cache region [" + cacheName + "]: " + e, e);
> > }
> > }
> > }
> > /**
> > * Removes a particular item from a
> particular region.
> > * <p/>
> > * If this class is running within
> a remote cache server, removes
> the item via the
> <code>RemoteCacheServer</code>
> > * API, so that removes will be
> broadcast to client machines.
> Otherwise clears the region directly via the usual
> > * cache API.
> > *
> > * @param cacheName
> > * @param key
> > *
> > * @throws IOException
> > */
> > public void removeItem(String
> cacheName, String key) throws
> IOException {
> > if (cacheName ==
> null) {
> >
> throw new IllegalArgumentException("The
> cache name
> specified was null.");
> > }
> > if (key == null)
> {
> >
> throw new IllegalArgumentException("The
> key specified was
> null.");
> > }
> > if
> (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> > //
> Not running in a remote cache server.
> > //
> Remove objects from the cache directly, as no need to
> broadcast removes to client machines...
> >
> cacheHub.getCache(cacheName).remove(key);
> > }
> > else {
> > //
> Running in a remote cache server.
> > //
> Remove objects via the RemoteCacheServer API, so that
> removes will be broadcast to client machines...
> >
> try {
> >
> Object keyToRemove = null;
> >
> CompositeCache cache =
> CompositeCacheManager.getInstance().getCache(cacheName);
> >
> // A String key was supplied, but to
> remove elements
> via the RemoteCacheServer API, we need the
> >
> // actual key object as stored in the
> cache (i.e. a
> Serializable object). To find the key in this form,
> >
> // we iterate through all keys stored in
> the memory
> cache until we find one whose toString matches
> >
> // the string supplied...
> >
> Object[] allKeysInCache =
> cache.getMemoryCache().getKeyArray();
> >
> for (int i = 0; i <
> allKeysInCache.length; i++) {
> >
> Object keyInCache =
> allKeysInCache[i];
> >
> if
> (keyInCache.toString().equals(key)) {
> >
> if (keyToRemove ==
> null) {
> >
>
> keyToRemove = keyInCache;
> >
> }
> >
> else {
> >
> // A
> key matching the one specified was
> already found...
> >
> throw
> new
> IllegalStateException("Unexpectedly found duplicate keys in
> the cache
> region matching the key specified.");
> >
> }
> >
> }
> >
> }
> >
> if (keyToRemove == null) {
> >
> throw new IllegalStateException("No
> match for this
> key could be found in the set of keys retrieved from the
> memory
> cache.");
> >
> }
> >
> if (!(keyToRemove instanceof
> Serializable)) {
> >
> throw new
> IllegalStateException("Found key [" +
> keyToRemove + ", " + keyToRemove.getClass() + "] in cache
> matching key
> specified, however key found in cache is unexpectedly not
> serializable.");
> >
> }
> >
> // At this point, we have retrieved the
> matching
> Serializable key.
> >
> // Call remoteCacheServer.remove(String,
> Serializable)...
> >
> // Note: We must fo this using reflection
> to bypass
> its package-private access...
> >
> Object remoteCacheServerObject =
> RemoteCacheServerFactory.getRemoteCacheServer();
> >
> Method removeMethod =
> remoteCacheServerObject.getClass().getMethod("remove", new
> Class[]{String.class, Serializable.class});
> >
> boolean previouslyAccessibility =
> removeMethod.isAccessible();
> >
> removeMethod.setAccessible(true);
> >
> removeMethod.invoke(remoteCacheServerObject,
> new
> Object[]{cacheName, keyToRemove});
> >
> removeMethod.setAccessible(previouslyAccessibility);
> > }
> >
> catch (Exception e) {
> >
> throw new IllegalStateException("Failed to
> remove
> element with key [" + key + ", " + key.getClass() + "] from
> cache region
> [" + cacheName + "]: " + e, e);
> > }
> > }
> > }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue
> online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Any reason that the RemoteCacheServer class is not exposed in the
Javadocs?
http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/auxiliary/remote/se
rver/RemoteCacheServerFactory.html
-----Original Message-----
From: Aaron Smuts (JIRA) [mailto:jira@apache.org]
Sent: Monday, August 31, 2009 8:29 AM
To: jcs-dev@jakarta.apache.org
Subject: [jira] Commented: (JCS-68) Admin.jsp on remote cache server
does not broadcast removes - patch
[
https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plu
gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749487#act
ion_12749487 ]
Aaron Smuts commented on JCS-68:
--------------------------------
Thanks, this is a good idea. Why are you calling the remove method via
reflection? That's too fragile. Especially without any unit tests. I
need unit tests for all changes.
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the
JCSAdmin.jsp when it's used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse
the objects stored in our distributed cache (i.e. uploaded by the client
servers), and allows us to remove arbitrary objects from the distributed
cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove
an object, the object is successfully removed from the JCS remote
server, but the 'remove' event for that object is not broadcast to all
client machines. Client machines which start up after we remove the
object get 'null' when they try to retrieve the object (the desired
behaviour). However client machines which were already running and using
this object continue to see the object in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls
the wrong API in JCS to remove objects from the cache when it's running
on the remote cache server. It calls the CompositeCache API, which is
intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running
on a client machine, BUT if it's running on a machine on which the JCS
remote server is enabled, it calls the RemoteCacheServer API instead.
> The fix involves replacing 3 methods in
org.apache.jcs.admin.JCSAdminBean as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears
all regions via the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines.
Otherwise clears all regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to
broadcast removes to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that
removes will be broadcast to client machines...
> try {
> String[] cacheNames =
CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each
cacheName...
> // Note: We must do this using reflection to bypass
its package-private access...
> Object remoteCacheServerObject =
RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod =
remoteCacheServerObject.getClass().getMethod("removeAll", new
Class[]{String.class});
> boolean previouslyAccessibility =
removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject,
new Object[]{cacheName});
> }
>
removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all
elements from all cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears
the region via the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines.
Otherwise clears the region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name
specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to
broadcast removes to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that
removes will be broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass
its package-private access...
> Object remoteCacheServerObject =
RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod =
remoteCacheServerObject.getClass().getMethod("removeAll", new
Class[]{String.class});
> boolean previouslyAccessibility =
removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new
Object[]{cacheName});
>
removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all
elements from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes
the item via the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines.
Otherwise clears the region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws
IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name
specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was
null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to
broadcast removes to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that
removes will be broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache =
CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements
via the RemoteCacheServer API, we need the
> // actual key object as stored in the cache (i.e. a
Serializable object). To find the key in this form,
> // we iterate through all keys stored in the memory
cache until we find one whose toString matches
> // the string supplied...
> Object[] allKeysInCache =
cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was
already found...
> throw new
IllegalStateException("Unexpectedly found duplicate keys in the cache
region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this
key could be found in the set of keys retrieved from the memory
cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" +
keyToRemove + ", " + keyToRemove.getClass() + "] in cache matching key
specified, however key found in cache is unexpectedly not
serializable.");
> }
> // At this point, we have retrieved the matching
Serializable key.
> // Call remoteCacheServer.remove(String,
Serializable)...
> // Note: We must fo this using reflection to bypass
its package-private access...
> Object remoteCacheServerObject =
RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod =
remoteCacheServerObject.getClass().getMethod("remove", new
Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility =
removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new
Object[]{cacheName, keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove
element with key [" + key + ", " + key.getClass() + "] from cache region
[" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749487#action_12749487
]
Aaron Smuts commented on JCS-68:
--------------------------------
Thanks, this is a good idea. Why are you calling the remove method via reflection? That's
too fragile. Especially without any unit tests. I need unit tests for all changes.
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's
used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse the objects stored
in our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove an object, the
object is successfully removed from the JCS remote server, but the 'remove' event for that
object is not broadcast to all client machines. Client machines which start up after we remove
the object get 'null' when they try to retrieve the object (the desired behaviour). However
client machines which were already running and using this object continue to see the object
in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in
JCS to remove objects from the cache when it's running on the remote cache server. It calls
the CompositeCache API, which is intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
> The fix involves replacing 3 methods in org.apache.jcs.admin.JCSAdminBean as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears all regions via
the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears all
regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each cacheName...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> }
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from all
cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears the region via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes the item via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
> // actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
> // we iterate through all keys stored in the memory cache until we find
one whose toString matches
> // the string supplied...
> Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was already found...
> throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" + keyToRemove + ",
" + keyToRemove.getClass() + "] in cache matching key specified, however key found in cache
is unexpectedly not serializable.");
> }
> // At this point, we have retrieved the matching Serializable key.
> // Call remoteCacheServer.remove(String, Serializable)...
> // Note: We must fo this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility = removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName,
keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove element with key ["
+ key + ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Gallagher updated JCS-68:
-------------------------------
Description:
We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's used
on a JCS remote cache server.
We use this JSP on our remote cache server. This allows us to browse the objects stored in
our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
The issue is: when we use the unmodified version of the code to remove an object, the object
is successfully removed from the JCS remote server, but the 'remove' event for that object
is not broadcast to all client machines. Client machines which start up after we remove the
object get 'null' when they try to retrieve the object (the desired behaviour). However client
machines which were already running and using this object continue to see the object in their
view of the cache.
This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in JCS
to remove objects from the cache when it's running on the remote cache server. It calls the
CompositeCache API, which is intended for use client-side only.
Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
The fix involves replacing 3 methods in org.apache.jcs.admin.JCSAdminBean as follows:
/**
* Clears all regions in the cache.
* <p/>
* If this class is running within a remote cache server, clears all regions via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears all regions
in the cache directly via
* the usual cache API.
*/
public void clearAllRegions() throws IOException {
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
String[] names = cacheHub.getCacheNames();
for (int i = 0; i < names.length; i++) {
cacheHub.getCache(names[i]).removeAll();
}
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
// Call remoteCacheServer.removeAll(String) for each cacheName...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
for (int i = 0; i < cacheNames.length; i++) {
String cacheName = cacheNames[i];
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
}
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from all cache
regions: " + e, e);
}
}
}
/**
* Clears a particular cache region.
* <p/>
* If this class is running within a remote cache server, clears the region via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*/
public void clearRegion(String cacheName) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).removeAll();
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
// Call remoteCacheServer.removeAll(String)...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
}
}
}
/**
* Removes a particular item from a particular region.
* <p/>
* If this class is running within a remote cache server, removes the item via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*
* @param cacheName
* @param key
*
* @throws IOException
*/
public void removeItem(String cacheName, String key) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (key == null) {
throw new IllegalArgumentException("The key specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).remove(key);
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
Object keyToRemove = null;
CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
// A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
// actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
// we iterate through all keys stored in the memory cache until we find one
whose toString matches
// the string supplied...
Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
for (int i = 0; i < allKeysInCache.length; i++) {
Object keyInCache = allKeysInCache[i];
if (keyInCache.toString().equals(key)) {
if (keyToRemove == null) {
keyToRemove = keyInCache;
}
else {
// A key matching the one specified was already found...
throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
}
}
}
if (keyToRemove == null) {
throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
}
if (!(keyToRemove instanceof Serializable)) {
throw new IllegalStateException("Found key [" + keyToRemove + ", " + keyToRemove.getClass()
+ "] in cache matching key specified, however key found in cache is unexpectedly not serializable.");
}
// At this point, we have retrieved the matching Serializable key.
// Call remoteCacheServer.remove(String, Serializable)...
// Note: We must fo this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
boolean previouslyAccessibility = removeMethod.isAccessible();
removeMethod.setAccessible(true);
removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName, keyToRemove});
removeMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove element with key [" + key
+ ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
}
}
}
was:
We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's used
on a JCS remote cache server.
We use this JSP on our remote cache server. This allows us to browse the objects stored in
our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
The issue is: when we use the unmodified version of the code to remove an object, the object
is successfully removed from the JCS remote server, but the 'remove' event for that object
is not broadcast to all client machines. Client machines which start up after we remove the
object get 'null' when they try to retrieve the object (the desired behaviour). However client
machines which were already running and using this object continue to see the object in their
view of the cache.
This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in JCS
to remove objects from the cache when it's running on the remote cache server. It calls the
CompositeCache API, which is intended for use client-side only.
Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
The fix involves replacing a 3 methods in org.apache.jcs.admin.JCSAdminBean with as follows:
/**
* Clears all regions in the cache.
* <p/>
* If this class is running within a remote cache server, clears all regions via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears all regions
in the cache directly via
* the usual cache API.
*/
public void clearAllRegions() throws IOException {
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
String[] names = cacheHub.getCacheNames();
for (int i = 0; i < names.length; i++) {
cacheHub.getCache(names[i]).removeAll();
}
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
// Call remoteCacheServer.removeAll(String) for each cacheName...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
for (int i = 0; i < cacheNames.length; i++) {
String cacheName = cacheNames[i];
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
}
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from all cache
regions: " + e, e);
}
}
}
/**
* Clears a particular cache region.
* <p/>
* If this class is running within a remote cache server, clears the region via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*/
public void clearRegion(String cacheName) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).removeAll();
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
// Call remoteCacheServer.removeAll(String)...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
}
}
}
/**
* Removes a particular item from a particular region.
* <p/>
* If this class is running within a remote cache server, removes the item via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*
* @param cacheName
* @param key
*
* @throws IOException
*/
public void removeItem(String cacheName, String key) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (key == null) {
throw new IllegalArgumentException("The key specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).remove(key);
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
Object keyToRemove = null;
CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
// A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
// actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
// we iterate through all keys stored in the memory cache until we find one
whose toString matches
// the string supplied...
Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
for (int i = 0; i < allKeysInCache.length; i++) {
Object keyInCache = allKeysInCache[i];
if (keyInCache.toString().equals(key)) {
if (keyToRemove == null) {
keyToRemove = keyInCache;
}
else {
// A key matching the one specified was already found...
throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
}
}
}
if (keyToRemove == null) {
throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
}
if (!(keyToRemove instanceof Serializable)) {
throw new IllegalStateException("Found key [" + keyToRemove + ", " + keyToRemove.getClass()
+ "] in cache matching key specified, however key found in cache is unexpectedly not serializable.");
}
// At this point, we have retrieved the matching Serializable key.
// Call remoteCacheServer.remove(String, Serializable)...
// Note: We must fo this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
boolean previouslyAccessibility = removeMethod.isAccessible();
removeMethod.setAccessible(true);
removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName, keyToRemove});
removeMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove element with key [" + key
+ ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
}
}
}
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's
used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse the objects stored
in our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove an object, the
object is successfully removed from the JCS remote server, but the 'remove' event for that
object is not broadcast to all client machines. Client machines which start up after we remove
the object get 'null' when they try to retrieve the object (the desired behaviour). However
client machines which were already running and using this object continue to see the object
in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in
JCS to remove objects from the cache when it's running on the remote cache server. It calls
the CompositeCache API, which is intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
> The fix involves replacing 3 methods in org.apache.jcs.admin.JCSAdminBean as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears all regions via
the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears all
regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each cacheName...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> }
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from all
cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears the region via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes the item via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
> // actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
> // we iterate through all keys stored in the memory cache until we find
one whose toString matches
> // the string supplied...
> Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was already found...
> throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" + keyToRemove + ",
" + keyToRemove.getClass() + "] in cache matching key specified, however key found in cache
is unexpectedly not serializable.");
> }
> // At this point, we have retrieved the matching Serializable key.
> // Call remoteCacheServer.remove(String, Serializable)...
> // Note: We must fo this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility = removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName,
keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove element with key ["
+ key + ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
[ https://issues.apache.org/jira/browse/JCS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748906#action_12748906
]
Niall Gallagher commented on JCS-68:
------------------------------------
FYI we updated the getByteCount method in JCSAdminBean too. This is not strictly necessary
to fix the issue above, it's fixes a display issue only. The unmodified code wasn't accounting
for objects which were already serialized (which is always the case on the remote cache server).
This version accounts for objects which are already serialized...
/**
* Tries to estimate how much data is in a region. This is expensive. If there are any
non serializable objects in
* the region or an error occurs, suppresses exceptions and returns 0.
* <p/>
*
* @return int The size of the region in bytes.
*/
public int getByteCount(CompositeCache cache) throws Exception {
if (cache == null) {
throw new IllegalArgumentException("The cache object specified was null.");
}
long size = 0;
try {
MemoryCache memCache = cache.getMemoryCache();
Iterator iter = memCache.getIterator();
while (iter.hasNext()) {
Map.Entry nextMapEntry = (Map.Entry) iter.next();
ICacheElement ice = (ICacheElement) nextMapEntry.getValue();
if (ice instanceof CacheElementSerialized) {
size = size + ((CacheElementSerialized) ice).getSerializedValue().length;
}
else {
Serializable element = ice.getVal();
//CountingOnlyOutputStream: Keeps track of the number of bytes written
to it, but doesn't write them anywhere.
CountingOnlyOutputStream counter = new CountingOnlyOutputStream();
try {
ObjectOutputStream out = new ObjectOutputStream(counter);
out.writeObject(element);
}
catch (IOException e) {
throw new RuntimeException("IOException while trying to measure the
size of the cached element", e);
}
// 4 bytes lost for the serialization header
size = size + counter.getCount() - 4;
}
}
if (size > Integer.MAX_VALUE) {
throw new IllegalStateException("The size of cache " + cache.getCacheName()
+ " (" + size + " bytes) is too large to be represented as an integer.");
}
}
catch (Exception e) {
// throw new RuntimeException("Failed to calculate the size of cache region ["
+ cache.getCacheName() + "]:" + e, e);
return 0;
}
return (int) size;
}
> Admin.jsp on remote cache server does not broadcast removes - patch
> -------------------------------------------------------------------
>
> Key: JCS-68
> URL: https://issues.apache.org/jira/browse/JCS-68
> Project: JCS
> Issue Type: Bug
> Components: RMI Remote Cache
> Affects Versions: jcs-1.3, jcs-1.4-dev
> Environment: All
> Reporter: Niall Gallagher
> Assignee: Aaron Smuts
> Priority: Minor
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's
used on a JCS remote cache server.
> We use this JSP on our remote cache server. This allows us to browse the objects stored
in our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
> The issue is: when we use the unmodified version of the code to remove an object, the
object is successfully removed from the JCS remote server, but the 'remove' event for that
object is not broadcast to all client machines. Client machines which start up after we remove
the object get 'null' when they try to retrieve the object (the desired behaviour). However
client machines which were already running and using this object continue to see the object
in their view of the cache.
> This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in
JCS to remove objects from the cache when it's running on the remote cache server. It calls
the CompositeCache API, which is intended for use client-side only.
> Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
> The fix involves replacing a 3 methods in org.apache.jcs.admin.JCSAdminBean with as follows:
> /**
> * Clears all regions in the cache.
> * <p/>
> * If this class is running within a remote cache server, clears all regions via
the <code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears all
regions in the cache directly via
> * the usual cache API.
> */
> public void clearAllRegions() throws IOException {
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> String[] names = cacheHub.getCacheNames();
> for (int i = 0; i < names.length; i++) {
> cacheHub.getCache(names[i]).removeAll();
> }
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
> // Call remoteCacheServer.removeAll(String) for each cacheName...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> for (int i = 0; i < cacheNames.length; i++) {
> String cacheName = cacheNames[i];
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> }
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from all
cache regions: " + e, e);
> }
> }
> }
> /**
> * Clears a particular cache region.
> * <p/>
> * If this class is running within a remote cache server, clears the region via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> */
> public void clearRegion(String cacheName) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).removeAll();
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> // Call remoteCacheServer.removeAll(String)...
> // Note: We must do this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
> boolean previouslyAccessibility = removeAllMethod.isAccessible();
> removeAllMethod.setAccessible(true);
> removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
> removeAllMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
> }
> }
> }
> /**
> * Removes a particular item from a particular region.
> * <p/>
> * If this class is running within a remote cache server, removes the item via the
<code>RemoteCacheServer</code>
> * API, so that removes will be broadcast to client machines. Otherwise clears the
region directly via the usual
> * cache API.
> *
> * @param cacheName
> * @param key
> *
> * @throws IOException
> */
> public void removeItem(String cacheName, String key) throws IOException {
> if (cacheName == null) {
> throw new IllegalArgumentException("The cache name specified was null.");
> }
> if (key == null) {
> throw new IllegalArgumentException("The key specified was null.");
> }
> if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
> // Not running in a remote cache server.
> // Remove objects from the cache directly, as no need to broadcast removes
to client machines...
> cacheHub.getCache(cacheName).remove(key);
> }
> else {
> // Running in a remote cache server.
> // Remove objects via the RemoteCacheServer API, so that removes will be
broadcast to client machines...
> try {
> Object keyToRemove = null;
> CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
> // A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
> // actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
> // we iterate through all keys stored in the memory cache until we find
one whose toString matches
> // the string supplied...
> Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
> for (int i = 0; i < allKeysInCache.length; i++) {
> Object keyInCache = allKeysInCache[i];
> if (keyInCache.toString().equals(key)) {
> if (keyToRemove == null) {
> keyToRemove = keyInCache;
> }
> else {
> // A key matching the one specified was already found...
> throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
> }
> }
> }
> if (keyToRemove == null) {
> throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
> }
> if (!(keyToRemove instanceof Serializable)) {
> throw new IllegalStateException("Found key [" + keyToRemove + ",
" + keyToRemove.getClass() + "] in cache matching key specified, however key found in cache
is unexpectedly not serializable.");
> }
> // At this point, we have retrieved the matching Serializable key.
> // Call remoteCacheServer.remove(String, Serializable)...
> // Note: We must fo this using reflection to bypass its package-private
access...
> Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
> Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
> boolean previouslyAccessibility = removeMethod.isAccessible();
> removeMethod.setAccessible(true);
> removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName,
keyToRemove});
> removeMethod.setAccessible(previouslyAccessibility);
> }
> catch (Exception e) {
> throw new IllegalStateException("Failed to remove element with key ["
+ key + ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Admin.jsp on remote cache server does not broadcast removes - patch
-------------------------------------------------------------------
Key: JCS-68
URL: https://issues.apache.org/jira/browse/JCS-68
Project: JCS
Issue Type: Bug
Components: RMI Remote Cache
Affects Versions: jcs-1.3, jcs-1.4-dev
Environment: All
Reporter: Niall Gallagher
Assignee: Aaron Smuts
Priority: Minor
We'd like to contribute some patches to fix an issue with the JCSAdmin.jsp when it's used
on a JCS remote cache server.
We use this JSP on our remote cache server. This allows us to browse the objects stored in
our distributed cache (i.e. uploaded by the client servers), and allows us to remove arbitrary
objects from the distributed cache by clicking 'remove' next to the key of the relevant object
displayed on the JSP.
The issue is: when we use the unmodified version of the code to remove an object, the object
is successfully removed from the JCS remote server, but the 'remove' event for that object
is not broadcast to all client machines. Client machines which start up after we remove the
object get 'null' when they try to retrieve the object (the desired behaviour). However client
machines which were already running and using this object continue to see the object in their
view of the cache.
This problem occurs because the JCSAdminBean (used by this JSP) calls the wrong API in JCS
to remove objects from the cache when it's running on the remote cache server. It calls the
CompositeCache API, which is intended for use client-side only.
Our patches update JCSAdminBean to call this same API when its running on a client machine,
BUT if it's running on a machine on which the JCS remote server is enabled, it calls the RemoteCacheServer
API instead.
The fix involves replacing a 3 methods in org.apache.jcs.admin.JCSAdminBean with as follows:
/**
* Clears all regions in the cache.
* <p/>
* If this class is running within a remote cache server, clears all regions via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears all regions
in the cache directly via
* the usual cache API.
*/
public void clearAllRegions() throws IOException {
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
String[] names = cacheHub.getCacheNames();
for (int i = 0; i < names.length; i++) {
cacheHub.getCache(names[i]).removeAll();
}
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
String[] cacheNames = CompositeCacheManager.getInstance().getCacheNames();
// Call remoteCacheServer.removeAll(String) for each cacheName...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
for (int i = 0; i < cacheNames.length; i++) {
String cacheName = cacheNames[i];
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
}
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from all cache
regions: " + e, e);
}
}
}
/**
* Clears a particular cache region.
* <p/>
* If this class is running within a remote cache server, clears the region via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*/
public void clearRegion(String cacheName) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).removeAll();
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
// Call remoteCacheServer.removeAll(String)...
// Note: We must do this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeAllMethod = remoteCacheServerObject.getClass().getMethod("removeAll",
new Class[]{String.class});
boolean previouslyAccessibility = removeAllMethod.isAccessible();
removeAllMethod.setAccessible(true);
removeAllMethod.invoke(remoteCacheServerObject, new Object[]{cacheName});
removeAllMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove all elements from cache
region [" + cacheName + "]: " + e, e);
}
}
}
/**
* Removes a particular item from a particular region.
* <p/>
* If this class is running within a remote cache server, removes the item via the <code>RemoteCacheServer</code>
* API, so that removes will be broadcast to client machines. Otherwise clears the region
directly via the usual
* cache API.
*
* @param cacheName
* @param key
*
* @throws IOException
*/
public void removeItem(String cacheName, String key) throws IOException {
if (cacheName == null) {
throw new IllegalArgumentException("The cache name specified was null.");
}
if (key == null) {
throw new IllegalArgumentException("The key specified was null.");
}
if (RemoteCacheServerFactory.getRemoteCacheServer() == null) {
// Not running in a remote cache server.
// Remove objects from the cache directly, as no need to broadcast removes to
client machines...
cacheHub.getCache(cacheName).remove(key);
}
else {
// Running in a remote cache server.
// Remove objects via the RemoteCacheServer API, so that removes will be broadcast
to client machines...
try {
Object keyToRemove = null;
CompositeCache cache = CompositeCacheManager.getInstance().getCache(cacheName);
// A String key was supplied, but to remove elements via the RemoteCacheServer
API, we need the
// actual key object as stored in the cache (i.e. a Serializable object).
To find the key in this form,
// we iterate through all keys stored in the memory cache until we find one
whose toString matches
// the string supplied...
Object[] allKeysInCache = cache.getMemoryCache().getKeyArray();
for (int i = 0; i < allKeysInCache.length; i++) {
Object keyInCache = allKeysInCache[i];
if (keyInCache.toString().equals(key)) {
if (keyToRemove == null) {
keyToRemove = keyInCache;
}
else {
// A key matching the one specified was already found...
throw new IllegalStateException("Unexpectedly found duplicate
keys in the cache region matching the key specified.");
}
}
}
if (keyToRemove == null) {
throw new IllegalStateException("No match for this key could be found
in the set of keys retrieved from the memory cache.");
}
if (!(keyToRemove instanceof Serializable)) {
throw new IllegalStateException("Found key [" + keyToRemove + ", " + keyToRemove.getClass()
+ "] in cache matching key specified, however key found in cache is unexpectedly not serializable.");
}
// At this point, we have retrieved the matching Serializable key.
// Call remoteCacheServer.remove(String, Serializable)...
// Note: We must fo this using reflection to bypass its package-private access...
Object remoteCacheServerObject = RemoteCacheServerFactory.getRemoteCacheServer();
Method removeMethod = remoteCacheServerObject.getClass().getMethod("remove",
new Class[]{String.class, Serializable.class});
boolean previouslyAccessibility = removeMethod.isAccessible();
removeMethod.setAccessible(true);
removeMethod.invoke(remoteCacheServerObject, new Object[]{cacheName, keyToRemove});
removeMethod.setAccessible(previouslyAccessibility);
}
catch (Exception e) {
throw new IllegalStateException("Failed to remove element with key [" + key
+ ", " + key.getClass() + "] from cache region [" + cacheName + "]: " + e, e);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
I faced the same problem and finally it was resolved by changing the oracle driver. I replaced mine with a newer version and it worked! I was not able to find out what exactly changed in the newer version that made it work, I suspect it might be the jdk version difference or may be the default charset for these drivers has changed, not sure what but I am really curious to find it out. Here are version details of these drivers (jars attached): Working: Manifest-Version: 1.0 Specification-Title: Oracle JDBC driver classes for use with JDK14 Sealed: false Created-By: 1.4.2_08 (Sun Microsystems Inc.) Implementation-Title: ojdbc14.jar Specification-Vendor: Oracle Corporation Specification-Version: Oracle JDBC Driver version - "10.2.0.3.0" Implementation-Version: Oracle JDBC Driver version - "10.2.0.3.0" Implementation-Vendor: Oracle Corporation Implementation-Time: Fri Sep 29 09:43:24 2006 Name: oracle/sql/converter/ Sealed: false Name: oracle/sql/ Sealed: false Name: oracle/sql/converter_xcharset/ Sealed: false Not Working: Manifest-Version: 1.0 Implementation-Version: "Oracle JDBC Driver version - 10.1.0.2.0" Specification-Title: "Oracle JDBC driver classes for use with JDK1. 4" Specification-Version: "Oracle JDBC Driver version - 10.1.0.2.0" Implementation-Title: "ojdbc14.jar" Created-By: 1.2.2 (Sun Microsystems Inc.) Implementation-Time: "Wed Jan 21 00:48:12 2004" Implementation-Vendor: "Oracle Corporation" Specification-Vendor: "Oracle Corporation" Regards Vishal Sinha -- View this message in context: http://www.nabble.com/-ERROR--JDBCDiskCache---java.io.StreamCorruptedException%3A-invalid-stream-header-tp11169850p25156423.html Sent from the JCS - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Author: asmuts
Date: Wed Aug 12 21:41:44 2009
New Revision: 803719
URL: http://svn.apache.org/viewvc?rev=803719&view=rev
Log:
Added a rough sketch of a partitioned cache access. I changed the get multiple to return
a Map and not a HashMap. Unfortunately, this may break some client. I hate to do this, but
it's a trivial fix.
Added:
jakarta/jcs/trunk/src/java/org/apache/jcs/access/PartitionedCacheAccess.java
jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/ConfigurationException.java
jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/AbstractPropertyContainer.java
jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactory.java
jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactoryFileImpl.java
Modified:
jakarta/jcs/trunk/src/java/org/apache/jcs/access/CacheAccess.java
jakarta/jcs/trunk/src/java/org/apache/jcs/access/behavior/ICacheAccess.java
jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/CacheException.java
jakarta/jcs/trunk/src/java/org/apache/jcs/engine/match/KeyMatcherPatternImpl.java
Modified: jakarta/jcs/trunk/src/java/org/apache/jcs/access/CacheAccess.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/access/CacheAccess.java?rev=803719&r1=803718&r2=803719&view=diff
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/access/CacheAccess.java (original)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/access/CacheAccess.java Wed Aug 12 21:41:44
2009
@@ -200,7 +200,7 @@
* @param pattern - a key pattern for the objects stored
* @return A map of key to values. These are stripped from the wrapper.
*/
- public HashMap getMatching( String pattern )
+ public Map getMatching( String pattern )
{
HashMap unwrappedResults = new HashMap();
Added: jakarta/jcs/trunk/src/java/org/apache/jcs/access/PartitionedCacheAccess.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/access/PartitionedCacheAccess.java?rev=803719&view=auto
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/access/PartitionedCacheAccess.java (added)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/access/PartitionedCacheAccess.java Wed Aug 12
21:41:44 2009
@@ -0,0 +1,737 @@
+package org.apache.jcs.access;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.apache.jcs.JCS;
+import org.apache.jcs.access.behavior.ICacheAccess;
+import org.apache.jcs.access.exception.CacheException;
+import org.apache.jcs.access.exception.ConfigurationException;
+import org.apache.jcs.engine.behavior.ICacheElement;
+import org.apache.jcs.engine.behavior.ICompositeCacheAttributes;
+import org.apache.jcs.engine.behavior.IElementAttributes;
+import org.apache.jcs.utils.props.AbstractPropertyContainer;
+
+/**
+ * TODO: Add new methods that will allow you to provide a partition indicator for all major
calls. Add an interface as well.
+ * <p>
+ * This handles dividing puts and gets.
+ * <p>
+ * There are two required properties.
+ * <p>
+ * <ol>
+ * <li>.numberOfPartitions</li>
+ * <li>.partitionRegionNamePrefix</li>
+ * </ol>
+ * System properties will override values in the properties file.
+ * <p>
+ * We use a JCS region name for each partition that looks like this: partitionRegionNamePrefix
+ "_"
+ * + patitionNuber. The number is ) indexed based.
+ * <p>
+ * @author Aaron Smuts
+ */
+public class PartitionedCacheAccess
+ extends AbstractPropertyContainer
+ implements ICacheAccess
+{
+ /** the logger. */
+ private static final Log log = LogFactory.getLog( PartitionedCacheAccess.class );
+
+ /** The number of partitions. */
+ private int numberOfPartitions = 1;
+
+ /**
+ * We use a JCS region name for each partition that looks like this: partitionRegionNamePrefix
+
+ * "_" + partitionNumber
+ */
+ private String partitionRegionNamePrefix;
+
+ /** An array of partitions built during initialization. */
+ private ICacheAccess[] partitions;
+
+ /** Is the class initialized. */
+ private boolean initialized = false;
+
+ /** Sets default properties heading and group. */
+ public PartitionedCacheAccess()
+ {
+ setPropertiesHeading( "PartitionedCacheAccess" );
+ setPropertiesGroup( "cache" );
+ }
+
+ /**
+ * Puts the value into the appropriate cache partition.
+ * <p>
+ * @param key key
+ * @param object object
+ * @throws CacheException on configuration problem
+ */
+ public void put( Object key, Object object )
+ throws CacheException
+ {
+ if ( key == null || object == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot put null into the cache." );
+ return;
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+ try
+ {
+ partitions[partition].put( key, object );
+ }
+ catch ( CacheException e )
+ {
+ log.error( "Problem putting value for key [" + key + "] in cache [" + partitions[partition]
+ "]" );
+ throw ( e );
+ }
+ }
+
+ /**
+ * Puts in cache if an item does not exist with the name in that region.
+ * <p>
+ * @param key
+ * @param object
+ * @throws CacheException
+ */
+ public void putSafe( Object key, Object object )
+ throws CacheException
+ {
+ if ( key == null || object == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot putSafe null into the cache."
);
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+ partitions[partition].putSafe( key, object );
+ }
+
+ /**
+ * Puts the value into the appropriate cache partition.
+ * <p>
+ * @param key key
+ * @param object object
+ * @param attr
+ * @throws CacheException on configuration problem
+ */
+ public void put( Object key, Object object, IElementAttributes attr )
+ throws CacheException
+ {
+ if ( key == null || object == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot put null into the cache." );
+ return;
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+ try
+ {
+ partitions[partition].put( key, object, attr );
+ }
+ catch ( CacheException e )
+ {
+ log.error( "Problem putting value for key [" + key + "] in cache [" + partitions[partition]
+ "]" );
+ throw ( e );
+ }
+ }
+
+ /**
+ * Gets the object for the key from the desired partition.
+ * <p>
+ * @param key key
+ * @return result, null if not found.
+ */
+ public Object get( Object key )
+ {
+ if ( key == null )
+ {
+ log.warn( "Bad input key [" + key + "]." );
+ return null;
+ }
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return null;
+ }
+
+ int partition = getPartitionNumberForKey( key );
+
+ return partitions[partition].get( key );
+ }
+
+ /**
+ * Gets the ICacheElement (the wrapped object) for the key from the desired partition.
+ * <p>
+ * @param key key
+ * @return result, null if not found.
+ */
+ public ICacheElement getCacheElement( Object key )
+ {
+ if ( key == null )
+ {
+ log.warn( "Bad input key [" + key + "]." );
+ return null;
+ }
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return null;
+ }
+
+ int partition = getPartitionNumberForKey( key );
+
+ return partitions[partition].getCacheElement( key );
+ }
+
+ /**
+ * This is a getMultiple. We try to group the keys so that we make as few calls as needed.
+ * <p>
+ * @param names
+ * @return Map of keys to ICacheElement
+ */
+ public Map getCacheElements( Set names )
+ {
+ if ( names == null )
+ {
+ log.warn( "Bad input names cannot be null." );
+ return Collections.EMPTY_MAP;
+ }
+
+ Set[] dividedNames = new Set[this.getNumberOfPartitions()];
+
+ Iterator it = names.iterator();
+ while ( it.hasNext() )
+ {
+ Object key = it.next();
+ int partition = getPartitionNumberForKey( key );
+ if ( dividedNames[partition] == null )
+ {
+ dividedNames[partition] = new HashSet();
+ }
+ dividedNames[partition].add( key );
+ }
+
+ Map result = new HashMap();
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ if ( dividedNames[i] != null && !dividedNames[i].isEmpty() )
+ {
+ result.putAll( partitions[i].getCacheElements( dividedNames[i] ) );
+ }
+ }
+ return result;
+ }
+
+ /**
+ * This is tricky. Do we need to get from all the partitions?
+ * <p>
+ * If this interface took an object, we could use the hashcode to determine the partition.
Then
+ * we could user the toString for the pattern.
+ * <p>
+ * @param pattern
+ * @return HashMap key to value
+ */
+ public Map getMatching( String pattern )
+ {
+ if ( pattern == null )
+ {
+ log.warn( "Bad input keypattern [" + pattern + "]." );
+ return null;
+ }
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return null;
+ }
+
+ Map result = new HashMap();
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ result.putAll( partitions[i].getMatching( pattern ) );
+ }
+ return result;
+ }
+
+ /**
+ * This is tricky. Do we need to get from all the partitions?
+ * <p>
+ * @param pattern
+ * @return HashMap key to ICacheElement
+ */
+ public Map getMatchingCacheElements( String pattern )
+ {
+ if ( pattern == null )
+ {
+ log.warn( "Bad input keypattern [" + pattern + "]." );
+ return null;
+ }
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return null;
+ }
+
+ Map result = new HashMap();
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ result.putAll( partitions[i].getMatchingCacheElements( pattern ) );
+ }
+ return result;
+ }
+
+ /**
+ * Calls remove on all partitions. This gets translated into a removeAll call.
+ * <p>
+ * @throws CacheException
+ */
+ public void remove()
+ throws CacheException
+ {
+ ensureInit();
+
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ partitions[i].remove();
+ }
+ }
+
+ /**
+ * Removes the item from the appropriate partition.
+ * <p>
+ * @param key
+ * @throws CacheException
+ */
+ public void remove( Object key )
+ throws CacheException
+ {
+ if ( key == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot remove null from the cache."
);
+ return;
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+ try
+ {
+ partitions[partition].remove( key );
+ }
+ catch ( CacheException e )
+ {
+ log.error( "Problem removing value for key [" + key + "] in cache [" + partitions[partition]
+ "]" );
+ throw ( e );
+ }
+ }
+
+ /**
+ * Calls free on each partition.
+ * <p>
+ * @param numberToFree
+ * @return number removed
+ * @throws CacheException
+ */
+ public int freeMemoryElements( int numberToFree )
+ throws CacheException
+ {
+ ensureInit();
+
+ int count = 0;
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ count += partitions[i].freeMemoryElements( numberToFree );
+ }
+ return count;
+ }
+
+ /**
+ * @return ICompositeCacheAttributes from the first partition.
+ */
+ public ICompositeCacheAttributes getCacheAttributes()
+ {
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return null;
+ }
+
+ if ( partitions.length == 0 )
+ {
+ return null;
+ }
+
+ return partitions[0].getCacheAttributes();
+ }
+
+ /**
+ * @return IElementAttributes from the first partition.
+ * @throws CacheException
+ */
+ public IElementAttributes getElementAttributes()
+ throws CacheException
+ {
+ ensureInit();
+
+ if ( partitions.length == 0 )
+ {
+ return null;
+ }
+
+ return partitions[0].getElementAttributes();
+ }
+
+ /**
+ * This is no more efficient than simply getting the cache element.
+ * <p>
+ * @param key
+ * @return IElementAttributes
+ * @throws CacheException
+ */
+ public IElementAttributes getElementAttributes( Object key )
+ throws CacheException
+ {
+ if ( key == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot getElementAttributes for null
from the cache." );
+ return null;
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+
+ return partitions[partition].getElementAttributes( key );
+ }
+
+ /**
+ * Resets the default element attributes on all partitions. This does not change items
that are
+ * already in the cache.
+ * <p>
+ * @param attributes
+ * @throws CacheException
+ */
+ public void resetElementAttributes( IElementAttributes attributes )
+ throws CacheException
+ {
+ ensureInit();
+
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ partitions[i].resetElementAttributes( attributes );
+ }
+ }
+
+ /**
+ * Resets the attributes for this item. This has the same effect as an update, in most
cases.
+ * None of the auxiliaries are optimized to do this more efficiently than a simply update.
+ * <p>
+ * @param key
+ * @param attributes
+ * @throws CacheException
+ */
+ public void resetElementAttributes( Object key, IElementAttributes attributes )
+ throws CacheException
+ {
+ if ( key == null )
+ {
+ log.warn( "Bad input key [" + key + "]. Cannot resetElementAttributes for null."
);
+ return;
+ }
+ ensureInit();
+
+ int partition = getPartitionNumberForKey( key );
+
+ partitions[partition].resetElementAttributes( key, attributes );
+ }
+
+ /**
+ * Sets the attributes on all the partitions.
+ * <p>
+ * @param cattr
+ */
+ public void setCacheAttributes( ICompositeCacheAttributes cattr )
+ {
+ try
+ {
+ ensureInit();
+ }
+ catch ( ConfigurationException e )
+ {
+ // TODO add exception to interface method.
+ log.error( "Couldn't configure partioned access.", e );
+ return;
+ }
+
+ for ( int i = 0; i < partitions.length; i++ )
+ {
+ partitions[i].setCacheAttributes( cattr );
+ }
+ }
+
+ /**
+ * This expects a numeric key. If the key cannot be converted into a number, we wil return
0.
+ * TODO we could md5 it or get the hashcode.
+ * <p>
+ * We determine the partition by taking the mod of the number of partions.
+ * <p>
+ * @param key key
+ * @return the partition number.
+ */
+ protected int getPartitionNumberForKey( Object key )
+ {
+ if ( key == null )
+ {
+ return 0;
+ }
+
+ long keyNum = getNumericValueForKey( key );
+
+ int partition = (int) ( keyNum % getNumberOfPartitions() );
+
+ if ( log.isDebugEnabled() )
+ {
+ log.debug( "Using partition [" + partition + "] for key [" + key + "]" );
+ }
+
+ return partition;
+ }
+
+ /**
+ * This can be overridden for special purposes.
+ * <p>
+ * @param key key
+ * @return long
+ */
+ public long getNumericValueForKey( Object key )
+ {
+ String keyString = key.toString();
+ long keyNum = -1;
+ try
+ {
+ keyNum = Long.parseLong( keyString );
+ }
+ catch ( NumberFormatException e )
+ {
+ // THIS IS UGLY, but I can't think of a better failsafe right now.
+ keyNum = key.hashCode();
+ log.warn( "Counldn't convert [" + key + "] into a number. Will use hashcode
[" + keyNum + "]" );
+ }
+ return keyNum;
+ }
+
+ /**
+ * Initialize if we haven't already.
+ * <p>
+ * @throws ConfigurationException on configuration problem
+ */
+ protected synchronized void ensureInit()
+ throws ConfigurationException
+ {
+ if ( !initialized )
+ {
+ initialize();
+ }
+ }
+
+ /**
+ * Use the partion prefix and the number of partions to get JCS regions.
+ * <p>
+ * @throws ConfigurationException on configuration problem
+ */
+ protected synchronized void initialize()
+ throws ConfigurationException
+ {
+ ensureProperties();
+
+ ICacheAccess[] tempPartitions = new ICacheAccess[this.getNumberOfPartitions()];
+ for ( int i = 0; i < this.getNumberOfPartitions(); i++ )
+ {
+ String regionName = this.getPartitionRegionNamePrefix() + "_" + i;
+ try
+ {
+ tempPartitions[i] = CacheAccess.getAccess( regionName );
+ }
+ catch ( CacheException e )
+ {
+ log.error( "Problem getting cache for region [" + regionName + "]" );
+ }
+ }
+ partitions = tempPartitions;
+ initialized = true;
+ }
+
+ /**
+ * Loads in the needed configuration settings. System properties are checked first. A
system
+ * property will override local property value.
+ * <p>
+ * Loads the following JCS Cache specific properties:
+ * <ul>
+ * <li>heading.numberOfPartitions</li>
+ * <li>heading.partitionRegionNamePrefix</li>
+ * </ul>
+ * @throws ConfigurationException on configuration problem
+ */
+ protected void handleProperties()
+ throws ConfigurationException
+ {
+ // Number of Partitions.
+ String numberOfPartitionsPropertyName = this.getPropertiesHeading() + ".numberOfPartitions";
+ String numberOfPartitionsPropertyValue = getPropertyForName( numberOfPartitionsPropertyName,
true );
+ try
+ {
+ this.setNumberOfPartitions( Integer.parseInt( numberOfPartitionsPropertyValue
) );
+ }
+ catch ( NumberFormatException e )
+ {
+ String message = "Could not convert [" + numberOfPartitionsPropertyValue + "]
into a number for ["
+ + numberOfPartitionsPropertyName + "]";
+ log.error( message );
+ throw new ConfigurationException( message );
+ }
+
+ // Partition Name Prefix.
+ String prefixPropertyName = this.getPropertiesHeading() + ".partitionRegionNamePrefix";
+ String prefix = getPropertyForName( prefixPropertyName, true );
+ this.setPartitionRegionNamePrefix( prefix );
+ }
+
+ /**
+ * Checks the system properties before the properties.
+ * <p>
+ * @param propertyName name
+ * @param required is it required?
+ * @return the property value if one is found
+ * @throws ConfigurationException thrown if it is required and not found.
+ */
+ protected String getPropertyForName( String propertyName, boolean required )
+ throws ConfigurationException
+ {
+ String propertyValue = null;
+ propertyValue = System.getProperty( propertyName );
+ if ( propertyValue != null )
+ {
+ if ( log.isInfoEnabled() )
+ {
+ log.info( "Found system property override: Name [" + propertyName + "] Value
[" + propertyValue + "]" );
+ }
+ }
+ else
+ {
+ propertyValue = this.getProperties().getProperty( propertyName );
+ if ( required && propertyValue == null )
+ {
+ String message = "Could not find required property [" + propertyName + "]
in propertiesGroup ["
+ + this.getPropertiesGroup() + "]";
+ log.error( message );
+ throw new ConfigurationException( message );
+ }
+ else
+ {
+ if ( log.isInfoEnabled() )
+ {
+ log.info( "Name [" + propertyName + "] Value [" + propertyValue + "]"
);
+ }
+ }
+ }
+ return propertyValue;
+ }
+
+ /**
+ * @param numberOfPartitions The numberOfPartitions to set.
+ */
+ protected void setNumberOfPartitions( int numberOfPartitions )
+ {
+ this.numberOfPartitions = numberOfPartitions;
+ }
+
+ /**
+ * @return Returns the numberOfPartitions.
+ */
+ protected int getNumberOfPartitions()
+ {
+ return numberOfPartitions;
+ }
+
+ /**
+ * @param partitionRegionNamePrefix The partitionRegionNamePrefix to set.
+ */
+ protected void setPartitionRegionNamePrefix( String partitionRegionNamePrefix )
+ {
+ this.partitionRegionNamePrefix = partitionRegionNamePrefix;
+ }
+
+ /**
+ * @return Returns the partitionRegionNamePrefix.
+ */
+ protected String getPartitionRegionNamePrefix()
+ {
+ return partitionRegionNamePrefix;
+ }
+
+ /**
+ * @param partitions The partitions to set.
+ */
+ protected void setPartitions( JCS[] partitions )
+ {
+ this.partitions = partitions;
+ }
+
+ /**
+ * @return Returns the partitions.
+ */
+ protected ICacheAccess[] getPartitions()
+ {
+ return partitions;
+ }
+}
Modified: jakarta/jcs/trunk/src/java/org/apache/jcs/access/behavior/ICacheAccess.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/access/behavior/ICacheAccess.java?rev=803719&r1=803718&r2=803719&view=diff
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/access/behavior/ICacheAccess.java (original)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/access/behavior/ICacheAccess.java Wed Aug 12
21:41:44 2009
@@ -19,7 +19,6 @@
* under the License.
*/
-import java.util.HashMap;
import java.util.Map;
import java.util.Set;
@@ -45,10 +44,10 @@
* Retrieve matching objects from the cache region this instance provides access to.
* <p>
* @param pattern - a key pattern for the objects stored
- * @return A map of key to values. These are stripped from the wrapper.
+ * @return A map of key to values. These are stripped from the wrapper.
*/
- HashMap getMatching( String pattern );
-
+ Map getMatching( String pattern );
+
/**
* Puts in cache if an item does not exist with the name in that region.
* <p>
@@ -112,7 +111,8 @@
* The last access time in the ElementAttributes should be current.
* <p>
* @param names set of Object cache keys
- * @return a map of Object key to ICacheElement element, or empty map if none of the
keys are present
+ * @return a map of Object key to ICacheElement element, or empty map if none of the
keys are
+ * present
*/
Map getCacheElements( Set names );
@@ -131,19 +131,10 @@
* The last access time in the ElementAttributes should be current.
* <p>
* @param pattern key search patern
- * @return a map of Object key to ICacheElement element, or empty map if no keys match
the pattern
+ * @return a map of Object key to ICacheElement element, or empty map if no keys match
the
+ * pattern
*/
Map getMatchingCacheElements( String pattern );
-
- /**
- * Removes an item or all items. Should be called remove.
- * <p>
- * @throws CacheException
- * @deprecated
- * @see #remove()
- */
- void destroy()
- throws CacheException;
/**
* Old remove all method.
@@ -153,17 +144,6 @@
throws CacheException;
/**
- * The older removeall method.
- * <p>
- * @param name
- * @throws CacheException
- * @deprecated
- * @see #remove(Object)
- */
- void destroy( Object name )
- throws CacheException;
-
- /**
* Remove an object for this key if one exists, else do nothing.
* <p>
* @param name
@@ -173,14 +153,13 @@
throws CacheException;
/**
- * ResetAttributes allows for some of the attributes of a region to be reset
- * in particular expiration time attriubtes, time to live, default time to
- * live and idle time, and event handlers. The cacheloader object and
- * attributes set as flags can't be reset with resetAttributes, the object
- * must be destroyed and redefined to cache those parameters. Changing
- * default settings on groups and regions will not affect existing objects.
- * Only object loaded after the reset will use the new defaults. If no name
- * argument is provided, the reset is applied to the region.
+ * ResetAttributes allows for some of the attributes of a region to be reset in particular
+ * expiration time attriubtes, time to live, default time to live and idle time, and
event
+ * handlers. The cacheloader object and attributes set as flags can't be reset with
+ * resetAttributes, the object must be destroyed and redefined to cache those parameters.
+ * Changing default settings on groups and regions will not affect existing objects.
Only object
+ * loaded after the reset will use the new defaults. If no name argument is provided,
the reset
+ * is applied to the region.
* <p>
* @param attributes
* @throws CacheException
@@ -199,10 +178,10 @@
throws CacheException;
/**
- * GetElementAttributes will return an attribute object describing the
- * current attributes associated with the object name. If no name parameter
- * is available, the attributes for the region will be returned. The name
- * object must override the Object.equals and Object.hashCode methods.
+ * GetElementAttributes will return an attribute object describing the current attributes
+ * associated with the object name. If no name parameter is available, the attributes
for the
+ * region will be returned. The name object must override the Object.equals and Object.hashCode
+ * methods.
* <p>
* @return The elementAttributes value
* @throws CacheException
@@ -230,20 +209,18 @@
/**
* Sets the ICompositeCacheAttributes of the cache region
* <p>
- * @param cattr
- * The new ICompositeCacheAttribute value
+ * @param cattr The new ICompositeCacheAttribute value
*/
public void setCacheAttributes( ICompositeCacheAttributes cattr );
/**
- * This instructs the memory cache to remove the <i>numberToFree</i>
- * according to its eviction policy. For example, the LRUMemoryCache will
- * remove the <i>numberToFree</i> least recently used items. These will be
- * spooled to disk if a disk auxiliary is available.
+ * This instructs the memory cache to remove the <i>numberToFree</i> according
to its eviction
+ * policy. For example, the LRUMemoryCache will remove the <i>numberToFree</i>
least recently
+ * used items. These will be spooled to disk if a disk auxiliary is available.
* <p>
* @param numberToFree
- * @return the number that were removed. if you ask to free 5, but there are
- * only 3, you will get 3.
+ * @return the number that were removed. if you ask to free 5, but there are only 3,
you will
+ * get 3.
* @throws CacheException
*/
public int freeMemoryElements( int numberToFree )
Modified: jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/CacheException.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/CacheException.java?rev=803719&r1=803718&r2=803719&view=diff
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/CacheException.java (original)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/CacheException.java Wed Aug
12 21:41:44 2009
@@ -57,5 +57,4 @@
{
super( message );
}
-
}
Added: jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/ConfigurationException.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/ConfigurationException.java?rev=803719&view=auto
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/ConfigurationException.java
(added)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/access/exception/ConfigurationException.java
Wed Aug 12 21:41:44 2009
@@ -0,0 +1,25 @@
+package org.apache.jcs.access.exception;
+
+/** Thrown if there is some severe configuration problem that makes the cache nonfunctional.
*/
+public class ConfigurationException
+ extends CacheException
+{
+ /** Don't change. */
+ private static final long serialVersionUID = 6881044536186097055L;
+
+ /** Constructor for the ConfigurationException object */
+ public ConfigurationException()
+ {
+ super();
+ }
+
+ /**
+ * Constructor for the ConfigurationException object.
+ * <p>
+ * @param message
+ */
+ public ConfigurationException( String message )
+ {
+ super( message );
+ }
+}
Modified: jakarta/jcs/trunk/src/java/org/apache/jcs/engine/match/KeyMatcherPatternImpl.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/engine/match/KeyMatcherPatternImpl.java?rev=803719&r1=803718&r2=803719&view=diff
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/engine/match/KeyMatcherPatternImpl.java (original)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/engine/match/KeyMatcherPatternImpl.java Wed
Aug 12 21:41:44 2009
@@ -28,6 +28,7 @@
for ( int i = 0; i < keyArray.length; i++ )
{
Object key = keyArray[i];
+ // TODO we might want to match on the toString.
if ( key instanceof String )
{
Matcher matcher = compiledPattern.matcher( (String) key );
Added: jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/AbstractPropertyContainer.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/AbstractPropertyContainer.java?rev=803719&view=auto
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/AbstractPropertyContainer.java (added)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/AbstractPropertyContainer.java Wed
Aug 12 21:41:44 2009
@@ -0,0 +1,190 @@
+package org.apache.jcs.utils.props;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Properties;
+
+import org.apache.jcs.access.exception.ConfigurationException;
+
+/**
+ * Provides a mechanism to load properties into objects.
+ * <p>
+ * Functions that depend on properties should call ensureProperties() before it uses any
properties.
+ */
+public abstract class AbstractPropertyContainer
+{
+ /** File, db, etc */
+ private static final PropertiesFactory DEFAULT_PROPERTIES_FACTORY = new PropertiesFactoryFileImpl();
+
+ /**
+ * A property group is a subsection of properties. It's sent to the properties factory
to
+ * specify which group of properties to pull back. This will probably mean different
things to
+ * different property factories. For PropertiesFactoryFileImpl, the propertiesGroup maps
to a
+ * filename.
+ */
+ private String propertiesGroup;
+
+ /**
+ * The property heading is used to specify a starting point in the properties object.
This is
+ * used so that settings can be relative to this propertiesHeading, as opposed to being
+ * statically coded. There's no enforcement of this, but users are encouraged to call
+ * getProperties().get( getPropertiesHeading() + ".foo" );
+ */
+ private String propertiesHeading;
+
+ /** The factory to use. */
+ private PropertiesFactory propertiesFactory;
+
+ /** The loaded properties. */
+ private Properties properties;
+
+ /**
+ * Makes sure an AbstractPropertyClass has all the properties it needs.
+ * <p>
+ * Synchronized mutators so multiple threads cannot cause problems. We wouldn't want
the
+ * properties heading to get changed as we were processing the properties.
+ * <p>
+ * @throws ConfigurationException on configuration failure
+ */
+ public synchronized void ensureProperties()
+ throws ConfigurationException
+ {
+ if ( getProperties() == null )
+ {
+ initializeProperties();
+ }
+ }
+
+ /**
+ * Loads the properties and then calls handleProperties. Typically, you don't need to
call this.
+ * This is primarily intended for reinitialization.
+ * <p>
+ * If the properties object is null, when you call ensureProperties initialize will be
called.
+ * <p>
+ * @throws ConfigurationException on configuration failure
+ */
+ public synchronized void initializeProperties()
+ throws ConfigurationException
+ {
+ loadProperties();
+
+ handleProperties();
+ }
+
+ /**
+ * This loads the properties regardless of whether or not they have already been loaded.
+ * <p>
+ * @throws ConfigurationException on configuration failure
+ */
+ private void loadProperties()
+ throws ConfigurationException
+ {
+ if ( getPropertiesGroup() == null )
+ {
+ throw new ConfigurationException( "Properties group is null and it shouldn't
be" );
+ }
+
+ if ( getPropertiesHeading() == null )
+ {
+ throw new ConfigurationException( "Properties heading is null and it shouldn't
be" );
+ }
+
+ if ( getPropertiesFactory() == null )
+ {
+ setProperties( DEFAULT_PROPERTIES_FACTORY.getProperties( getPropertiesGroup()
) );
+ }
+ else
+ {
+ setProperties( getPropertiesFactory().getProperties( getPropertiesGroup() ) );
+ }
+ }
+
+ /**
+ * Sets fields for properties, and verifies that all necessary properties are there.
+ * <p>
+ * @throws ConfigurationException on configuration failure
+ */
+ protected abstract void handleProperties()
+ throws ConfigurationException;
+
+ /**
+ * @return Returns the properties.
+ */
+ public Properties getProperties()
+ {
+ return properties;
+ }
+
+ /**
+ * @param properties The properties to set.
+ */
+ public synchronized void setProperties( Properties properties )
+ {
+ this.properties = properties;
+ }
+
+ /**
+ * @return Returns the propertiesHeading.
+ */
+ public String getPropertiesHeading()
+ {
+ return propertiesHeading;
+ }
+
+ /**
+ * @param propertiesHeading The propertiesHeading to set.
+ */
+ public synchronized void setPropertiesHeading( String propertiesHeading )
+ {
+ this.propertiesHeading = propertiesHeading;
+ }
+
+ /**
+ * @return Returns the propertiesFactory.
+ */
+ public PropertiesFactory getPropertiesFactory()
+ {
+ return propertiesFactory;
+ }
+
+ /**
+ * @param propertiesFactory The propertiesFactory to set.
+ */
+ public void setPropertiesFactory( PropertiesFactory propertiesFactory )
+ {
+ this.propertiesFactory = propertiesFactory;
+ }
+
+ /**
+ * @return Returns the propertiesGroup.
+ */
+ public String getPropertiesGroup()
+ {
+ return propertiesGroup;
+ }
+
+ /**
+ * @param propertiesGroup The propertiesGroup to set.
+ */
+ public void setPropertiesGroup( String propertiesGroup )
+ {
+ this.propertiesGroup = propertiesGroup;
+ }
+}
Added: jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactory.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactory.java?rev=803719&view=auto
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactory.java (added)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactory.java Wed Aug 12
21:41:44 2009
@@ -0,0 +1,36 @@
+package org.apache.jcs.utils.props;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Properties;
+
+/**
+ * Retrieves properties from a configurable source.
+ */
+public interface PropertiesFactory
+{
+ /**
+ * Fetches a set of properties for the specified group.
+ * <p>
+ * @param groupName the group to pull properties from.
+ * @return a properties object.
+ */
+ Properties getProperties( String groupName );
+}
Added: jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactoryFileImpl.java
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactoryFileImpl.java?rev=803719&view=auto
==============================================================================
--- jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactoryFileImpl.java (added)
+++ jakarta/jcs/trunk/src/java/org/apache/jcs/utils/props/PropertiesFactoryFileImpl.java Wed
Aug 12 21:41:44 2009
@@ -0,0 +1,39 @@
+package org.apache.jcs.utils.props;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Properties;
+
+/**
+ * Goes to the file system to load a properties file.
+ */
+public class PropertiesFactoryFileImpl
+ implements PropertiesFactory
+{
+ /**
+ * Loads the properties using the property loader.
+ * @param groupName property group name
+ * @return Properties
+ */
+ public Properties getProperties( String groupName )
+ {
+ return PropertyLoader.loadProperties( groupName );
+ }
+}
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Author: asmuts
Date: Wed Aug 12 14:39:19 2009
New Revision: 803539
URL: http://svn.apache.org/viewvc?rev=803539&view=rev
Log:
Fixed bug (JCS-67) in the indexed disk cache. Partial key removal was adding duplicates in
the recycle bin. This lead to the multiple keys pointing to the same spot on disk.
Added:
jakarta/jcs/tempbuilds/jcs-1.3.3.5-RC.jar (with props)
Added: jakarta/jcs/tempbuilds/jcs-1.3.3.5-RC.jar
URL: http://svn.apache.org/viewvc/jakarta/jcs/tempbuilds/jcs-1.3.3.5-RC.jar?rev=803539&view=auto
==============================================================================
Binary file - no diff available.
Propchange: jakarta/jcs/tempbuilds/jcs-1.3.3.5-RC.jar
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Author: asmuts
Date: Wed Aug 12 14:37:58 2009
New Revision: 803538
URL: http://svn.apache.org/viewvc?rev=803538&view=rev
Log:
Fixed indexed disk cache problem where the partial key removal would add dupes to the recylebin.
Added:
jakarta/jcs/tags/JCS_1_3_3_5/
- copied from r803537, jakarta/jcs/trunk/
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
Author: asmuts
Date: Wed Aug 12 14:37:04 2009
New Revision: 803536
URL: http://svn.apache.org/viewvc?rev=803536&view=rev
Log:
Increasing version for tag and tempbuild.
Modified:
jakarta/jcs/trunk/pom.xml
jakarta/jcs/trunk/project.xml
Modified: jakarta/jcs/trunk/pom.xml
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/pom.xml?rev=803536&r1=803535&r2=803536&view=diff
==============================================================================
--- jakarta/jcs/trunk/pom.xml (original)
+++ jakarta/jcs/trunk/pom.xml Wed Aug 12 14:37:04 2009
@@ -36,7 +36,7 @@
<groupId>org.apache.jcs</groupId>
<artifactId>jcs</artifactId>
<packaging>pom</packaging>
- <version>1.3.3.4-RC</version>
+ <version>1.3.3.5-RC</version>
<name>Jakarta JCS</name>
<url>http://jakarta.apache.org/jcs/</url>
<inceptionYear>2002</inceptionYear>
Modified: jakarta/jcs/trunk/project.xml
URL: http://svn.apache.org/viewvc/jakarta/jcs/trunk/project.xml?rev=803536&r1=803535&r2=803536&view=diff
==============================================================================
--- jakarta/jcs/trunk/project.xml (original)
+++ jakarta/jcs/trunk/project.xml Wed Aug 12 14:37:04 2009
@@ -17,7 +17,7 @@
<pomVersion>3</pomVersion>
<name>JCS</name>
<id>jcs</id>
- <currentVersion>1.3.3.4-RC</currentVersion>
+ <currentVersion>1.3.3.5-RC</currentVersion>
<organization>
<name>Apache Software Foundation</name>
<url>http://jakarta.apache.org/</url>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org