Forum OpenACS Development: ns_job valid procs

If you simply define the proc in a script to be executed, the proc is defined in the current interpreter only. To ensure that new procedures are incorporated into the blueprints for all threads/interpreters (including in the interpreter used in the job queue), you must define them using ns_eval (see man page).

However, when a proc is defined in the library files, which are loaded at startup time (as in OpenACS under "packages"), the proc becomes part of the blueprints for all future interpreters, and there is no need for ns_eval.

Here is your example slightly modified to use ns_eval:

ns_eval {
  ad_proc foo {} {
    ns_log warning "hello, world"
  }
}

if {"test_queue" ni [ns_job queues]} {
    ns_job create test_queue
}
ns_job queue test_queue foo

This example works with NaviServer (AOLserver is now obsolete).

Note: Avoid using puts to output to stdout, as this output can be difficult to locate. Instead, use ns_log for logging messages.

Hope this helps!
-g

The NaviServer does not produce the error with variable "bar", just tested the following snippet.

ns_eval {
  ad_proc foo {bar} {
    ns_log notice "hello, $bar"
  }
}

if {"test_queue" ni [ns_job queues]} {
    ns_job create test_queue
}
ns_job queue test_queue [list foo XXX]

Notice, that ns_job expects the script as a single argument.

all the best
-g

It's the weirdest thing. I know AOLserver supports ns_eval, but in the folder I was given to prototype new features, I get errors simply by having variables in the ns_eval code block:

can't read "bar": no such variable
    while executing
"ns_eval {
  proc foo {bar} {
    ns_log notice "hello, $bar"
  }
}"

Now I can get around this by relying on adprocs that are loaded when the server starts, but then I still can't seem to get ns_job to function the way I'd expect. If foo is already defined (in this case, as an adproc), I don't get a runtime error with this in a tcl script loaded in tandem with an adp page:

set bar "world"
ns_job queue test_queue [foo $bar]

but if I review the queue's job list, I see an empty string: id job36 state done results {} script {} code TCL_OK type nondetached req none time 0.01 starttime 1743162229 endtime 1743162229

indicating the foo proc was executed before anything was added to the queue. If use curly braces:

set bar "world"
ns_job queue test_queue {[foo $bar]}

I get the following in the queue: id job38 state done results {can't read "bar": no such variable} script {[foo $bar]} code TCL_ERROR type nondetached req none time 0.06 starttime 1743163464 endtime 1743163464

I could try again with standard procs, but this feels like something wrong with how my script is being evaluated.

Ah thank you! Double curly braces allowed the proc to be defined.

As far as adding the proc to a queue, I discovered that the variable could be evaluated if I synced it across interpreters:

ns_eval -sync set globalBar "world"
ns_job queue test_queue {foo $globalBar}

Interestingly, this was only required in the sandbox area I was given to test the functionality (located in a web directory). I'm not sure if it's some configuration in place or this was a quirk inherent to tcl running in {base_dir}/www, but I didn't need to use ns_eval -sync to set the variable anymore once moving the code to the {base_dir}/tcl directory.

Good advice. The time investment is definitely a concern.

Just to document for anyone else who runs into the same mental block I did, the best way to pass args into ns_job is using subst:

set bar "world"
ns_job queue test_queue [subst {foo $bar}]