Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0DBF518A2D for ; Wed, 17 Jun 2015 19:19:11 +0000 (UTC) Received: (qmail 36725 invoked by uid 500); 17 Jun 2015 19:19:11 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 36674 invoked by uid 500); 17 Jun 2015 19:19:10 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 36663 invoked by uid 99); 17 Jun 2015 19:19:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Jun 2015 19:19:10 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dchau3@binghamton.edu designates 209.85.216.182 as permitted sender) Received: from [209.85.216.182] (HELO mail-qc0-f182.google.com) (209.85.216.182) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Jun 2015 19:16:55 +0000 Received: by qcwx2 with SMTP id x2so17036533qcw.1 for ; Wed, 17 Jun 2015 12:18:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=rtq0gA1MbMWV7rObZxBwwUJ4PfI23NepFinP6lWgt1s=; b=d0tTWmky08SmwND3X2Xr5xPYuiJ6tlPnLdV5baopsxKmYSxNvisFo2PEhAKzru9e5h w5cATjdsXP4ZVyFSjcqzHTdEKzWQFsAYmFEvA+NwfglU+o0i5eHOomKX995fTWzj0YNG +mc3LU88hKCDKZr2FJpWOEp0EiZ+7cf0EWv6BMVWO/e9Si39KFcuitqB+42dziD3JAjK DatkkAoyTg+KPvflLe4OWlFeTRs5tG/KbNQOH8AWTZ1++OCEXy+YZKtiBRl3vBVGzczH A6uBNC4ewWh9tHv8hBZMWsg24eQiu+o9eVoxOxIHpUcix2dCdrxS0szO4CpZl1uQzO+c 4oCA== X-Gm-Message-State: ALoCoQkVH4FqOYOaKCvb3Y9OBCoRXMm6yNHW/sgKW8GqZooIZSnca53/wfdhTPFGCmAQSogDIdb1 X-Received: by 10.55.17.154 with SMTP id 26mr16960200qkr.18.1434568721881; Wed, 17 Jun 2015 12:18:41 -0700 (PDT) Received: from [192.168.2.87] (pool-100-2-204-34.nycmny.fios.verizon.net. [100.2.204.34]) by mx.google.com with ESMTPSA id 60sm2650046qgy.11.2015.06.17.12.18.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jun 2015 12:18:40 -0700 (PDT) From: Douglas Chau Content-Type: multipart/alternative; boundary="Apple-Mail=_CD46FA5D-FB49-40A9-B12C-5D13DF75DA2E" Subject: PGA Cache and AJAX/PHP Message-Id: <72951BAC-2BE0-46AE-9038-31EAC7BF5BCF@binghamton.edu> Date: Wed, 17 Jun 2015 15:18:39 -0400 To: dev@airavata.apache.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_CD46FA5D-FB49-40A9-B12C-5D13DF75DA2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 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=E2=80=99s 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=E2=80=99s 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.=20 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=E2=80=99s 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 =E2=80=9Ctrue=E2=80=9D. And of course, = if you are eventually setting a boolean field to the string =E2=80=9Ctrue=E2= =80=9D, PHP always evaluates a string to boolean true unless it is = something that is considered empty by PHP (i.e. =E2=80=9C=E2=80=9D or = =E2=80=9C0=E2=80=9D). 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-throug= h-ajax-being-treated-as-strings-in-server-side = = http://stackoverflow.com/questions/7336861/how-to-convert-string-to-boolea= n-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 --Apple-Mail=_CD46FA5D-FB49-40A9-B12C-5D13DF75DA2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s 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 metho= d actually gets it=E2=80=99s 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=E2=80=99s 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 =E2=80=9Ctrue=E2=80=9D. And of course, if you are = eventually setting a boolean field to the string =E2=80=9Ctrue=E2=80=9D, = PHP always evaluates a string to boolean true unless it is something = that is considered empty by PHP (i.e. =E2=80=9C=E2=80=9D or =E2=80=9C0=E2=80= =9D). 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

= --Apple-Mail=_CD46FA5D-FB49-40A9-B12C-5D13DF75DA2E--