commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From arnout cator <arnout.ca...@gmail.com>
Subject Re: can # sometimes be ignored by JCS
Date Thu, 19 Mar 2015 21:59:25 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message