Working with another great JDE upgrade.
Part of what I like to do is look through the logs on a nightly basis and see if anything strange occurred. I have a couple of stories from the trenches on this.
Firstly, some logs
057 Wed Jun 2 09:35:11.080962 ipcmisc.c348
IPC3700004 - sendMessage timed out, idx=246,
errno=4.
3057 Wed Jun
2 09:35:11.081207 extmsgq.c1194
Could not pass message to jdenet_k kernel
queue=<Krnl18952ReqQ> (lastIPCError=<eIPCTimedOut>),Message aborted
for msgType=924.
3057 Wed
Jun 2 09:35:11.081261
extmsgq.c1271
NET2000002: Could not pass message to
jdenet_k kernel queue=<Krnl18952ReqQ>
(lastIPCError=<eIPCTimedOut>), Message aborted, type=924
Wed Jun 2
10:01:38.787813 extmsgq.c1271
NET2000002: Could not pass message to
jdenet_k kernel queue=<Krnl18952ReqQ> (lastIPCError=<eIPCTimedOut>),
Message aborted, type=924
2981 Wed
Jun 2 13:08:03.750311
ipcmisc.c348
IPC3700004 - sendMessage timed out, idx=246,
errno=4.
2981 Wed
Jun 2 13:08:03.750469
extmsgq.c1194
Could not pass message to jdenet_k kernel queue=<Krnl18952ReqQ>
(lastIPCError=<eIPCTimedOut>),Message aborted for msgType=924.
2981 Wed
Jun 2 13:08:03.750520
extmsgq.c1271
2614 Wed
Jun 2 02:17:35.323798
ipcmisc.c348
IPC3700004 - sendMessage timed out, idx=246,
errno=4.
2614 Wed
Jun 2 02:17:35.323955
extmsgq.c1194
Could not pass message to jdenet_k kernel
queue=<Krnl18952ReqQ> (lastIPCError=<eIPCTimedOut>),Message aborted
for msgType=916.
2614 Wed
Jun 2 02:17:35.324004 extmsgq.c1271
NET2000002: Could not pass message to
jdenet_k kernel queue=<Krnl18952ReqQ>
(lastIPCError=<eIPCTimedOut>), Message aborted, type=916
2614 Wed
Jun 2 02:17:35.324045
saw_mon.c1100
jdeSawImpGetKernelUserListV3:Error:JDENET_SendMsg:le_net_error
12:<JDEVPAPP02>,<6017>,18952,5
The important thing about logs like this is the msgType, because this tells you the type of message being dropped. Let's be honest, if it's serverManager related stats, we do not care!
opening msgtpye.h in netmessaging dir from system/include on the server, shows me the message that this is occurring for. But you also need to look at the kernel.
You do not need to be a programmer to work out the moderate description from the comments in the code.
typedef
enum tagJDENETCallObjectMsgType {
JDEMSGCALLOBJ = CALLOBJECT_RANGE_START,
JDEMSGINITREMOTEUSER, /* 902 */
JDEMSGFREEREMOTEUSER, /* 903 */
JDEMSGINITREMOTEENV, /* 904 */
JDEMSGFREEREMOTEENV, /* 905 */
JDEMSGGETSZUSERLIST, /* 906 */
JDEMSGCUSTOMRUN, /* 907 */
JDEMSGCUSTOMLOAD, /* 908 */
JDEMSGCUSTOMUNLOAD, /* 909 */
JDEMSGNOTUSED, /* 910 */ /* Previously
JDEMSGTAMSEND */
JDEMSGREFRESHCACHE, /* 911 */
JDEMSGREFRESHPOCACHE, /* 912 */
JDEMSGCOMMITREMOTEUSER, /* 913 */
JDEMSGROLLBACKREMOTEUSER, /* 914 */
JDEMSGPREPAREREMOTEUSER, /* 915 */
JDEMSGGETUSERLIST, /* 916 */
JDEMSGCLEARCACHE, /* 917 */
JDEMSGSETUSEROPTION, /* 918 */
JDEMSGGETMSDTCWHEREABOUTS,/* 919 */
JDEMSGXMLCALLOBJ, /* 920 */
JDEMSGBULKTREELOADFROMJDECACHE, /* 921 */
JDEMSGGETZEVENTTEMPLATE, /* 922 */
JDEMSGCONFIGURATIONCHANGE, /* 923 */
Remember that the jdenet kernel is the magician that is passing messages internally via IPC and externally via TCP/IP. You can see where they are going to though, just need to read.
At the end of the day, this is a good tip for working back from your logs to deciphering the IPC errors on your server. Generally if you are hitting OS limits, the JDE logs are going to get pretty verbose. So in the instance above, we do not need to increase any of the OS limits because of the IPC errors
remember on Linux as the jde user, you can run ipcs and see all of the shared memory and IPCs that JDE is using in kernel world.
