airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Nakandala <supun.nakand...@gmail.com>
Subject Re: PGA Cache and AJAX/PHP
Date Thu, 18 Jun 2015 11:01:50 GMT
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 <jweachock@gmail.com> 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" <dchau3@binghamton.edu> 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

Mime
View raw message