We will occasionally see one of the PE subprocesses get something "stuck in
its throat." Often after a bad FOSI edit on my part. Ahem. For example, if
while I'm editing I double or lose an e-i-c end-tag, "my" PE subprocess gets
stuck with the bad FOSI (or perhaps something else about the subprocess's
environment is ruined) and throws a DVI error completely failing to produce
a PDF. Subsequent requests succeed in producing a PDF but it is
"format-free." Prior to learning this trick the only solution was restarting
Tomcat/PE (or waiting long enough ... long enough for PE to kill/restart the
thread, I now know).
Here is a shorter way to subprocess goodness:
1) Crash the subprocess as described above.
2) Curse.
3) Remote Desktop to the server.
4) Start Task Manager.
5) Select Processes tab (and show processes from all users).
6) Sort by Image Name. (You should see three, well, *I* see three epic.exe
processes. You should see as many as you have set to run in the minthreads
or whatever value.)
7) Switch back to wherever Editor is running and submit a job.
😎 Switch back to the server and select the epic.exe that spins up CPU.
9) Wait for the job to finish. (May not be necessary. Likely avoids some
probably non-destructive error in Editor, though.)
10) End that epic.exe process.
11) Submit another job. Or two.
I saw an error on the first ... didn't catch what it was. Second job worked
like a charm, though.
Cool!
If you have a "real" development environment, restarting Tomcat may not be
an impact, but if you do this on a machine authors are working on, this is
way more friendly since that Tomcat restart also severs DLM connections and
whatnot.
Also, yes, I know using Architect would prevent this happening in the first
place!
--
Paul Nagai
