Re: [GSoC] Midterm Evaluation and Weekly Hangout

[Suresh Marru]

Hi John,

Lets go with your update first that way you can be done before 9.30 am. We can 
only do a update for tomorrow and I am sure demos will require more time to 
plan, so lets shoot them for next week.

Suresh
> On Jun 18, 2015, at 3:22 PM, John Weachock  wrote:
> 
> Approximately how long will the hangout last? Unfortunately, I wasn't aware 
> we'd be scheduling a meeting tomorrow, so I may need to leave early to pick 
> my mother up from a doctor's appointment. I expect her to be ready around 
> 9:30am EST.
> 
> Should we just have our midterm prepared for tomorrow, or should we try to 
> prepare a demo as well?
> 
> Thanks!
> 
> On Jun 18, 2015 1:42 PM, "Suresh Marru"  > wrote:
> GSoC Students,
> 
> You might have received email from google about GSoC mid-term evaluations due 
> to be filled starting next friday. In preparation for this, please update or 
> write your status util now and plans for remaining half of the duration on 
> the Wiki. Please clearly indicate your accomplishments as well us 
> understanding of your project so far and write in convincing terms how you 
> plan to finish up.
> 
> Lets have our weekly hangout tomorrow (Friday) at 9 am eastern (6.30pm IST) 
> and review these. I think it will be better during next week if we schedule 
> demos of your work so far.
> 
> Please keep sending any technical impediments to the dev list so they can be 
> resolved sooner than weekly meetings. But if anything will need longer 
> discussion, we can certainly talk after the mid-term updates.
> 
> Cheers,
> Suresh

Re: PGA JavaScript and CSS

[Douglas Chau]

Thanks!
On Jun 18, 2015 3:58 PM, "Supun Nakandala" 
wrote:

> Yes, You can find sample imports in here
> https://github.com/apache/airavata-php-gateway/blob/master/app/views/experiment/search.blade.php#L117
>
> On Fri, Jun 19, 2015 at 1:26 AM, Douglas Chau 
> wrote:
>
>> Hey Supun,
>>
>> Is the laravel syntax the parts of code that say:
>> @section (‘scripts’)
>> @parent
>> @stop
>>
>> Could you give me a quick example of how I would reference a newly added
>> "test.js" file into the assets?
>>
>> Doug
>>
>>
>> On Jun 18, 2015, at 3:46 PM, Supun Nakandala 
>> wrote:
>>
>> Hi Douglas,
>>
>> JS and CSS files should be put in the following folder
>> https://github.com/apache/airavata-php-gateway/tree/master/public and
>> they should explicitly imported in the view files using laravel syntax.
>>
>> Thanks
>> Supun
>>
>> On Fri, Jun 19, 2015 at 1:14 AM, Douglas Chau 
>> wrote:
>>
>>> Hey Devs,
>>>
>>> Can anyone point me to where the JavaScript and CSS files are supposed
>>> to go?
>>>
>>> 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
>

Re: PGA JavaScript and CSS

[Supun Nakandala]

Yes, You can find sample imports in here
https://github.com/apache/airavata-php-gateway/blob/master/app/views/experiment/search.blade.php#L117

On Fri, Jun 19, 2015 at 1:26 AM, Douglas Chau  wrote:

> Hey Supun,
>
> Is the laravel syntax the parts of code that say:
> @section (‘scripts’)
> @parent
> @stop
>
> Could you give me a quick example of how I would reference a newly added
> "test.js" file into the assets?
>
> Doug
>
>
> On Jun 18, 2015, at 3:46 PM, Supun Nakandala 
> wrote:
>
> Hi Douglas,
>
> JS and CSS files should be put in the following folder
> https://github.com/apache/airavata-php-gateway/tree/master/public and
> they should explicitly imported in the view files using laravel syntax.
>
> Thanks
> Supun
>
> On Fri, Jun 19, 2015 at 1:14 AM, Douglas Chau 
> wrote:
>
>> Hey Devs,
>>
>> Can anyone point me to where the JavaScript and CSS files are supposed to
>> go?
>>
>> 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

Re: Docker - airavata PGA is available!!

[Pierce, Marlon]

Great!  Please try it out, everyone.

