Publishing Engine 6.0 m010: APE Request Failure. Failed to save body file to ....rq_4746\rqbody.dat

[naglists]

Has anyone else seen, diagnosed, fixed

Publishing Engine 6.0 m010: APE Request Failure.
Failed to save body file to [PE install path]....rq_4746\rqbody.dat
Read timed out.
java.net.SocketTimeoutException.........

This does not happen 100% of the time. It seems to be happening in our
larger docs. (Our large docs aren't really all that large ... all less than
1,000 pages, average is probably in the 200 to 300 range.)

--
Paul Nagai

[naglists]

I now have a case open for this. I have not seen this since we were
mid-upgrade and neither has the lead author I work very closely with. (I
work over VPN near 100% of the time. She is onsite 90%+ of the time.) Any
time we encountered this issue, resubmitting the PDF request successfully
generated a PDF. (Maybe once or twice it took three submissions?)

Now, however, our offshore authors, I believe in Singapore and two sites in
India are seeing this regularly.

Queueing jobs does not succeed. (I am clarifying how the failure shows up
in this scenario. For interactive failures, it shows up in the Event Log
that Editor opens post-failure.)

I just noticed that the header announcing the error is: "Asynchronous
Composition Error" for what that's worth. I was so focused on the insides
of the error report, I failed to notice that bit.

Does it reflect a moral weakness that I want to blame this all on spotty
networks?

[ptc-4875135]

That looks like a network issue to me. What's happening is that the PE
server is trying to take the content being passed to PE and save it to the
server's file system in that path under the Tomcat install tree (I bet
that's got a 'temp' or 'work' somewhere in there), and the connection
between the client (Editor) and server (PE/Tomcat) drops out before all the
content can be transferred and the whole file can be written. I'm not sure
what you could do to fix it, but I think that's probably what's happening.



Chris

[jsillari]

No, Paul, it's not a weakness on your part; it's a fault of software engineering practices which are over-reliant on the integrity of a network which isn't really there. They're not catching network latency and drop-outs as part of APE's error trapping routines (at the right time and in the right place). I'm seeing this in other related publishing products as well.

John Sillari
Chief Technologist
Technical Services Division
Dayton T. Brown, Inc.

On Dec 3, 2012, at 12:57, "Paul Nagai" <-<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">>">mailto:->> wrote:

I now have a case open for this. I have not seen this since we were mid-upgrade and neither has the lead author I work very closely with. (I work over VPN near 100% of the time. She is onsite 90%+ of the time.) Any time we encountered this issue, resubmitting the PDF request successfully generated a PDF. (Maybe once or twice it took three submissions?)

Now, however, our offshore authors, I believe in Singapore and two sites in India are seeing this regularly.

Queueing jobs does not succeed. (I am clarifying how the failure shows up in this scenario. For interactive failures, it shows up in the Event Log that Editor opens post-failure.)

I just noticed that the header announcing the error is: "Asynchronous Composition Error" for what that's worth. I was so focused on the insides of the error report, I failed to notice that bit.

Does it reflect a moral weakness that I want to blame this all on spotty networks?



On Mon, Oct 22, 2012 at 1:04 PM, Paul Nagai <-<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">>">mailto:->> wrote:
Has anyone else seen, diagnosed, fixed

Publishing Engine 6.0 m010: APE Request Failure.
Failed to save body file to [PE install path]....rq_4746\rqbody.dat
Read timed out.
java.net.SocketTimeoutException.........

This does not happen 100% of the time. It seems to be happening in our larger docs. (Our large docs aren't really all that large ... all less than 1,000 pages, average is probably in the 200 to 300 range.)

--
Paul Nagai






-----End Original Message-----

[naglists]

Support is suggesting increasing maxBusyInterval. Looks like I am running
the default as that value is not set in 6.0. In my old 5.3 system, I had it
set to four hours (14400 seconds). So I am definitely good on changing that
value. That said, I think in 5.3 we got an error message that pointed more
clearly to PE timing out. It was a long time ago, though and my memory
ain't what it used to be ...

They also mentioned maxsubprocesswait (which we also changed in our 5.3
environment but I don't think that's relevant here and I'm not sure I want
to change it in 6.0 ... I'd rather guide authors to queue jobs if PE is
"busy."

For what it's worth.

I'll let you know if changing maxBusyInterval helps.