*ERROR* Associated kernel 38934 not found

aravindhjo

Member
Hi,

While running a application in web i'm getting the below exception error. In FAT(local web) it's running good.

Select Application Failure Header Label

In the logs found the following error

*ERROR* Associated kernel 38934 not found host UANLSAG030:6016(37904) SocID:55802, freeLocal com.jdedwards.system.net.JdeNetAssociatedKernelException: Kernel for associated message not exist

Please let me know in which scenerios this error will occur.




Regards,
Aravindh
E9.1.4, Enterprise Server: Linux, Database Server: Linux, Oracle DB: 11g, Weblogic.Streamserve
 
Last edited:
When a BSSV invokes a BSFN, the BSFN will be executed on a Call Object Kernel (COK) kernel. Now let us assume that the COK kernel to which BSSV had initially connected to has gone zombie or it has been kernel recycled.

Now if a new BSSV request is submitted, then that particular BSSV transaction will fail with an error - "JdeNetAssociatedKernelException: Kernel for associated message not exist error." A subsequent re-submission of the BSSV transaction will be successful.

The BSSV layer which actually connects to the COK kernel through the E1 Foundation layer does not know that the COK kernel which it had initially connected to has gone zombie or has been kernel recycled. So when a new request to execute a BSFN is submitted, BSSV will try to connect to the same COK and since that COK is no longer available the error - "JdeNetAssociatedKernelException: Kernel for associated message not exist error" will be thrown and the BSSV transaction will fail.

Solution 1 - Manual Re-submit of BSSV Request

If you manually re-submit the BSSV transaction then it will succeed and subsequent transactions will also be successful. This is because once a "JdeNetAssociatedKernelException: Kernel for associated message not exist error" is thrown, the corresponding COK kernel which has gone zombie or that has been kernel recycled shall be removed from the available COK kernel list so that any subsequent request will not go to same COK kernel.

Scenario where Manual Re-submit of BSSV request is required

A Manual Re-Submit will be required when either of below two conditions is true

1) The context object of the BSSV transaction is created with a manual commit connection in the published bssv method

The context object of a BSSV transaction is created with a manual commit connection if in the corresponding published BSSV method, the startPublishedMethod is called with IConnection.MANUAL or if the startPublishedMethod is called without specifying the connection mode parameter at all.

For ex - context = startPublishedMethod(context, "addAddressBook", vo, IConnection.MANUAL);

(OR)

startPublishedMethod(context, "addAddressBook", vo); // so when the connection mode
parameter is not specified, the default connection mode is manual.

2) Any of the BSFN(s) invoked in the BSSV transaction, create a Cache (BSFN Cache)
 
Back
Top