Ahh, yes that makes a lot more sense because the caches seemed very selective. Thank you! On Jun 18, 2015 7:08 AM, "Supun Nakandala" <[email protected]> wrote:
> Hi, > > Now you can disable app-catalog data caching in the pga-config.php > > Thanks > > On Thu, Jun 18, 2015 at 4:31 PM, Supun Nakandala < > [email protected]> wrote: > >> Hi, >> >> In PGA pages are not cached. Only ComputerResource and >> ApplicationInterface entities are cached. I decided to cache those data in >> order to improve the performance PGA. When we retrieve experiment data we >> get only the resource host id and application id s. We don't get the names >> of them which are required in the UI. So this ends up creating multiple API >> calls to back end to resolve the names. This becomes problematic in showing >> search and browse results as it takes a long time. >> >> Currently it is not possible to disable caching but you can reduce the >> cache invalidation time in pga_config.php. I will change the code such >> that it is possible to disable caching. >> >> Sorry if this caused you trouble >> >> Supun >> >> On Thu, Jun 18, 2015 at 1:01 PM, John Weachock <[email protected]> >> wrote: >> >>> I was running into a lot of issues recently with the PGA returning >>> cached copies of pages. Is there any way to disable the cache for >>> development or shorten the time-to-live for cached pages? >>> >>> Thanks! >>> On Jun 17, 2015 3:19 PM, "Douglas Chau" <[email protected]> wrote: >>> >>>> Hello Devs, >>>> >>>> Nothing that requires immediate attention, but I thought I would >>>> document some of my hurdles while working on adding a feature to the PGA in >>>> case anyone else encounters similar issues. So there are two takeaways: be >>>> wary of PGA caching results, and be careful of boolean variables passed >>>> through AJAX being treated as strings in PHP. >>>> >>>> I was working on the admin interface that allows a gateway admin to >>>> turn on/off the visibility of a resource to regular users. The page before >>>> was only a dummy page with a bunch of buttons for each resource. I added >>>> some AJAX functionality to the current buttons so that when one is switched >>>> on/off a call is made to a PHP controller method that resides in >>>> AdminController.php; that call then invokes a utility function within >>>> CRUtilities.php which does the actual calling to the the Airavata API to >>>> update the compute resource description with the new boolean value that >>>> reflects the button's on/off state. So basically, the button just updates a >>>> boolean field in the compute resource description. Sounds simple enough. >>>> >>>> To make sure everything was working, I wrote some sanity checks to >>>> print the before and after states of the compute resource description to >>>> the browser (using javascript's console.log() function). For the record, I >>>> used the *CRUtilities::register_or_update_compute_resource *method to >>>> do the actual updating of the compute resource and then the >>>> *CRUtilities::get_compute_resource* method to check the results. So >>>> strangely and surely, when I got the results back and printed them to the >>>> screen, the changes were not reflected; the compute resource object’s >>>> fields were completely unchanged. But, the even stranger thing was that >>>> after periods of time, the object fields would change. Huh?... This lead me >>>> on a wild goose chase to see if there was something I forgot in the >>>> airavata backend code, or if there was some composer command I forgot to >>>> call, and so on. I looked through the CRUtilities code more carefully and >>>> found that the *CRUtilities::**register_or_update_compute_resource* method >>>> actually returns the compute resource when it succeeds. I tried printing >>>> this return value to the screen and discovered that the changes were >>>> happily reflected in these results but still not in the results of the >>>> other *CRUtilities::get_compute_resource *method. Why? With some more >>>> stumbling around, I discovered that the >>>> *CRUtilities::register_or_update_compute_resource* method actually >>>> gets it’s resulting resource description by calling the >>>> *Airavata::getComputeResource* method and not the getter method >>>> already provided in CRUtilities; so the succeeding results actually come >>>> directly from the airavata backend. And finally, after looking carefully at >>>> the *CRUtilities::get_compute_resource* method, I found that this >>>> method actually returns a cached version of the resource if available, >>>> which explains why none of the changes were immediately reflected but did >>>> after a period of time. >>>> >>>> If you did not follow all that, the takeaway is, >>>> *CRUtilities::get_compute_resource* returns a cached version of the >>>> resource, so if you ever make an update and are trying to check the results >>>> to see if they have changed, use the return value of the >>>> *CRUtilities::**register_or_update_compute_resource *instead; the >>>> results of *CRUtilities::get_compute_resource* will deceive you into >>>> thinking the change did not go through. I guess that makes sense, but may >>>> not be so apparent to newcomers to the PGA code. >>>> >>>> Also, if any of you ever try passing boolean values from AJAX to PHP, >>>> when PHP get’s the POST/GET results, it will take your original boolean >>>> types and covert them to strings. So if you passed in boolean true, PHP >>>> will get it as string “true”. And of course, if you are eventually setting >>>> a boolean field to the string “true”, PHP always evaluates a string to >>>> boolean true unless it is something that is considered empty by PHP (i.e. >>>> “” or “0”). So if you need to do this, make sure the values are converted >>>> back to boolean. See these links for more detail: >>>> >>>> http://stackoverflow.com/questions/3654454/boolean-variables-posted-through-ajax-being-treated-as-strings-in-server-side >>>> >>>> http://stackoverflow.com/questions/7336861/how-to-convert-string-to-boolean-php >>>> >>>> I hope this was all somewhat clear. And at the least, I hope this helps >>>> anyone who may eventually work on the PGA code. >>>> >>>> Thanks, >>>> Doug >>>> >>>> >> >> >> -- >> Thank you >> Supun Nakandala >> Dept. Computer Science and Engineering >> University of Moratuwa >> > > > > -- > Thank you > Supun Nakandala > Dept. Computer Science and Engineering > University of Moratuwa >
