ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Very first msg always fails after reload NEON

Post new topic  Reply to topic
 Very first msg always fails after reload NEON « View previous topic :: View next topic » 
Author Message
Yanghui
PostPosted: Thu Feb 06, 2003 10:44 am    Post subject: Very first msg always fails after reload NEON Reply with quote

Disciple

Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland

Hi, there,

urgent help needed here.

WMQI2.1 + CSD2, broker on Solaris with Oracle db.

It's certain that the first msg always can't be processed successfully in a new broker enviornment if there is NEON/NEONMSG node used in msgflow. It seems to me that the first msg always has difficulty to connect to NEON db. Only the very first one has this problem. The execeptionlist is like:

<ExceptionList>
<RecoverableException>
<File>/build/S210_P/src/DataFlowEngine/PluginInterface/ImbCniNode.cpp</File>
<Line>1086</Line>
<Function>ImbCniNode::evaluate</Function>
<Type>ComIbmCniNode</Type>
<Name>a7448516-ee00-0000-0080-98ebea084b67</Name>
<Label>ALL_SWIFT_OUT_MF.</Label>
<Text>Caught exception and rethrowing</Text>
<Catalog>WMQIv210</Catalog>
<Severity>3</Severity>
<Number>2230</Number>
- <RecoverableException>
<File>/home/src/ccm_wa/en g_dev/mif~MIF_2.1_31/mif/src/common/NeonConnectionMgr.cpp</File>
<Line>190</Line>
<Function>NEONConnectionManager::dbmsSession()</Function>
<Type />
<Name />
<Label />
<Text />
<Catalog>NEONMIF20</Catalog>
<Severity>1</Severity>
<Number>406</Number>
</RecoverableException>
</RecoverableException>
</ExceptionList>

Does anybody come cross similar problem? Is there any solution for this? After our system goes live, we can't afford this failure each time we reload NEON in production.

Thanks a lot in advance.

-Yanghui
Back to top
View user's profile Send private message Send e-mail
yaakovd
PostPosted: Thu Feb 06, 2003 1:10 pm    Post subject: Reply with quote

Partisan

Joined: 20 Jan 2003
Posts: 319
Location: Israel

I don't know about this problem itself.
But I guess if you set Backout Threshold more than 1, you message will be processed in second retry. Let me know if it work...
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel
Back to top
View user's profile Send private message Send e-mail
Yanghui
PostPosted: Fri Feb 07, 2003 2:42 am    Post subject: Reply with quote

Disciple

Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland

Thank you very much for your reponse. It's a great idea but what a pity that all backout msgs would be captured by Catch terminal of the MQInput node and redirected to error-handling subflow. So, all roll-back msgs won't be put back to the input queue. I think Backout Threshold won't help...

Here are more information about this problem...

1). The problem happens to each msgflow which uses NEON node. So, each time I reload NEON db, all msgflows using NEON will be affected without exception, which is the pain.

2). The command MQSIRELOAD isn't helpful either.

3). I am wondering that maybe we shouldn't copy NEON db from oracle layer but from NEON layer to do NNFie import and export from one test to live. Since our NEON db is huge, it takes more than 7 hours or more to do import, which is the pain as well. Nobody likes the idea to get system down for 7 hours just for reload NEON db...

I am still looking for a better solution ... many thanks.

-Yanghui
Back to top
View user's profile Send private message Send e-mail
Yanghui
PostPosted: Fri Feb 07, 2003 4:27 am    Post subject: Reply with quote

Disciple

Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland

The situation is more clear now. It seems certain that after NEON db reload, the very first msg process result is somehow unpredictable. In one msgflow, there is a MQOutput node (outside trans control) to make a copy of incoming msg. Sometimes we can get the copy of the very first one, sometimes we can't. So, msgflow is not 100 percent behave on the very first msg.

Now I suspect it's a bug in system...

-Yanghui
Back to top
View user's profile Send private message Send e-mail
Nick Lethbridge
PostPosted: Sun Feb 09, 2003 10:39 am    Post subject: Reply with quote

Voyager

Joined: 13 Aug 2001
Posts: 88
Location: Santander, UK

Yanghui,

The following extract from the CSD04 Readme.txt might be relevant (?):

First NEON domain or NEONMSG domain message through a broker fails
(defect 23534)
If you observe this failure, you need to force the order of lil loading.
ibmdfneo.lil must be loaded before NEONRulesEvaluation.lil,
NEONMaptransform.lil and NEONMSGParser.lil. You can set the order of
loading by using the LilPath registry key. LilPath specifies a list
of directories and which order they should be searched for lils. The
following steps will ensure the lils are loaded in the correct order.
a) Create a new directory e.g. /usr/mylildir
b) Move NEONRulesEvaluation.lil, NEONMaptransform.lil and
NEONMSGParser.lil to this new directory.
c) Edit the file /var/wmqi/registry/<BROKERNAME>/LilPath, by adding
the directory containing the lils to the end of the colon separated
list of directories. Make sure you do not insert a new line
character. For example
$ cd /var/wmqi/<BROKERNAME>/registry
$ more LilPath
/usr/opt/mqsi/lil:/usr/opt/mqsi/jplugin
$ print -n /usr/opt/mqsi/lil:/usr/opt/mqsi/jplugin:/usr/mylildir > LilPath
where <BROKERNAME> is the name of your broker

Regards,
Nick.
Back to top
View user's profile Send private message Send e-mail
Yanghui
PostPosted: Wed Feb 12, 2003 3:08 am    Post subject: Reply with quote

Disciple

Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland

Hi, Nick,

Thanks for your reply.

Your information seems quite relevant but I can't find it in the CSD04. I downloaded the CSD04 Readme.txt files for both NT (U200186.txt) and Solaris(U485556.txt) ( it seems same to me.)

I have also searched IBM website for the defect 23534 but in vain.

Do you mind to let me know more about where you can get the info? Thanks again.

Regards
-Yanghui
Back to top
View user's profile Send private message Send e-mail
Nick Lethbridge
PostPosted: Wed Feb 12, 2003 2:38 pm    Post subject: Reply with quote

Voyager

Joined: 13 Aug 2001
Posts: 88
Location: Santander, UK

Hi Yanghui,

The Readme.txt file is in the CSD04 zip file for NT (or tar file for Solaris) and gets installed with the CSD.

I have emailed you a copy.

Regards,
Nick.
Back to top
View user's profile Send private message Send e-mail
Yanghui
PostPosted: Mon Feb 17, 2003 9:02 am    Post subject: Reply with quote

Disciple

Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland

Thanks, Nick,

The defeat 23543 is for AIX but I still tried it on our Solaris to see any help. Unfortunately it doesn't.

I applied CSD04. The problem doesn't go away.



I am a bit at wit's end. Any idea would be highly appreciated.

Thanks in advance.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Very first msg always fails after reload NEON
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.