Syracuse Node.js keepalive settings

SUGGESTED

I'm on V12p23, and I'm trying to resolve 'econnreset' and 'X3Dispatch' errors. End-users get the errors launching basic functions, and we see 'econnreset' errors on the batch server tasks. On the runtime server these seem to correlate with KERNELBASE.dll errors in the event log. I have applied the registry settings in KB 105883 related to TCP/IP keepalive. I have two Syracuse servers, one of which resides with Mongo, and both are virtual machines. I have a support case open, and we're still working on it. The error itself seems to indicate an attempt to connect to an X3 resource that no longer exists, or that the connection is ruined in some way. This may have happened occasionally in V12p21, but it's been a frequent issue since upgrading to p23.

http://online-help.sageerpx3.com/erp/12/staticpost/configuration-file-nodelocal/

The online help article for configuring the nodelocal.js file has two settings under the 'server' section; keepAliveTimeout and headersTimeout. (In the actual Node.js documentation, the base 'server.timeout' value is also specified there.)

When Syracuse starts up the log indicates it's setting the server.timeout to 600 seconds, and the server.keepAliveTimeout and server headersTimeout are null. I am curious to know if anyone has set these in X3 and with what results.

Thanks.

  • 0

    James - we are on P18 and I have one user (only one) who gets this type of error 5 times a day.  Only in the sales order menu (GESSOH) and almost always using filters in the left list.  He never uses the "close page" icon.  Just wondering if any of this is similar to your case.  Ours is unresolved.

  • 0 in reply to Jeremy Rosenbaum

    A note to what I stated above: the variables I noted originally are null in the config file, but they get set when the sessions are created. Mine are 5 seconds and 40 seconds, for the keepAliveTimeout and headersTimeout, respectively.

    While I'm sure I have my share of users that close things improperly, our issue seemed to be more a function of the total number of runtime connections. It's only been a couple of days, but the issue appears to have been resolved by adding an additional runtime server. (I also added memory to the main runtime server, so it's probably a combination of things.)

    I wonder if this note in the Runtime for patch 23 would be relevant to your case:

    - [BEHAVIOUR CHANGE] Error on closing session by PSADX [#X3-201786]
    The timeout during the Adonix closing process has been extended by two seconds to allow Syracuse exchanges to finish.
    The running process test performed after session closing on the 4GL script side has also been updated to wait two seconds longer.

  • 0
    SUGGESTED

    I will be writing this up as a KB soon, as am waiting for final confirmation for a positive outcome.  At this stage I am cautiously optimistic the issue is caused by Windows heap sizing, as it effects all classic user connections, not just batch server

    As it requires a registry change I would prefer to provide the KB article ID once written up and carefully considered, rather than describe the change here

    regards

    Mike

  • 0 in reply to Mike Shaw

    Thanks Mike and James.  I will look for an update to come.

  • 0 in reply to JamesG-ACD
    SUGGESTED

    This change of behavior was to correct an issue when killing user sessions, described in KB 108003 ( support.na.sage.com/.../viewdocument.do ) "ERROR "Application error" when trying to disconnect X3 users from within Sage"