From: Pankaj Saha mailto:psa...@binghamton.edu>>
Reply-To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Date: Thursday, June 18, 2015 at 3:50 PM
To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Subject: Docker - airavata PGA is available!!

Hello Developers,

Docker airavata PGA is available!!

I have published one docker image for airavata PGA at the following public 
repository.

Airavata_pga

please pull the image and run containers to check if pga is working in your 
environment.


This docker image in based on Ubuntu and Apache Airavata PGA 0.15 branch
How to pull this image:

docker pull psaha4/airavata_pga

Note: This is a public image repository so no credentials will be required

How to build a running container:

To build a container and run it use the below docker command

docker run -p 127.0.0.1::80 -i -t  
/bin/bash

Note:

HOST_PORT(Ex: 8585) is where host system want to listen the PGA service. Inside 
container its running at port 80, but after running the container host system 
can use the delivered HOST_PORT

To check IMAGE_ID, use command “ docker images”

This will list all available images with image id and repository name.

How to test the container:

If running container was successful then host system can access the Airavata 
PGA service in the desired HOST_PORT. lets consider HOST_PORT is 8585 here,now 
open any browser window and type

http://localhost:8585/airavata-php-gateway/public/

You should be able to see the gateway interface.


Thanks
Pankaj

Re: PGA JavaScript and CSS

[Douglas Chau]

Hey Supun,

Is the laravel syntax the parts of code that say:
@section (‘scripts’)
@parent
@stop

Could you give me a quick example of how I would reference a newly added 
"test.js" file into the assets?

Doug


> On Jun 18, 2015, at 3:46 PM, Supun Nakandala  
> wrote:
> 
> Hi Douglas,
> 
> JS and CSS files should be put in the following folder 
> https://github.com/apache/airavata-php-gateway/tree/master/public 
>  and they 
> should explicitly imported in the view files using laravel syntax.
> 
> Thanks
> Supun
> 
> On Fri, Jun 19, 2015 at 1:14 AM, Douglas Chau  > wrote:
> Hey Devs,
> 
> Can anyone point me to where the JavaScript and CSS files are supposed to go?
> 
> Thanks,
> Doug
> 
> 
> 
> -- 
> Thank you
> Supun Nakandala
> Dept. Computer Science and Engineering
> University of Moratuwa

Docker - airavata PGA is available!!

[Pankaj Saha]

Hello Developers,

Docker airavata PGA is available!!

I have published one docker image for airavata PGA at the following public
repository.

Airavata_pga 

please pull the image and run containers to check if pga is working in your
environment.


This docker image in based on Ubuntu and Apache Airavata PGA 0.15 branch
How to pull this image:

docker pull psaha4/airavata_pga

Note: This is a public image repository so no credentials will be required
How to build a running container:

To build a container and run it use the below docker command

docker run -p 127.0.0.1::80 -i -t  /bin/bash

Note:

HOST_PORT(Ex: 8585) is where host system want to listen the PGA service.
Inside container its running at port 80, but after running the container
host system can use the delivered HOST_PORT

To check IMAGE_ID, use command “ docker images”

This will list all available images with image id and repository name.
How to test the container:

If running container was successful then host system can access the
Airavata PGA service in the desired HOST_PORT. lets consider HOST_PORT is
8585 here,now open any browser window and type

http://localhost:8585/airavata-php-gateway/public/

You should be able to see the gateway interface.


Thanks
Pankaj

Re: PGA JavaScript and CSS

[Supun Nakandala]

Hi Douglas,

JS and CSS files should be put in the following folder
https://github.com/apache/airavata-php-gateway/tree/master/public and they
should explicitly imported in the view files using laravel syntax.

Thanks
Supun

On Fri, Jun 19, 2015 at 1:14 AM, Douglas Chau  wrote:

> Hey Devs,
>
> Can anyone point me to where the JavaScript and CSS files are supposed to
> go?
>
> Thanks,
> Doug




-- 
Thank you
Supun Nakandala
Dept. Computer Science and Engineering
University of Moratuwa

PGA JavaScript and CSS

[Douglas Chau]

Hey Devs,

Can anyone point me to where the JavaScript and CSS files are supposed to go? 

Thanks,
Doug

Re: [GSoC] Midterm Evaluation and Weekly Hangout

[John Weachock]

