You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by arnout cator <ar...@gmail.com> on 2015/03/10 23:12:43 UTC

can # sometimes be ignored by JCS

Hi, I have the situation that I have 10+ web apps using JCS. I have this in
cache.ccf:

 ###################################################################
# Stylesheet settings
###################################################################
#disable disk caching if WAS doesn't provide serialized dom
#jcs.region.stylesheet=
jcs.region.stylesheet=DC
jcs.region.stylesheet.cacheattributes.MaxObjects=128
###################################################################

I have no issues with all other regions defined, but I have a problem that
sometimes amongst the 10 web apps, not consistently the same web apps, the
stylesheet cache is not invalidated when I do a code release to the 10
apps. I get over it by removing all disk cache files and restarting the app
server.

I wondered if it is possible that JCS sometimes reads the # line. Can that
be causing this?
If not, why would just the stylesheet disk cache file not be invalidated
sometimes? Did anyone in JCS user world see a similar event?

Re: can # sometimes be ignored by JCS

Posted by arnout cator <ar...@gmail.com>.
sorry, i showed a Spring bean configuration variable. This Spring bean
works with a jar deployed in WebLogic to render a folder custom for each
web application. This obviously is not a cache.ccf configuration item.
I think I feel that the problem has more to do with multiple JCS instances
in multiple nodes invalidating the same cache folder due to some issue in
the product that deploys and runs the JCS.



On Thu, Mar 19, 2015 at 9:59 PM, arnout cator <ar...@gmail.com>
wrote:

> Hi, thanks a lot for taking some time to look at my problem. I have set up
> a reproduction environment for my customer's production installation.
>
> I have done some deploying and thinking and I think this is what I believe
> might help understand a bit more what is going on:
>
> The customer has BEA Weblogic and they have multiple instances of the
> site. In cache.ccf they have a weblogic variable set in the invalidation
> monitor path:
>
>   <!-- invalidation monitor -->
>   <bean id="runtime.cache.InvalidationFileDirectory"
>         factory-bean="util.ContentResourceFactory"
>         factory-method="getFile">
>     <constructor-arg><value>/sites/${atg.dynamo.server.name
> }</value></constructor-arg>
>   </bean>
>
> Now, what I believe is the case is that the problem only occurs when the
> pages are in auxiliary disk. Then when the customer has a code release,
> then they restart BEA when updating the application where JCS is sitting.
> Then they experience the issue that the cached object is not deleted from
> disk from various but not all weblogic managed servers (web applications).
> So, my question then is: is this variable then not read in some cases at
> random?
>
> This is what the customer's deployment manager said:
>
> *Additional information:  *When it fails the deployment contains an EAR
> file and the Shared Libraries that are started in the WebLogic instance are
> getting a new jar file pushed to the server.  WebLogic is using this as a
> shared library on start up.  After this happens we push content into the
> web application.  Sometimes the content shows up and sometimes it does not.
>
> * Happens 5 or 6 times over last 3 months
>
> * More frequently seeing issues where it caused a problem
>
> * Appears the cache file is not being invalidated automatically.
>
> * We push to a preview environment and works fine, then push to Production
> and it fails AND we've seen push to the preview environment fail but push
> to Production works just fine.  Unable to identify why unless it's a timing
> issue we're not aware of or maybe a process is not being done?
>
>
>
>
> On Fri, Mar 13, 2015 at 7:04 AM, Thomas Vandahl <tv...@apache.org> wrote:
>
>> On 10.03.15 23:12, arnout cator wrote:
>> > Hi, I have the situation that I have 10+ web apps using JCS. I have
>> this in
>> > cache.ccf:
>> >
>> >  ###################################################################
>> > # Stylesheet settings
>> > ###################################################################
>> > #disable disk caching if WAS doesn't provide serialized dom
>> > #jcs.region.stylesheet=
>> > jcs.region.stylesheet=DC
>> > jcs.region.stylesheet.cacheattributes.MaxObjects=128
>> > ###################################################################
>> >
>> > I have no issues with all other regions defined, but I have a problem
>> that
>> > sometimes amongst the 10 web apps, not consistently the same web apps,
>> the
>> > stylesheet cache is not invalidated when I do a code release to the 10
>> > apps. I get over it by removing all disk cache files and restarting the
>> app
>> > server.
>> >
>> > I wondered if it is possible that JCS sometimes reads the # line. Can
>> that
>> > be causing this?
>>
>> This is very unlikely because JCS uses the standard JDK methods to read
>> its configuration files.
>>
>> > If not, why would just the stylesheet disk cache file not be invalidated
>> > sometimes? Did anyone in JCS user world see a similar event?
>>
>> I'm not sure I understand your environment correctly. Do you generally
>> expect the cache contents to survive an application restart or not?
>>
>> The disk cache will persist keys and data during an orderly shutdown so
>> that they can be reloaded on restart. This normally requires
>> JCSServletContextListener to be present in the web application. However
>> JCS also registers a shutdown hook to the JVM which may or may not work
>> in an app-server environment. This would explain the inconsistent
>> behavior you are experiencing.
>>
>> Bye, Thomas.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>

