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
