airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Nakandala <>
Subject Re: PGA Cache and AJAX/PHP
Date Thu, 18 Jun 2015 11:07:52 GMT

Now you can disable app-catalog data caching in the pga-config.php


On Thu, Jun 18, 2015 at 4:31 PM, Supun Nakandala <>

> 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 <>
> 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" <> 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:
>>> 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

View raw message