Re: can # sometimes be ignored by JCS

Posted by arnout cator <ar...@gmail.com>.
Hi, thanks a lot for taking some time to look at my problem. I have set up
a reproduction environment for my customer's production installation.

I have done some deploying and thinking and I think this is what I believe
might help understand a bit more what is going on:

The customer has BEA Weblogic and they have multiple instances of the site.
In cache.ccf they have a weblogic variable set in the invalidation monitor
path:

  <!-- invalidation monitor -->
  <bean id="runtime.cache.InvalidationFileDirectory"
        factory-bean="util.ContentResourceFactory"
        factory-method="getFile">
    <constructor-arg><value>/sites/${atg.dynamo.server.name
}</value></constructor-arg>
  </bean>

Now, what I believe is the case is that the problem only occurs when the
pages are in auxiliary disk. Then when the customer has a code release,
then they restart BEA when updating the application where JCS is sitting.
Then they experience the issue that the cached object is not deleted from
disk from various but not all weblogic managed servers (web applications).
So, my question then is: is this variable then not read in some cases at
random?

This is what the customer's deployment manager said:

*Additional information:  *When it fails the deployment contains an EAR
file and the Shared Libraries that are started in the WebLogic instance are
getting a new jar file pushed to the server.  WebLogic is using this as a
shared library on start up.  After this happens we push content into the
web application.  Sometimes the content shows up and sometimes it does not.

* Happens 5 or 6 times over last 3 months

* More frequently seeing issues where it caused a problem

* Appears the cache file is not being invalidated automatically.

* We push to a preview environment and works fine, then push to Production
and it fails AND we've seen push to the preview environment fail but push
to Production works just fine.  Unable to identify why unless it's a timing
issue we're not aware of or maybe a process is not being done?




On Fri, Mar 13, 2015 at 7:04 AM, Thomas Vandahl <tv...@apache.org> wrote:

> On 10.03.15 23:12, arnout cator wrote:
> > Hi, I have the situation that I have 10+ web apps using JCS. I have this
> in
> > cache.ccf:
> >
> >  ###################################################################
> > # Stylesheet settings
> > ###################################################################
> > #disable disk caching if WAS doesn't provide serialized dom
> > #jcs.region.stylesheet=
> > jcs.region.stylesheet=DC
> > jcs.region.stylesheet.cacheattributes.MaxObjects=128
> > ###################################################################
> >
> > I have no issues with all other regions defined, but I have a problem
> that
> > sometimes amongst the 10 web apps, not consistently the same web apps,
> the
> > stylesheet cache is not invalidated when I do a code release to the 10
> > apps. I get over it by removing all disk cache files and restarting the
> app
> > server.
> >
> > I wondered if it is possible that JCS sometimes reads the # line. Can
> that
> > be causing this?
>
> This is very unlikely because JCS uses the standard JDK methods to read
> its configuration files.
>
> > If not, why would just the stylesheet disk cache file not be invalidated
> > sometimes? Did anyone in JCS user world see a similar event?
>
> I'm not sure I understand your environment correctly. Do you generally
> expect the cache contents to survive an application restart or not?
>
> The disk cache will persist keys and data during an orderly shutdown so
> that they can be reloaded on restart. This normally requires
> JCSServletContextListener to be present in the web application. However
> JCS also registers a shutdown hook to the JVM which may or may not work
> in an app-server environment. This would explain the inconsistent
> behavior you are experiencing.
>
> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

Re: can # sometimes be ignored by JCS

Posted by Thomas Vandahl <tv...@apache.org>.
On 10.03.15 23:12, arnout cator wrote:
> Hi, I have the situation that I have 10+ web apps using JCS. I have this in
> cache.ccf:
> 
>  ###################################################################
> # Stylesheet settings
> ###################################################################
> #disable disk caching if WAS doesn't provide serialized dom
> #jcs.region.stylesheet=
> jcs.region.stylesheet=DC
> jcs.region.stylesheet.cacheattributes.MaxObjects=128
> ###################################################################
> 
> I have no issues with all other regions defined, but I have a problem that
> sometimes amongst the 10 web apps, not consistently the same web apps, the
> stylesheet cache is not invalidated when I do a code release to the 10
> apps. I get over it by removing all disk cache files and restarting the app
> server.
> 
> I wondered if it is possible that JCS sometimes reads the # line. Can that
> be causing this?

This is very unlikely because JCS uses the standard JDK methods to read
its configuration files.

> If not, why would just the stylesheet disk cache file not be invalidated
> sometimes? Did anyone in JCS user world see a similar event?

I'm not sure I understand your environment correctly. Do you generally
expect the cache contents to survive an application restart or not?

The disk cache will persist keys and data during an orderly shutdown so
that they can be reloaded on restart. This normally requires
JCSServletContextListener to be present in the web application. However
JCS also registers a shutdown hook to the JVM which may or may not work
in an app-server environment. This would explain the inconsistent
behavior you are experiencing.

Bye, Thomas.



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org