job I submitted yesterday didn't really run? about reader

[dbrower]

I see a record of two jobs being submitted (one yesterday and one today), but can't find the jobs themselves. hmm..

[dbrower]

In the log file ~eric/log/queue2carrel.log I found the following message for both of these jobs: Error: Unknown type (cord). Call Eric.

It looks like the dispatch table for reader-classic does not have an entry for cord. https://github.com/ericleasemorgan/reader-classic/blob/master/bin/queue2carrel.sh#L116

@ericleasemorgan do you have any thoughts on this?

[ericleasemorgan]

On Jun 4, 2021, at 1:10 PM, Natalie Meyers ***@***.***> wrote: I am pretty sure a job I submitted 16 hrs ago aka yesterday didn't run or didn't return results. Tried again today, submit button appears to work, then no emails, nothing shows up in My Carrels etc. so @ericleasemorgan the question is, where's my job? did it run, did it complete? how do I see the output?

Natalie, let's do some debugging; let's do something simple. Please try to create a small carrel using the "classic" interface, and then try to create the same carrel using the "/p" interface. I am able to get carrels from the classic interface, but not from the /p interface. Don, it seems all your good work is located on reader-http in /opt/reader. When I navigate down to the file templates/cord-create.html I see that the form's action attribute is empty. I suppose execution of a submission gets handled by @app.route("/create/cord", methods=["GET", "POST"]). I then noticed that you write to the queue using add_job_to_queue, but alas, there are two queues because there are two distinctly different bibliographic structures; processing against Reader Classic is different than processing against Reader CORD. Thus, when creating carrels for CORD, update the queue at: /data-disk/reader-compute/reader-cord/queue/todo And when processing everything else, update the queue at: /data-disk/reader-compute/reader-classic/queue/todo You have put the location of the queue in TODO_PATH. I believe you will be able to branch accordingly based on the value of TYPE. 'Make sense? P.S. Don, you have written a whole lot of code!!

…

-- Eric

[randal-sean-harrison]

Hey Don, Did my question about the route actually get pulled in and change the route. Occam’s Razor, that’s the likeliest? Cheers, Randy Randal Sean Harrison, Ph.D. Associate Librarian, Emerging Technologies Hesburgh Libraries Concurrent Teaching Professor, Management & Organization Mendoza College of Business University of Notre Dame 158 Hesburgh Library Notre Dame, IN 46556 [phone] ***@***.*** ***@***.***> randalseanharrison.com <https://randalseanharrison.com/> ⌖ Map to my office <https://randalseanharrison.com/img/map-to-my-office.svg> ⌖ Meet with me <https://calendly.com/randal-sean-harrison/consultation>

…

On Jun 4, 2021, at 5:03 PM, Eric Lease Morgan ***@***.***> wrote: On Jun 4, 2021, at 1:10 PM, Natalie Meyers ***@***.***> wrote: > I am pretty sure a job I submitted 16 hrs ago aka yesterday didn't run or didn't return results. > Tried again today, submit button appears to work, then no emails, nothing shows up in My Carrels etc. > > so @ericleasemorgan the question is, where's my job? did it run, did it complete? how do I see the output? Natalie, let's do some debugging; let's do something simple. Please try to create a small carrel using the "classic" interface, and then try to create the same carrel using the "/p" interface. I am able to get carrels from the classic interface, but not from the /p interface. Don, it seems all your good work is located on reader-http in /opt/reader. When I navigate down to the file templates/cord-create.html I see that the form's action attribute is empty. I suppose execution of a submission gets handled by @app.route("/create/cord", methods=["GET", "POST"]). I then noticed that you write to the queue using add_job_to_queue, but alas, there are two queues because there are two distinctly different bibliographic structures; processing against Reader Classic is different than processing against Reader CORD. Thus, when creating carrels for CORD, update the queue at: /data-disk/reader-compute/reader-cord/queue/todo And when processing everything else, update the queue at: /data-disk/reader-compute/reader-classic/queue/todo You have put the location of the queue in TODO_PATH. I believe you will be able to branch accordingly based on the value of TYPE. 'Make sense? P.S. Don, you have written a whole lot of code!! -- Eric — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#175 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAXSPMFWVS2A7UVFK6SI33TRE5S3ANCNFSM46DFZJQQ>.

[dbrower]

Don, it seems all your good work is located on reader-http in /opt/reader. When I navigate down to the file templates/cord-create.html I see that the form's action attribute is empty. I suppose execution of a submission gets handled by @app.route("/create/cord", methods=["GET", "POST"]).

Yes, exactly. The html is sent with a GET, and then a POST is used for the form submission. And the server is running out of /opt/reader.

I then noticed that you write to the queue using add_job_to_queue, but alas, there are two queues because there are two distinctly different bibliographic structures; processing against Reader Classic is different than processing against Reader CORD.

Yuuuuup, this is it. I missed that there were multiple submission queues when I was porting the CGI scripts. Thanks for pointing this out. I'll get a patch made to fix it.

I also see a third queue for the HathiTrust, and each queue has a corresponding backlog directory for files.

[dbrower]

Did my question about the route actually get pulled in and change the route.

Yes, I think that was pulled in. But it isn't causing this problem.

[dbrower]

@nkmeyers I think the problem is fixed and I have rerun those two jobs that got "lost".