Approximately how long will the hangout last? Unfortunately, I wasn't aware
we'd be scheduling a meeting tomorrow, so I may need to leave early to pick
my mother up from a doctor's appointment. I expect her to be ready around
9:30am EST.

Should we just have our midterm prepared for tomorrow, or should we try to
prepare a demo as well?

Thanks!
On Jun 18, 2015 1:42 PM, "Suresh Marru"  wrote:

> GSoC Students,
>
> You might have received email from google about GSoC mid-term evaluations
> due to be filled starting next friday. In preparation for this, please
> update or write your status util now and plans for remaining half of the
> duration on the Wiki. Please clearly indicate your accomplishments as well
> us understanding of your project so far and write in convincing terms how
> you plan to finish up.
>
> Lets have our weekly hangout tomorrow (Friday) at 9 am eastern (6.30pm
> IST) and review these. I think it will be better during next week if we
> schedule demos of your work so far.
>
> Please keep sending any technical impediments to the dev list so they can
> be resolved sooner than weekly meetings. But if anything will need longer
> discussion, we can certainly talk after the mid-term updates.
>
> Cheers,
> Suresh

[GSoC] Midterm Evaluation and Weekly Hangout

[Suresh Marru]

GSoC Students,

You might have received email from google about GSoC mid-term evaluations due 
to be filled starting next friday. In preparation for this, please update or 
write your status util now and plans for remaining half of the duration on the 
Wiki. Please clearly indicate your accomplishments as well us understanding of 
your project so far and write in convincing terms how you plan to finish up.

Lets have our weekly hangout tomorrow (Friday) at 9 am eastern (6.30pm IST) and 
review these. I think it will be better during next week if we schedule demos 
of your work so far. 

Please keep sending any technical impediments to the dev list so they can be 
resolved sooner than weekly meetings. But if anything will need longer 
discussion, we can certainly talk after the mid-term updates. 

Cheers,
Suresh

Re: chessisNumber?

[Pamidighantam, Sudhakar V]

Thanks Chaturi:

OK. this is to specify a particular host in a cluster. This option is used to 
test some thing in one host before going to production for all hosts or if one 
host has special resources that are needed.

Sudhakar.
On Jun 18, 2015, at 8:55 AM, Chathuri Wimalasena 
mailto:kamalas...@gmail.com>> wrote:

According to LSF xslt file, chassis name is specified as "#BSUB -m c". May be 
Lahiru can give more insight.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 9:16 AM, Pamidighantam, Sudhakar V 
mailto:spami...@illinois.edu>> wrote:
I have not heard such a requirement in LSF. Can somebody explain how this is 
used.

Sudhakar.

On Jun 18, 2015, at 7:56 AM, Pierce, Marlon 
mailto:marpi...@iu.edu>> wrote:

Is this chassis number?

From: Chathuri Wimalasena mailto:kamalas...@gmail.com>>
Reply-To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Date: Thursday, June 18, 2015 at 8:53 AM
To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Subject: Re: chessisNumber?

Hi Suresh,

It was added when we add LSF job manager. As I remember, it was required for 
that.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru 
mailto:sma...@apache.org>> wrote:
Hi All,

What is chessisNumber in the scheduling model [1]?

Suresh

[1] - 
https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift

Re: chessisNumber?

[Suresh Marru]

I found some references to it. In short, this is a very cluster specific and is 
a non-standard option. I will look into how to handle these kind of options in 
a general way.

http://wiki.umassrc.org/wiki/index.php/Main_Page 


Suresh

> On Jun 18, 2015, at 9:55 AM, Chathuri Wimalasena  wrote:
> 
> According to LSF xslt file, chassis name is specified as "#BSUB -m c". May be 
> Lahiru can give more insight. 
> 
> Thanks..
> Chathuri
> 
> On Thu, Jun 18, 2015 at 9:16 AM, Pamidighantam, Sudhakar V 
> mailto:spami...@illinois.edu>> wrote:
> I have not heard such a requirement in LSF. Can somebody explain how this is 
> used. 
> 
> Sudhakar.
> 
> On Jun 18, 2015, at 7:56 AM, Pierce, Marlon  > wrote:
> 
>> Is this chassis number?
>> 
>> From: Chathuri Wimalasena > >
>> Reply-To: "dev@airavata.apache.org " 
>> mailto:dev@airavata.apache.org>>
>> Date: Thursday, June 18, 2015 at 8:53 AM
>> To: "dev@airavata.apache.org " 
>> mailto:dev@airavata.apache.org>>
>> Subject: Re: chessisNumber?
>> 
>> Hi Suresh, 
>> 
>> It was added when we add LSF job manager. As I remember, it was required for 
>> that. 
>> 
>> Thanks..
>> Chathuri
>> 
>> On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru > > wrote:
>> Hi All,
>> 
>> What is chessisNumber in the scheduling model [1]?
>> 
>> 
>> Suresh
>> 
>> [1] - 
>> https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift
>>  
>> 
> 
> 

