DSI/DCLINK jdeXMLResponse receive failed

nrferrie

Active Member
Hi List,
We are running DSI DCLINK 5.0 on Windows 2003 R2. JDE 8.12/tools 8.98.2.4 on iSeries V6R1. Once in a while our DSI server gets the error message "jdeXMLResponse receive failed". It seems the only way to recover is by restarting the DSI server and bouncing JDE on the Enterprise Server. Has anyone seen this or has any idea what is causing it?

Thanks.
 
Have you checked the logs of the XML Dispatch kernels? There are the kernels that the XML messages from DSI get sent to initially. Also, I know in older tools releases there were known issues with XML messages so you may want to look into updating to a current 8.98 tools release.
 
JDE thin client is leaking resources. This will always lead to the client process eventually crashing. This affects all releases of JDE including the latest TR's. - I know this, because I was hitting this issue repeatedly until I ended up re-developing the client layer and I'm now using my own implementation which does not have this problem.
 
Check your Kernel Recycling also I've attached a white paper from DSI

Symptoms
Following error message in the Dispatch kernel log when processing XML Interoperability requests via a third party application or using the XML APIs:
<errorReport code="11" state="3">
The network communication is broken.

Cause
The errors in the XML Dispatch kernel logs indicate that messages can not be sent to specific XML CO Kernel processes. There are only 2 possible causes why this error happens so watch for zombie callObject kernels:

1. The E1 Server was bounced, but the XML Interoperability clients talking to the server were not. This causes the clients to send requests with "stale" session ID's (i.e. to XML CO Kernel processes that no longer exist). The XML Interoperability client code should be smart enough to handle this situation and re-send the request with a blank Session ID so that a new one is created. If this is what's going on and the customer wants to avoid these errors, they should bounce the DSI clients when they bounce the E1 server.

Referring to a sample XML Dispatch log, it looks like the XMLDispatcher is trying to communicate with the COK with PID: 4492 at Mon Oct 22 07:34:53.727002. When checking the COK, It looks like the COK is already recycled at Mon Oct 22 01:00:04.914001. That means the COK 4492 is not longer available at the time when XMLDispatcher is trying to communicate. Hence, the following error gets generated in the XMLDispatcher logs. In this case the XML Interoperability client code should be smart enough to handle this situation and re-send the request with a blank Session ID so that a new one is created:
2776/2780 SYS:XMLDispatch Mon Oct 22 07:34:53.727000 Dispatcher.cpp714
Sending a message failed, netErr=17.

2776/2780 SYS:XMLDispatch Mon Oct 22 07:34:53.727001 Dispatcher.cpp714
ProcessDoc (processResquest): Dispatch Exception, state=2

2776/2780 SYS:XMLDispatch Mon Oct 22 07:34:53.727002 Dispatcher.cpp714
XMLDispatcher error report: <?xml version='1.0' encoding='utf-8' ?>
<jdeResponse environment="PD900" type="callmethod" user="dclink" session="4492.1350837271.3">
<errorReport code="11" state="3">
The network communication is broken.
</errorReport>
</jdeResponse>

The first part of the session ID is the Process ID of the XML CO Kernel. So, when the problem occurs, check the process ID to determine if if that process exists. If not, then this is what is causing the error.

2. The XML CO Kernels crashed. If this is the case, there would be zombie kernels in Server Manager. In this case additional research needs to be conducted by GSC to investigate why it crashed( became zombie kernel).
Solution
When getting this error, the recommendation for the 2 possible root causes is the following:

1. To correct the issue from happening again the XML Interop clients need to be restarted whenever the E1 servers are restarted or the corresponding COKs are recycled.

2. If there are callObject zombie kernels, submit the corresponding callObj and dispatch kernel logs from Enterprise Server to GSC for further analysis.
 

Attachments

  • 183844-DSI Whitepaper - JDE.INI Basic Settings for XML Workload.doc
    83 KB · Views: 459
I've always suspected an orphaned connection, but could not prove it. That is a very interesting white paper from DSI. It describes exactly what is happening with our system. We restart our JDE subsystems on a nightly basis (I know...not necessary). I'll start bouncing the DSI/DCLINK server on a nightly basis.

Thanks for all the input folks!
 
I forgot to mention something earlier that most already know. Another issue that was causing broken connections, time outs, long server boot times and various server tasks hanging was the numerous JDEROOT and JAS log files clogging the WINDOWS\SYSTEM32 folder. On a regular WEBDEV or FAT client these were more an annoyance in the E812 folder, but on the server they were created in Windows\System32 by default.

The fix:
Modify the JDELOG.PROPERTIES file located in C:\e812\system\Classes to either not create any log files or specify the location.

Below I've changed it from FILE=\\JDEROOT.LOG to FILE=NONE and FILE=\\JAS.LOG to FILE=NONE

--Sample JDELOG.PROPERTIES--

#The section name should be E1LOG. This logs all the log messages above WARN
[E1LOG]
FILE=NONE
LEVEL=WARN
FORMAT=APPS
MAXFILESIZE=10MB
MAXBACKUPINDEX=20
COMPONENT=ALL
APPEND=TRUE

#Logging runtime and JAS above APP level will be helpful for application developers.
#Application developers should use this log as a substitute to analyze the flow of events
#in the webclient.
[LOG1]
FILE=NONE
LEVEL=APP
FORMAT=APPS
MAXFILESIZE=10MB
MAXBACKUPINDEX=20
COMPONENT=RUNTIME|JAS|JDBJ
APPEND=TRUE
 
Back
Top