On 07-Mar-14 11:12 PM, Lisa Ann Lentz-Liddell wrote: > Thanks for the responses. To give you background, we are converting from > using SAFfire to OpenSAF. Our code has been running with SAFfire for years. > We have converted our AIS logic to now work with OpenSAF. We are struggling > with getting items working under OpenSAF that were working with SAFfire. The > majority of the problems we are seeing are when there are multiple components > defined within the SU and as one unlocks SUs across the cluster. We have a > need to have approx. 12 different SGs, 90 SUs running across e.g 6 nodes, 1 > to 16 components within a SU (depends on the SG). If we have a simple SU > with one component or start the first SU, things are pretty consistent. As > soon as we increase the number of components and as we unlock SUs, > inconsistencies appear. The CSI attribute assignment is one of those items. > > The extra display attribute with the CSI definition is something we added to > the config for our own purposes. Yes the xml is valid and loads properly. > We removed it from the config and still run into the same problem where only > some of the components within the SU are receiving the CSI attribute. We do > not think that the config is the problem. We are trying to debug the code to > see why it has the attribute in some cases and not in others. The logs below prints a message like "> TMPI-30021: CSI assignment has been received with attribute value of targetDG=3. " This means a component assigned some CSI and AMF passed csi attributes in the arguments of the callback. But the is no log which says that a component got a callback but with null value of csi attribute which was configured for the csi. Please confirm that other components are assigned any csi ?
Thanks Praveen > Any help/direction would be appreciated. > > > Lisa Lentz-Liddell | Technical Consultant, Forward R&D | Office: +1 (800) > 519-8360 x4569 | Direct Dial +1 (513) 345-7869 | www.NetCracker.com > Proven Partner to Communications Service Providers > > -----Original Message----- > From: Hans Feldt [mailto:hans.fe...@ericsson.com] > Sent: Friday, March 07, 2014 4:55 AM > To: praveen malviya; Lisa Ann Lentz-Liddell > Cc: opensaf-users@lists.sourceforge.net > Subject: RE: [users] CSI attribute not received by all components within SU > > Does this XML validate using xmllint and the xsd? > >> -----Original Message----- >> From: praveen malviya [mailto:praveen.malv...@oracle.com] >> Sent: den 7 mars 2014 10:47 >> To: Lisa Ann Lentz-Liddell >> Cc: opensaf-users@lists.sourceforge.net >> Subject: Re: [users] CSI attribute not received by all components within SU >> >> >> On 07-Mar-14 6:42 AM, Lisa Ann Lentz-Liddell wrote: >>> We are running OpenSAF4.4 RC2. >>> >>> We are converting from using SAFfire to OpenSAF. >>> >>> We have a SU with multiple components. All of the components are of the >>> same process (running multiple copies of the same >> process). These components receive via the csi attribute what data they >> should work on. All components within the same SU receive >> the same value attribute value (we need multiple copies of the same process >> working on the same data). When we unlock the >> service unit, we see that only some of the components receive the csi >> attribute. It is inconsistent on how many of the components >> will actually receive the csi attribute. >>> Trace from our logs, the SU has 8 components 1.3.1 -> 1.3.8. Only 6 of 8 >>> components received the CSI attribute, comp 1.3.2 and 1.3.5 >> did not receive the csi attribute: >>> $ grep CSI amfOELCComp1.3*.LOG | grep TMPI | grep attr >>> amfOELCComp1.3.1.155952.LOG:20781:47833720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:13 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.3.155951.LOG:20571:BEFD4720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:13 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.4.155951.LOG:20466:3C85E720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:13 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.6.155951.LOG:20256:654D1720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:12 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.7.155950.LOG:20151:F5132720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:12 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.8.155950.LOG:20047:16F81720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 16:00:12 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> Stop/Restarted the cluster, ran again, all components received a csi >>> attribute for the same SU: >>> $ grep CSI amfOELCComp1.3*.19*.LOG | grep attr >>> amfOELCComp1.3.1.195615.LOG:26890:628C0720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:23 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.2.195615.LOG:26785:8B521720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:23 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.3.195614.LOG:26678:9A3C1720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:23 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.4.195614.LOG:26574:4EF16720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:23 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.5.195614.LOG:26468:D0DF0720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:22 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.6.195614.LOG:26363:71DC2720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:22 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.7.195614.LOG:26257:30EC5720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:22 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> amfOELCComp1.3.8.195613.LOG:26152:DCE68720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:56:22 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=3. >>> But another SU with the same look as the above SU (total 8 components) only >>> 5 out of 8 components received the CSI attribute: >>> $ grep CSI amfOELCComp1.4.*.19*.LOG | grep attr >>> amfOELCComp1.4.1.195748.LOG:27893:FCB13720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:58:00 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=2. >>> amfOELCComp1.4.2.195748.LOG:27787:BC487720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:58:00 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=2. >>> amfOELCComp1.4.4.195748.LOG:27577:DADF3720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:57:59 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=2. >>> amfOELCComp1.4.6.195747.LOG:27368:C053A720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:57:59 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=2. >>> amfOELCComp1.4.8.195747.LOG:27158:2EE50720:INFORM----TMPIgenericMain.cc:2781:06/03/2014 >>> 19:57:58 > TMPI-30021: CSI >> assignment has been received with attribute value of targetDG=2. >>> All of our CSIs for the SI are configured with a csi attribute e.g. >>> <object class="SaAmfCSIAttribute"> >>> >>> <dn>safCsiAttr=targetDG,safCsi=amfOELCElfCompCSI1.4.1,safSi=amfOELCSI1.4,safApp=olcApp</dn> >>> <attr> >>> <name>display</name> >>> <value>OELCCSI Attribute1.4.1</value> >>> </attr> >> As per AMF spec, class SaAmfCSIAttribute has only one attribute which is >> saAmfCSIAttriValue. Why "<name>display</name>' is configured? >> >> Thanks >> Praveen >>> <attr> >>> <name>saAmfCSIAttriValue</name> >>> <value>targetDG=4</value> >>> </attr> >>> </object> >>> >>> Any help with debugging this? >>> >>> Thanks. >>> >>> Lisa Lentz-Liddell | Technical Consultant, Forward R&D | Office: +1 (800) >>> 519-8360 x4569 | Direct Dial +1 (513) 345-7869 | >> www.NetCracker.com >>> Proven Partner to Communications Service Providers >>> >>> >>> >>> >>> ________________________________ >>> The information transmitted herein is intended only for the person or >>> entity to which it is addressed and may contain confidential, >> proprietary and/or privileged material. Any review, retransmission, >> dissemination or other use of, or taking of any action in reliance >> upon, this information by persons or entities other than the intended >> recipient is prohibited. If you received this in error, please >> contact the sender and delete the material from any computer. >>> ------------------------------------------------------------------------------ >>> Subversion Kills Productivity. Get off Subversion & Make the Move to >>> Perforce. >>> With Perforce, you get hassle-free workflows. Merge that actually works. >>> Faster operations. Version large binaries. Built-in WAN optimization and >>> the >>> freedom to use Git, Perforce or both. Make the move to Perforce. >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Opensaf-users mailing list >>> Opensaf-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/opensaf-users >> >> ------------------------------------------------------------------------------ >> Subversion Kills Productivity. Get off Subversion & Make the Move to >> Perforce. >> With Perforce, you get hassle-free workflows. Merge that actually works. >> Faster operations. Version large binaries. Built-in WAN optimization and the >> freedom to use Git, Perforce or both. Make the move to Perforce. >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Opensaf-users mailing list >> Opensaf-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/opensaf-users > > ________________________________ > The information transmitted herein is intended only for the person or entity > to which it is addressed and may contain confidential, proprietary and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Opensaf-users mailing list Opensaf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-users