Re: chessisNumber?

[Chathuri Wimalasena]

According to LSF xslt file, chassis name is specified as "#BSUB -m c". May
be Lahiru can give more insight.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 9:16 AM, Pamidighantam, Sudhakar V <
spami...@illinois.edu> wrote:

>  I have not heard such a requirement in LSF. Can somebody explain how this
> is used.
>
>  Sudhakar.
>
>  On Jun 18, 2015, at 7:56 AM, Pierce, Marlon  wrote:
>
>  Is this chassis number?
>
>   From: Chathuri Wimalasena 
> Reply-To: "dev@airavata.apache.org" 
> Date: Thursday, June 18, 2015 at 8:53 AM
> To: "dev@airavata.apache.org" 
> Subject: Re: chessisNumber?
>
>   Hi Suresh,
>
>  It was added when we add LSF job manager. As I remember, it was required
> for that.
>
>  Thanks..
> Chathuri
>
> On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru  wrote:
>
>> Hi All,
>>
>>  What is chessisNumber in the scheduling model [1]?
>>
>>  Suresh
>>
>>  [1] -
>> https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift
>> 
>>
>
>
>

Re: chessisNumber?

[Pamidighantam, Sudhakar V]

I have not heard such a requirement in LSF. Can somebody explain how this is 
used.

Sudhakar.
On Jun 18, 2015, at 7:56 AM, Pierce, Marlon 
mailto:marpi...@iu.edu>> wrote:

Is this chassis number?

From: Chathuri Wimalasena mailto:kamalas...@gmail.com>>
Reply-To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Date: Thursday, June 18, 2015 at 8:53 AM
To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Subject: Re: chessisNumber?

Hi Suresh,

It was added when we add LSF job manager. As I remember, it was required for 
that.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru 
mailto:sma...@apache.org>> wrote:
Hi All,

What is chessisNumber in the scheduling model [1]?

Suresh

[1] - 
https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift

Re: chessisNumber?

[Pierce, Marlon]

Is this chassis number?

From: Chathuri Wimalasena mailto:kamalas...@gmail.com>>
Reply-To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Date: Thursday, June 18, 2015 at 8:53 AM
To: "dev@airavata.apache.org" 
mailto:dev@airavata.apache.org>>
Subject: Re: chessisNumber?

Hi Suresh,

It was added when we add LSF job manager. As I remember, it was required for 
that.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru 
mailto:sma...@apache.org>> wrote:
Hi All,

What is chessisNumber in the scheduling model [1]?

Suresh

[1] - 
https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift

Re: chessisNumber?

[Chathuri Wimalasena]

Hi Suresh,

It was added when we add LSF job manager. As I remember, it was required
for that.

Thanks..
Chathuri

On Thu, Jun 18, 2015 at 8:38 AM, Suresh Marru  wrote:

> Hi All,
>
> What is chessisNumber in the scheduling model [1]?
>
> Suresh
>
> [1] -
> https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift
>

Re: PGA Cache and AJAX/PHP

[John Weachock]

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" 
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 <
> supun.nakand...@gmail.com> 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 
>> 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_comp

chessisNumber?

[Suresh Marru]

Hi All,

What is chessisNumber in the scheduling model [1]?

Suresh

[1] - 
https://github.com/apache/airavata/blob/master/thrift-interface-descriptions/airavata-api/scheduling_model.thrift
 

Re: PGA Cache and AJAX/PHP

[Supun Nakandala]

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 
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 
> 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 t

Re: PGA Cache and AJAX/PHP

[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

Re: PGA Cache and AJAX/PHP

[John Weachock]

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