[LON-CAPA-admin] Republish Course Content?

Stuart Raeburn raeburn at msu.edu
Sat Aug 26 00:11:58 EDT 2017


LON-CAPA is designed to handle the situation where a resource is  
republished on a library node, but other node(s) which have a  
subscription to the resource will not accept (or sustain) a connection  
from the library node.

The final step in republication is to add a call to  
lonpublisher::notify() to the PerlCleanupHandler.

When this runs at the end of the request it causes an update command  
to be sent to each subscribed node.  You'll see entries of the  
following type in the .log file for the republished resource (i.e., in  
/home/httpd/html/priv/purdue/<author>/<path>/<resource filename>.log )

Cleanup phase: Notifications

Notifying host <purduea2>:con_delayed
Notifying host <purduea3>:con_delayed
Notifying host <purduea4>:con_delayed

etc.

In addition, files will be added to: /home/httpd/sockets/delayed
for each delayed transaction, and also a log message will be appended  
to /home/httpd/perl/logs/lonnet.perm.log

When the lonc daemon on the library server is next able to connect to  
lond on an access server, any delayed transactions will be completed.

In /home/httpd/perl/logs/lonc.log on the library server you'll see:
"SUCCESS: A delayed transaction was completed"

In /home/httpd/perl/logs/lonnet.perm.log you'll see entries such as:

<timestamp1>:D:<purduea2>:update:<path to resource>:<time and date 1>
<timestamp2>:S::sethost:<purduea2>:update:<path to resource>:<time and date 2>

where "D" is for the delayed transaction, and "S" is for the completed  
transaction.

So, if you were to experience this same problem in the future, what  
you need to do is force a reconnection from the library node to the  
access nodes, after you have fixed whatever problem was causing the  
communication failure.

There are a couple of ways to do this.

One would be to log-in to the library server, select a Domain  
Coordinator role, and use: Main Menu > Status of domain servers >  
"Update Connections and Refresh Status Information"

Another would be to log-in to the library server, and then enter the URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__loncapa.purdue.edu_adm_switchserver-3Fotherserver-3Dpurduea2&d=DwICAw&c=nE__W8dFE-shTxStwXtp0A&r=6g24AmpQZBPFulGSIuS5JJ6GiSlM0WnvLBs7abAf0Go&m=g8rvdD6_TH_WVouvXTMR64wrL97kV_Iw15a5RpOjivg&s=B6vNtUd2gIZ5MD5CPTJrlRtgQEKlvRakVNn7MhEWhlc&e= 

then log-in to library server again, and enter the URL:

https://urldefense.proofpoint.com/v2/url?u=https-3A__loncapa.purdue.edu_adm_switchserver-3Fotherserver-3Dpurduea3&d=DwICAw&c=nE__W8dFE-shTxStwXtp0A&r=6g24AmpQZBPFulGSIuS5JJ6GiSlM0WnvLBs7abAf0Go&m=g8rvdD6_TH_WVouvXTMR64wrL97kV_Iw15a5RpOjivg&s=RndA6mhhUwUaDTL6je0uegzO380YPM_WuEVGOtnMx4M&e= 

etc.

There is a different type of failure mode in which lonc on the library  
node is able to successfully send the "update" command to lond on the  
access node following re-publication, but the LWP request from the  
access node to the library node to retrieve the new version of the  
file fails.

Currently, LON-CAPA just logs the failure in  
/home/httpd/perl/logs/lond.log, but leaves the outdated file in place  
on the access node.  In the future, lond will remove the outdated file  
(see:  
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.lon-2Dcapa.org_pipermail_lon-2Dcapa-2Dcvs_Week-2Dof-2DMon-2D20170821_027885.html&d=DwICAw&c=nE__W8dFE-shTxStwXtp0A&r=6g24AmpQZBPFulGSIuS5JJ6GiSlM0WnvLBs7abAf0Go&m=g8rvdD6_TH_WVouvXTMR64wrL97kV_Iw15a5RpOjivg&s=yQ5KSQmjatjCpEj-tNE6kftgaW46i-rAnu1HgUJdmmE&e=   
).

Stuart Raeburn
LON-CAPA Academic Consortium


Quoting "Young, Joyce E" <young257 at purdue.edu>:

> All,
>                 We had an incident where our library server was not  
> communicating with our application servers for a time. Users were  
> all logging into the library server and all seemed fine until the  
> library server got overloaded, we saw what was happening, and got  
> all servers communicating again.
>                 During the time when activity was only happening on  
> the library server, some course problems were edited and  
> republished. When we re-connected all servers and students were then  
> re-routed to the application servers, we learned that the students  
> were not seeing the updated problem versions. The updated problems  
> were not pushed to the application servers as they would have been  
> during normal circumstances.
>                 We found that if the problems were re-published,  
> once all servers were connected, then the version push happened as  
> it should. To rectify our issue, we went in and manually republished  
> any problems that were edited during the "dark" period.
>                 Is there an easier way to handle this situation if  
> it should happen again? Is there a way to "refresh" a whole course,  
> re-publishing any content currently used in that course? Could we  
> have just copied the affected .problem and .problem.meta files from  
> the library server over to the application servers?
>                 The authorspace directories that we pull from have  
> unpublished resources in them (works in progress), so republishing  
> at the directory level wouldn't work for us. Any advice or ideas  
> would be appreciated. We don't expect this to happen again, but it  
> would be nice to have a plan in place in case it does.
>                                                                       
>                            Thanks,
>                                                                       
>                                            Joyce Young
>
> Joyce Young
> Programmer/Analyst
> ITAS - Student Systems Competency Center
> Purdue University
> 3495 Kent Avenue, Suite 100
> West Lafayette, IN 47906
> Phone: (765) 427-6340
> Fax: (765) 464-2233
> Campus Mail: ROSS
> young257 at purdue.edu<mailto:young257 at purdue.edu>



More information about the LON-CAPA-admin mailing list