Skip to main content
N
naglists1-Visitor
1-Visitor
October 22, 2012
Question

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

  • October 22, 2012
  • 4 replies
  • 1052 views
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

    4 replies

    N
    naglists1-VisitorAuthor
    1-Visitor
    December 3, 2012
    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?



    P
    ptc-48751351-Visitor
    1-Visitor
    December 3, 2012
    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


    J
    jsillari1-Visitor
    1-Visitor
    December 3, 2012
    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-----
    N
    naglists1-VisitorAuthor
    1-Visitor
    December 3, 2012
    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.


    Terms & ConditionsAccessibility statement