Wouldn't it be a valid scenario to change the cache expiry time as in my case? As you've said, I understand that we cannot expect every new version of the app to have cache configuration changes. But during testing or initial development i think it could happen. Even in that case this is not a blocking issue i think. I just want to understand how we should work with that. :)
On Wed, Oct 29, 2014 at 6:48 PM, Afkham Azeez <[email protected]> wrote: > It doesn't happen like that in practice. The developer suddenly doesn't > change the mind and change the cache configuration on the fly. These > parameters are fixed, and will be set upon cache creation. > > On Wed, Oct 29, 2014 at 6:15 AM, Gayashan Amarasinghe <[email protected]> > wrote: > >> Thanks Azeez. Understood. However in case the developer wanted to change >> the cache configuration of an existing cache what is the recommended >> approach? Only possible way would be to make the cache have a different >> name? >> >> On Wed, Oct 29, 2014 at 6:37 PM, Afkham Azeez <[email protected]> wrote: >> >>> You cannot call the builder twice when the cache already exists. Other >>> teams such as IS use both the getCache & the builder method with proper >>> synchronization which will return the cache if it exists, or will build & >>> return the cache with custom parameter if it does not exist. I will try to >>> write a sample code segment and publish on my blog today. That can be made >>> into a class called CachingUtil or something. >>> >>> Azeez >>> >>> On Wed, Oct 29, 2014 at 5:59 AM, Gayashan Amarasinghe <[email protected] >>> > wrote: >>> >>>> Hi Azeez, >>>> >>>> During Carbon testing i've created a simple web app that utilize the >>>> cache (source code at [1]). In this web app I've created a cache with >>>> custom expiry and deployed it in a cluster and hit it using jmeter. During >>>> testing i changed the expiry time of the cache prorgrammatically and tried >>>> to redeploy the web app. But since the server was not restarted the cache >>>> created by the previous web app was already there. (I didn't change the >>>> name of the cache manager or the cache) As a result the following exception >>>> was thrown. >>>> >>>> TID: [-1234] [] [2014-10-29 12:27:57,185] ERROR >>>> {org.apache.catalina.core.StandardWrapperValve} - Allocate exception for >>>> servlet org.wso2.carbon.CarbonTest.CachingTest >>>> {org.apache.catalina.core.StandardWrapperValve} >>>> javax.cache.CacheException: Cache expiringCache already exists >>>> at >>>> org.wso2.carbon.caching.impl.CarbonCacheManager.createCacheBuilder(CarbonCacheManager.java:96) >>>> at org.wso2.carbon.CarbonTest.CachingTest.init(CachingTest.java:38) >>>> at javax.servlet.GenericServlet.init(GenericServlet.java:158) >>>> at >>>> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1279) >>>> at >>>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1192) >>>> at >>>> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:864) >>>> at >>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:134) >>>> at >>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) >>>> at >>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) >>>> at >>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) >>>> at >>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) >>>> at >>>> org.wso2.carbon.statistics.webapp.RequestIntercepterValve.invoke(RequestIntercepterValve.java:43) >>>> at >>>> org.wso2.carbon.bam.webapp.stat.publisher.WebAppStatisticPublisherValve.invoke(WebAppStatisticPublisherValve.java:104) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.CarbonTomcatValve$1.invoke(CarbonTomcatValve.java:47) >>>> at >>>> org.wso2.carbon.webapp.mgt.GhostWebappDeployerValve.invoke(GhostWebappDeployerValve.java:141) >>>> at >>>> org.wso2.carbon.webapp.mgt.TenantLazyLoaderValve.invoke(TenantLazyLoaderValve.java:56) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:47) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:141) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:154) >>>> at >>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) >>>> at >>>> org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:52) >>>> at >>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) >>>> at >>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >>>> at >>>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) >>>> at >>>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) >>>> at >>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1721) >>>> at >>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1679) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) >>>> at java.lang.Thread.run(Thread.java:662) >>>> >>>> >>>> This is going to be an issue when developers try to redeploy a webapp >>>> with modifications to the cache configurations. Is this a bug or the >>>> intended behavior? AFAIU we should not let this happen. WDYT? >>>> >>>> [1] >>>> https://github.com/GayashanNA/CarbonCachingTestWebapp/blob/master/src/main/java/org/wso2/carbon/CarbonTest/CachingTest.java >>>> >>>> ​Thanks. >>>> /Gayashan​ >>>> >>>> -- >>>> *Gayashan Amarasinghe* >>>> Software Engineer | Platform TG >>>> WSO2, Inc. | http://wso2.com >>>> lean. enterprise. middleware >>>> >>>> Mobile : +94718314517 >>>> Blog : gayashan-a.blogspot.com >>>> >>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **[email protected]* <[email protected]> >>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: **http://twitter.com/afkham_azeez* >>> <http://twitter.com/afkham_azeez> >>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >> >> >> >> -- >> *Gayashan Amarasinghe* >> Software Engineer | Platform TG >> WSO2, Inc. | http://wso2.com >> lean. enterprise. middleware >> >> Mobile : +94718314517 >> Blog : gayashan-a.blogspot.com >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- *Gayashan Amarasinghe* Software Engineer | Platform TG WSO2, Inc. | http://wso2.com lean. enterprise. middleware Mobile : +94718314517 Blog : gayashan-a.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
