
|
If you were logged in you would be able to see more operations.
|
|
|
OSCache
Created: 19/Dec/05 04:05 PM
Updated: 03/Dec/06 04:31 AM
|
|
| Component/s: |
Filters
|
| Affects Version/s: |
2.2 final
|
| Fix Version/s: |
2.3
|
|
|
Environment:
|
MS Windows 2000 SP4, Apache Tomcat 5.5.12 /w JDK 5.0 on Intel PIV D /w 1 GB DDR RAM.
|
|
|
OSCache 2.0 gave us the ability to expire content at specific dates and/or times based on a cron expression specified in the "cron" attribute of "<oscache:" JSP custom tag. However, this feature was never implemented as part of the whole OSCache solution and a "cron" initialization parameter and regular CRON-inspired scheduling functionality is therefore lacking from the "CacheFilter" class. This means that cached HTTP responses only get refreshed x seconds after the JSP has been initially requested by a user. This in turn causes all of the JSPs (potentially displaying information displayed in whole or in part by other JSPs) to be out of sync: some displaying newer data than others simply because they were requested by a user later than others. The entire application suffers and an illusion of data incoherence is vehiculated to all the end users.
To remedy this problem, I propose that the CRON-inspired scheduling functionality added to the OSCache custom tags in OSCache 2.0 be also added to the CacheFilter class in the next major release of OSCache.
Disk caching of HTTP responses can dramatically speed up a web application that displays regularly updated information by avoiding unnecessary CPU cycles and RAM usage caused by the processing, in whole or in part, of JSPs. The J2EE server thus behaves more like a classic HTTP server than a J2EE server in certain cases, depening on the URL patterns fed to the CacheFilter class.
Thanks && keep up the great work!
|
|
Description
|
OSCache 2.0 gave us the ability to expire content at specific dates and/or times based on a cron expression specified in the "cron" attribute of "<oscache:" JSP custom tag. However, this feature was never implemented as part of the whole OSCache solution and a "cron" initialization parameter and regular CRON-inspired scheduling functionality is therefore lacking from the "CacheFilter" class. This means that cached HTTP responses only get refreshed x seconds after the JSP has been initially requested by a user. This in turn causes all of the JSPs (potentially displaying information displayed in whole or in part by other JSPs) to be out of sync: some displaying newer data than others simply because they were requested by a user later than others. The entire application suffers and an illusion of data incoherence is vehiculated to all the end users.
To remedy this problem, I propose that the CRON-inspired scheduling functionality added to the OSCache custom tags in OSCache 2.0 be also added to the CacheFilter class in the next major release of OSCache.
Disk caching of HTTP responses can dramatically speed up a web application that displays regularly updated information by avoiding unnecessary CPU cycles and RAM usage caused by the processing, in whole or in part, of JSPs. The J2EE server thus behaves more like a classic HTTP server than a J2EE server in certain cases, depening on the URL patterns fed to the CacheFilter class.
Thanks && keep up the great work! |
Show » |
|