[LON-CAPA-admin] Not Open To Be Viewed Troubles

Stuart Raeburn raeburn at msu.edu
Wed Oct 4 23:28:39 EDT 2017


Reviewing my previous answer, I find that I provided an answer to a  
different question than the one you had actually asked.

Accordingly, I am going to revise my answer from: "it is in memory on  
the access server", to it is in memory (in %env) and also in the  
user's session file, on the filesystem on the access server.

As you noted the username_courseid.state file in /home/httpd/perl/tmp  
contains the conditional statement:

&EXT('user.resource.resource.200.1.awarddetail','BuffersLab') eq 'APPROX_ANS'

The user's session file (a GDBM file):


will contain a key of: user.state.uiuc_3g9196182397259fcuiuclibrary1,  
with the corresponding value containing the results of evaluated  

The routine: &Apache::lonuserstate::evalstate() is used to determine  
(and save)  the value for:  
user.state.uiuc_3g9196182397259fcuiuclibrary1, which is appended to  
%env, and also to the session file.

The evalstate() routine will evaluate the conditions in perl Safe  
space, which will include calling lonnet::EXT(), which in turn calls  
lonnet::restore to retrieve the user's submission history for the  
resource to which the alias: 'BuffersLab' points.

The routine: &Apache::lonnet::devalidate() will remove  
user.state.uiuc_3g9196182397259fcuiuclibrary1 from %env (and from the  
user's session file).

The devalidate() routine is called whenever lonnet::store() or  
lonnet::cstore are called in course context to store the user's  
submissions, points etc.

Note: the question I answered with my previous response to this thread  
was where can you find values for items such as:  
&EXT('user.resource.resource.200.1.awarddetail','BuffersLab') when a  
problem is being rendered, and in that case the answer is in memory.

Stuart Raeburn
LON-CAPA Academic Consortium

>> Does this live entirely in memory or am I missing something?
> It is in memory on the access server.
> When the problem is rendered, the &initialize_storage() routine is  
> called in structuretags.pm within start_problem() which will
> the (global) %history hash in Apache::lonhomework with submission
> award history etc. for the current resource (in the current course  
> context and instance for the current user) by calling  
> lonnet::restore().
> See lines 1024-1025 in the version of structuretags.pm included in  
> loncapa-2.11.2.
> Later during rendering, the global %history hash is cleared with  
> undef (within the end_problem routine).
> Stuart Raeburn
> LON-CAPA Academic Consortium
>> I'm tracing the path of where a condition is stored against the
> files
>> on our servers.
>> Condition to be met:
> &EXT('user.resource.resource.200.1.awarddetail','BuffersLab') eq
>> contains:
> =
>> I'm having a difficult time locating that condition on the access
servers, though.  I've found the conditional statement in the .state
>> file, but I'm not seeing it in any of the user files.  Does this
> live
>> entirely in memory or am I missing something?
>> Thanks,
>> Lee
>> -----Original Message-----
>> From: lon-capa-admin-bounces at mail.lon-capa.org  
>> [mailto:lon-capa-admin-bounces at mail.lon-capa.org] On Behalf Of
> Stuart
>> Raeburn
>> Sent: Tuesday, October 3, 2017 7:14 PM
>> To: lon-capa-admin at mail.lon-capa.org
>> Subject: Re: [LON-CAPA-admin] Not Open To Be Viewed Troubles
>> Hello Lee,
>> There is no log file of access server parameter file changes, but
> you
>> could make your own (see below).
>> Looking back through the archives, it seems you ran into this issue
> in March.
>> I posted a response to the list to that earlier post. See:
>> mail.lon-capa.org/pipermail/lon-capa-admin/2017-March/003273.html
>> which discussed how to view cached parameters in memcache.
>> Assuming the open date parameter in effect is for all students, or  
>> for a specific section, and not for individual student(s), then  
>> parameters will be retrieved using lonnet::get_courseresdata().
>> will, in turn, call &lonnet::dump(), when the cache on the access  
>> server has expired (it's valid for 10 minutes).
>> You could modify lonnet::get_courseresdata() to write the hash  
>> returned by dump() for a particular course to a file (e.g.,  
>> /home/httpd/perl/tmp/debug/$coursenum on the access server).
>> Your code could check if the file already exists, and if it did
>> the existing file to /home/httpd/perl/tmp/debug/$coursenum.old,  
>> before writing the latest data to a new file.
>> You could then create a perl script, which would be run by cron
> every
>> 5 minutes to look in /home/httpd/perl/tmp/debug/.  The script would
compare the contents of $coursenum.old and $coursenum (if both
> exist)
>> and record what had changed for course: $coursenum for the current
timestamp, in a log file.  The script would then unlink
>> Stuart Raeburn
>> LON-CAPA Academic Consortium
>>> Hello Admins,
>>> I am diving back into an issue we've had in which resources are
>>> temporarily "Not open to be viewed."  The resources should be
>>> available now and do become available after 10-20 minutes or a
>> change
>>> of access server.  The leading theory is that the parameter file
>>> being read incorrectly, resulting in the access server thinking
>>> resource is unavailable until the bad parameter is updated.
>>> Is there a log anywhere of access server parameter file changes?
>>> Because things seem to go back to normal after a while I have yet
> to
>>> have the problem reported to me in time to look at the potentially
>>> problematic files in real time.
>>> Sorry for rehashing old troubles, but I'm hoping this time will to
>> the trick.
>>> Lee
>> _______________________________________________
>> LON-CAPA-admin mailing list
>> LON-CAPA-admin at mail.lon-capa.org
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org

More information about the LON-CAPA-admin mailing list