Informatica Ultra Messaging (Version 6.1)

Concepts Guide

Informatica Ultra Messaging Concepts Guide

Version 6.1April 2013

Copyright (c) 2004-2013 Informatica Corporation. All rights reserved.

This software and documentation contain proprietary information of Informatica Corporation and are provided under a license agreement containing restrictions on use anddisclosure and are also protected by copyright law. Reverse engineering of the software is prohibited. No part of this document may be reproduced or transmitted in any form, by anymeans (electronic, photocopying, recording or otherwise) without prior consent of Informatica Corporation. This Software may be protected by U.S. and/or international Patents andother Patents Pending.

Use, duplication, or disclosure of the Software by the U.S. Government is subject to the restrictions set forth in the applicable software license agreement and as provided in DFARS227.7202-1(a) and 227.7702-3(a) (1995), DFARS 252.227-7013©(1)(ii) (OCT 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14 (ALT III), as applicable.

The information in this product or documentation is subject to change without notice. If you find any problems in this product or documentation, please report them to us inwriting.

Informatica, Informatica Platform, Informatica Data Services, PowerCenter, PowerCenterRT, PowerCenter Connect, PowerCenter Data Analyzer, PowerExchange, PowerMart,Metadata Manager, Informatica Data Quality, Informatica Data Explorer, Informatica B2B Data Transformation, Informatica B2B Data Exchange Informatica On Demand,Informatica Identity Resolution, Informatica Application Information Lifecycle Management, Informatica Complex Event Processing, Ultra Messaging and Informatica Master DataManagement are trademarks or registered trademarks of Informatica Corporation in the United States and in jurisdictions throughout the world. All other company and productnames may be trade names or trademarks of their respective owners.

Portions of this software and/or documentation are subject to copyright held by third parties, including without limitation: Copyright DataDirect Technologies. All rights reserved.Copyright © Sun Microsystems. All rights reserved. Copyright © RSA Security Inc. All Rights Reserved. Copyright © Ordinal Technology Corp. All rights reserved.Copyright ©Aandacht c.v. All rights reserved. Copyright Genivia, Inc. All rights reserved. Copyright Isomorphic Software. All rights reserved. Copyright © Meta Integration Technology, Inc. Allrights reserved. Copyright © Intalio. All rights reserved. Copyright © Oracle. All rights reserved. Copyright © Adobe Systems Incorporated. All rights reserved. Copyright © DataArt,Inc. All rights reserved. Copyright © ComponentSource. All rights reserved. Copyright © Microsoft Corporation. All rights reserved. Copyright © Rogue Wave Software, Inc. All rightsreserved. Copyright © Teradata Corporation. All rights reserved. Copyright © Yahoo! Inc. All rights reserved. Copyright © Glyph & Cog, LLC. All rights reserved. Copyright ©Thinkmap, Inc. All rights reserved. Copyright © Clearpace Software Limited. All rights reserved. Copyright © Information Builders, Inc. All rights reserved. Copyright © OSS Nokalva,Inc. All rights reserved. Copyright Edifecs, Inc. All rights reserved. Copyright Cleo Communications, Inc. All rights reserved. Copyright © International Organization forStandardization 1986. All rights reserved. Copyright © ej-technologies GmbH. All rights reserved. Copyright © Jaspersoft Corporation. All rights reserved. Copyright © isInternational Business Machines Corporation. All rights reserved. Copyright © yWorks GmbH. All rights reserved. Copyright © Lucent Technologies. All rights reserved. Copyright(c) University of Toronto. All rights reserved. Copyright © Daniel Veillard. All rights reserved. Copyright © Unicode, Inc. Copyright IBM Corp. All rights reserved. Copyright ©MicroQuill Software Publishing, Inc. All rights reserved. Copyright © PassMark Software Pty Ltd. All rights reserved. Copyright © LogiXML, Inc. All rights reserved. Copyright ©2003-2010 Lorenzi Davide, All rights reserved. Copyright © Red Hat, Inc. All rights reserved. Copyright © The Board of Trustees of the Leland Stanford Junior University. All rightsreserved. Copyright © EMC Corporation. All rights reserved. Copyright © Flexera Software. All rights reserved. Copyright © Jinfonet Software. All rights reserved. Copyright © AppleInc. All rights reserved. Copyright © Telerik Inc. All rights reserved. Copyright © BEA Systems. All rights reserved.

This product includes software developed by the Apache Software Foundation (http://www.apache.org/), and/or other software which is licensed under various versions of theApache License (the "License"). You may obtain a copy of these Licenses at http://www.apache.org/licenses/. Unless required by applicable law or agreed to in writing, softwaredistributed under these Licenses is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the Licenses forthe specific language governing permissions and limitations under the Licenses.

This product includes software which was developed by Mozilla (http://www.mozilla.org/), software copyright The JBoss Group, LLC, all rights reserved; software copyright ©1999-2006 by Bruno Lowagie and Paulo Soares and other software which is licensed under various versions of the GNU Lesser General Public License Agreement, which may befound at http:// www.gnu.org/licenses/lgpl.html. The materials are provided free of charge by Informatica, "as-is", without warranty of any kind, either express or implied, includingbut not limited to the implied warranties of merchantability and fitness for a particular purpose.

The product includes ACE(TM) and TAO(TM) software copyrighted by Douglas C. Schmidt and his research group at Washington University, University of California, Irvine, andVanderbilt University, Copyright (©) 1993-2006, all rights reserved.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (copyright The OpenSSL Project. All Rights Reserved) and redistribution of thissoftware is subject to terms available at http://www.openssl.org and http://www.openssl.org/source/license.html.

This product includes Curl software which is Copyright 1996-2007, Daniel Stenberg, <daniel@haxx.se>. All Rights Reserved. Permissions and limitations regarding this softwareare subject to terms available at http://curl.haxx.se/docs/copyright.html. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is herebygranted, provided that the above copyright notice and this permission notice appear in all copies.

The product includes software copyright 2001-2005 (©) MetaStuff, Ltd. All Rights Reserved. Permissions and limitations regarding this software are subject to terms available athttp://www.dom4j.org/ license.html.

The product includes software copyright © 2004-2007, The Dojo Foundation. All Rights Reserved. Permissions and limitations regarding this software are subject to terms availableat http://dojotoolkit.org/license.

This product includes ICU software which is copyright International Business Machines Corporation and others. All rights reserved. Permissions and limitations regarding thissoftware are subject to terms available at http://source.icu-project.org/repos/icu/icu/trunk/license.html.

This product includes software copyright © 1996-2006 Per Bothner. All rights reserved. Your right to use such materials is set forth in the license which may be found at http://www.gnu.org/software/ kawa/Software-License.html.

This product includes OSSP UUID software which is Copyright © 2002 Ralf S. Engelschall, Copyright © 2002 The OSSP Project Copyright © 2002 Cable & Wireless Deutschland.Permissions and limitations regarding this software are subject to terms available at http://www.opensource.org/licenses/mit-license.php.

This product includes software developed by Boost (http://www.boost.org/) or under the Boost software license. Permissions and limitations regarding this software are subject toterms available at http:/ /www.boost.org/LICENSE_1_0.txt.

This product includes software copyright © 1997-2007 University of Cambridge. Permissions and limitations regarding this software are subject to terms available at http://www.pcre.org/license.txt.

This product includes software copyright © 2007 The Eclipse Foundation. All Rights Reserved. Permissions and limitations regarding this software are subject to terms available athttp:// www.eclipse.org/org/documents/epl-v10.php.

This product includes software licensed under the terms at http://www.tcl.tk/software/tcltk/license.html, http://www.bosrup.com/web/overlib/?License, http://www.stlport.org/doc/license.html, http:// asm.ow2.org/license.html, http://www.cryptix.org/LICENSE.TXT, http://hsqldb.org/web/hsqlLicense.html, http://httpunit.sourceforge.net/doc/ license.html,http://jung.sourceforge.net/license.txt , http://www.gzip.org/zlib/zlib_license.html, http://www.openldap.org/software/release/license.html, http://www.libssh2.org, http://slf4j.org/license.html, http://www.sente.ch/software/OpenSourceLicense.html, http://fusesource.com/downloads/license-agreements/fuse-message-broker-v-5-3- license-agreement;http://antlr.org/license.html; http://aopalliance.sourceforge.net/; http://www.bouncycastle.org/licence.html; http://www.jgraph.com/jgraphdownload.html; http://www.jcraft.com/jsch/LICENSE.txt; http://jotm.objectweb.org/bsd_license.html; . http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231; http://www.slf4j.org/license.html; http://nanoxml.sourceforge.net/orig/copyright.html; http://www.json.org/license.html; http://forge.ow2.org/projects/javaservice/, http://www.postgresql.org/about/licence.html, http://

www.sqlite.org/copyright.html, http://www.tcl.tk/software/tcltk/license.html, http://www.jaxen.org/faq.html, http://www.jdom.org/docs/faq.html, http://www.slf4j.org/license.html;http://www.iodbc.org/dataspace/iodbc/wiki/iODBC/License; http://www.keplerproject.org/md5/license.html; http://www.toedter.com/en/jcalendar/license.html; http://www.edankert.com/bounce/index.html; http://www.net-snmp.org/about/license.html; http://www.openmdx.org/#FAQ; http://www.php.net/license/3_01.txt; http://srp.stanford.edu/license.txt; http://www.schneier.com/blowfish.html; http://www.jmock.org/license.html; http://xsom.java.net; and http://benalman.com/about/license/; https://github.com/CreateJS/EaselJS/blob/master/src/easeljs/display/Bitmap.js; http://www.h2database.com/html/license.html#summary; and http://jsoncpp.sourceforge.net/LICENSE.

This product includes software licensed under the Academic Free License (http://www.opensource.org/licenses/afl-3.0.php), the Common Development and Distribution License(http://www.opensource.org/licenses/cddl1.php) the Common Public License (http://www.opensource.org/licenses/cpl1.0.php), the Sun Binary Code License AgreementSupplemental License Terms, the BSD License (http:// www.opensource.org/licenses/bsd-license.php) the MIT License (http://www.opensource.org/licenses/mit-license.php) andthe Artistic License (http://www.opensource.org/licenses/artistic-license-1.0).

This product includes software copyright © 2003-2006 Joe WaInes, 2006-2007 XStream Committers. All rights reserved. Permissions and limitations regarding this software aresubject to terms available at http://xstream.codehaus.org/license.html. This product includes software developed by the Indiana University Extreme! Lab. For further informationplease visit http://www.extreme.indiana.edu/.

This Software is protected by U.S. Patent Numbers 5,794,246; 6,014,670; 6,016,501; 6,029,178; 6,032,158; 6,035,307; 6,044,374; 6,092,086; 6,208,990; 6,339,775; 6,640,226;6,789,096; 6,820,077; 6,823,373; 6,850,947; 6,895,471; 7,117,215; 7,162,643; 7,243,110, 7,254,590; 7,281,001; 7,421,458; 7,496,588; 7,523,121; 7,584,422; 7676516; 7,720,842; 7,721,270; and 7,774,791, international Patents and other Patents Pending.

DISCLAIMER: Informatica Corporation provides this documentation "as is" without warranty of any kind, either express or implied, including, but not limited to, the impliedwarranties of noninfringement, merchantability, or use for a particular purpose. Informatica Corporation does not warrant that this software or documentation is error free. Theinformation provided in this software or documentation may include technical inaccuracies or typographical errors. The information in this software and documentation is subject tochange at any time without notice.

NOTICES

This Informatica product (the "Software") includes certain drivers (the "DataDirect Drivers") from DataDirect Technologies, an operating company of Progress Software Corporation("DataDirect") which are subject to the following terms and conditions:

1.THE DATADIRECT DRIVERS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITEDTO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.

2. IN NO EVENT WILL DATADIRECT OR ITS THIRD PARTY SUPPLIERS BE LIABLE TO THE END-USER CUSTOMER FOR ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, CONSEQUENTIAL OR OTHER DAMAGES ARISING OUT OF THE USE OF THE ODBC DRIVERS, WHETHER OR NOT INFORMED OF THEPOSSIBILITIES OF DAMAGES IN ADVANCE. THESE LIMITATIONS APPLY TO ALL CAUSES OF ACTION, INCLUDING, WITHOUT LIMITATION, BREACH OFCONTRACT, BREACH OF WARRANTY, NEGLIGENCE, STRICT LIABILITY, MISREPRESENTATION AND OTHER TORTS.

Part Number: UM-CPT-61000-0001

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vInformatica Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Informatica MySupport Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Informatica Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Informatica Web Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Informatica How-To Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Informatica Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Informatica Multimedia Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Informatica Marketplace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Informatica Global Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Chapter 1: Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2: Fundamental Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Topic Structure and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Late Join. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Request/Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Transports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Multi-Transport Threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Event Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Rate Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Operational Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 3: UM Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Context Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Topic Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Source Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Message Properties Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Source Configuration and Transport Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Zero Object Delivery (Source). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Receiver Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Receiver Configuration and Transport Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Wildcard Receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Zero Object Delivery (ZOD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Table of Contents i

Event Queue Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Transport Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Transport TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Transport TCP-LB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Transport LBT-RU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Transport LBT-RM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Transport LBT-IPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Transport LBT-SMX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Transport LBT-RDMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 4: Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Embedded Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Sequential Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Topic Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Multicast Topic Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Topic Resolution Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Topic Resolution Configuration Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Unicast Topic Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Message Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Implicit Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Adaptive Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Intelligent Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Explicit Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Application Batching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Ordered Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Sequence Number Order, Fragments Reassembled (Default Mode). . . . . . . . . . . . . . . . . . . . . 48

Arrival Order, Fragments Not Reassembled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Arrival Order, Fragments Reassembled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Loss Detection Using TSNIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Receiver Keepalive Using Sesssion Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 5: UMS Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Using Late Join. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Late Join Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Late Join Options Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Using Default Late Join Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Specifying a Range of Messages to Retransmit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Retransmitting Only Recent Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Configuring Late Join for Large Numbers of Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Off-Transport Recovery (OTR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

OTR Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

OTR with Sequence Number Ordered Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ii Table of Contents

OTR Options Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Request/Response Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Request Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Response Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

TCP Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Example Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Self Describing Messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Pre-Defined Messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Typical PDM Usage Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Using the PDM API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Migrating from SDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Multicast Immediate Messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Temporary Transport Session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Receiving Immediate Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

MIM Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

MIM Example Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Spectrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Performance Pluses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Configuration Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Hot Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Implementing Hot Failover Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Implementing Hot Failover Receivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Implementing Hot Failover Wildcard Receivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Java and .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Using Hot Failover with UMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Hot Failover Intentional Gap Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Hot Failover Optional Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Using Hot Failover with Ordered Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Hot Failover Across Multiple Contexts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapter 6: Monitoring UMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Why Monitor?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

What to Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

UMS API Functions and Data Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Context Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Event Queue Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Source or Receiver Transport Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

UMS Monitoring API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

UMS Monitoring Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

API Framework Flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table of Contents iii

Initial Monitoring Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Creating a Monitoring Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Specifying the Object to Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Receiving Monitoring Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

The UMS Transport Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

The UDP Transport Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

The SNMP Transport Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Automatic Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Monitoring Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

lbmmon.c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

lbmmonudp.c and lbmmondiag.pl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Interpreting LBT-RM Source Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Chapter 7: Manpage for lbmrd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98lbmrd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Chapter 8: UM Log Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99UM Core Log Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

UM Core API Log Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

UM Lbmrd Log Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

UM Dynamic Routing Log Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

iv Table of Contents

Preface

This document introduces important fundamental design concepts behind Ultra Messaging® high performancemessage streaming. Understanding these concepts is important to software developers designing and writingapplication code that uses the Ultra Messaging® Application Programming Interfaces (API).

Informatica Resources

Informatica MySupport PortalAs an Informatica customer, you can access the Informatica MySupport Portal at http://mysupport.informatica.com.

The site contains product information, user group information, newsletters, access to the Informatica customersupport case management system (ATLAS), the Informatica How-To Library, the Informatica Knowledge Base, theInformatica Multimedia Knowledge Base, Informatica Product Documentation, and access to the Informatica usercommunity.

Informatica DocumentationThe Informatica Documentation team takes every effort to create accurate, usable documentation. If you havequestions, comments, or ideas about this documentation, contact the Informatica Documentation team through emailat infa_documentation@informatica.com. We will use your feedback to improve our documentation. Let us know if wecan contact you regarding your comments.

The Documentation team updates documentation as needed. To get the latest documentation for your product,navigate to Product Documentation from http://mysupport.informatica.com.

Informatica Web SiteYou can access the Informatica corporate web site at http://www.informatica.com. The site contains information aboutInformatica, its background, upcoming events, and sales offices. You will also find product and partner information.The services area of the site includes important information about technical support, training and education, andimplementation services.

Informatica How-To LibraryAs an Informatica customer, you can access the Informatica How-To Library at http://mysupport.informatica.com. TheHow-To Library is a collection of resources to help you learn more about Informatica products and features. It includesarticles and interactive demonstrations that provide solutions to common problems, compare features and behaviors,and guide you through performing specific real-world tasks.

v

Informatica Knowledge BaseAs an Informatica customer, you can access the Informatica Knowledge Base at http://mysupport.informatica.com.Use the Knowledge Base to search for documented solutions to known technical issues about Informatica products.You can also find answers to frequently asked questions, technical white papers, and technical tips. If you havequestions, comments, or ideas about the Knowledge Base, contact the Informatica Knowledge Base team throughemail at KB_Feedback@informatica.com.

Informatica Multimedia Knowledge BaseAs an Informatica customer, you can access the Informatica Multimedia Knowledge Base at http://mysupport.informatica.com. The Multimedia Knowledge Base is a collection of instructional multimedia files thathelp you learn about common concepts and guide you through performing specific tasks. If you have questions,comments, or ideas about the Multimedia Knowledge Base, contact the Informatica Knowledge Base team throughemail at KB_Feedback@informatica.com.

Informatica MarketplaceThe Informatica Marketplace is a forum where developers and partners can share solutions that augment, extend, orenhance data integration implementations. By leveraging any of the hundreds of solutions available on theMarketplace, you can improve your productivity and speed up time to implementation on your projects. You canaccess Informatica Marketplace at http://www.informaticamarketplace.com.

Informatica Global Customer SupportYou can contact a Customer Support Center by telephone or through the Online Support. Online Support requires auser name and password. You can request a user name and password at http://mysupport.informatica.com.

Use the following telephone numbers to contact Informatica Global Customer Support:

North America / South America Europe / Middle East / Africa Asia / Australia

Toll FreeBrazil: 0800 891 0202Mexico: 001 888 209 8853North America: +1 877 463 2435

Toll FreeFrance: 0805 804632Germany: 0800 5891281Italy: 800 915 985Netherlands: 0800 2300001Portugal: 800 208 360Spain: 900 813 166Switzerland: 0800 463 200United Kingdom: 0800 023 4632

Standard RateBelgium: +31 30 6022 797France: +33 1 4138 9226Germany: +49 1805 702 702Netherlands: +31 306 022 797United Kingdom: +44 1628 511445

Toll FreeAustralia: 1 800 151 830New Zealand: 09 9 128 901

Standard RateIndia: +91 80 4112 5738

vi Preface

C H A P T E R 1

OverviewThis chapter includes the following topics:

¨ Preface, 1

¨ Introduction, 1

Preface. This document introduces important fundamental design concepts behind Ultra Messaging high performancemessage streaming (UMS). Understanding these concepts is important to software developers designing and writingapplication code that uses UMS.

IntroductionUM is a software layer, supplied in the form of a dynamic library (shared object), which provides applications withmessage delivery functionality that adds considerable value to the basic networking services contained in the hostoperating system. The application accesses the messaging functionality through the Ultra Messaging ApplicationProgramming Interface (API).

There are actually four APIs: the UM C API, the UM Java API, the UM .NET API . These APIs are very similar, and forthe most part this document concentrates on the C API. The translation from C functions to Java or .NET methodsshould be reasonably straightforward; see the UM Quick Start Guide for sample applications in Java and .NET.

The two most important design goals of UMS are to minimize message latency (the time that a given message spends"in transit") and maximize throughput. Ultra Messaging achieves these goals by not duplicating services provided bythe underlying network whenever possible. Instead of implementing special messaging servers and daemons toreceive and re-transmit messages, Ultra Messaging routes messages primarily with the network infrastructure at wirespeed. Placing little or nothing in between the sender and receiver is an important and unique design principle of UltraMessaging.

1

C H A P T E R 2

Fundamental ConceptsThis chapter includes the following topics:

¨ Overview, 2

¨ Topic Structure and Management, 2

¨ Late Join, 3

¨ Request/Response, 3

¨ Transports, 3

¨ Event Delivery, 5

¨ Rate Controls, 5

¨ Operational Statistics, 6

OverviewA UM application can function either as a source or a receiver. A source application sends messages, and a receiverapplication receives them. (It is also common for an application to function as both source and receiver; we separatethe concepts for organizational purposes.)

Topic Structure and ManagementUM offers the Publish/Subscribe model for messaging ("Pub/Sub"), whereby one or more receiver programs expressinterest in a topic, and one or more source programs send to that topic. So, a topic can be thought of as a data streamthat can have multiple producers and multiple consumers. One of the functions of the messaging layer is to make surethat all messages sent to a given topic are distributed to all receivers listening to that topic. UM does this through anautomatic process known as topic resolution.

A topic is just an arbitrary string. For example:

Deals

Market/US/DJIA/Sym1

It is not unusual for an application system to have many thousands of topics, perhaps even more than a million, witheach one carrying a very specific range of information (e.g. quotes for a single stock symbol).

2

It is also possible to configure receiving programs to match multiple topics using wildcards. UM uses powerful regularexpression pattern matching to allow applications to match topics in a very flexible way. At the present time, messagescannot be sent to wildcarded topic names. See “Wildcard Receiver” on page 10.

Late JoinIn many applications, a new receiver may be interested in messages that were sent before it existed. UM provides alate join feature that allows a new receiver to join a group of others already listening to a source. Without the late joinfeature, the joining receiver would only receive messages sent after the time it joined. With late join, the source storessent messages according to its Late Join configuration options so a joining receiver can receive any of thesemessages that were sent before it joined the group. See “Using Late Join” on page 50.

Request/ResponseUM also offers a Request/Response messaging model. A sending application (the requester) sends a message to atopic. Every receiving application listening to that topic gets a copy of the request. One or more of those receivingapplications (responder) can then send one or more responses back to the original requester. UM sends the requestmessage via the normal pub/sub method, whereas UM delivers the response message directly to the requester.

An important aspect of UM's Request/Response model is that it allows the application to keep track of which requestcorresponds to a given response. Due to the asynchronous nature of UM requests, any number of requests can beoutstanding, and as the responses come in, they can be matched to their corresponding requests.

Request/Response can be used in many ways and is often used during the initialization of UM receiver objects. Whenan application starts a receiver, it can issue a request on the topic the receiver is interested in. Source objects for thetopic can respond and begin publishing data. This method prevents the UM source objects from publishing to a topicwithout subscribers.

Be careful not to be confused with the sending/receiving terminology. Any application can send a request, includingone that creates and manages UM receiver objects. And any application can receive and respond to a request,including one that creates and manages UM source objects.

See “Request/Response Model” on page 57.

TransportsA source application uses an UMS transport to send messages to a receiver application. A UM transport is built on topof a standard IP protocol. The different UM transport types have different tradeoffs in terms of latency, scalability,throughput, bandwidth sharing, and flexibility. The sending application chooses the transport type that is mostappropriate for the data being sent, at the topic level. A programmer might choose different transport types fordifferent topics within the same application.

A UM sending application can make use of very many topics (over a million). UM maps those topics onto a muchsmaller number of transport sessions. A transport session can be thought of as a specific instance of a transport type.A given transport session might carry a single topic, or might carry hundreds of thousands of topics. A receivingapplication may express interest in a small set of those topics, in which case UM will join the transport session,receiving messages for all topics carried on that transport session. UM will then discard any messages for topics that

Late Join 3

the application is not interested in. This user-space filtering does consume system resources (primarily CPU andbandwidth), and can be minimized by carefully mapping topics onto transport sessions according to receivingapplication interest.

When UM sets up a transport session and receives the first data over the live data stream, UM generates a BOS(Beginning Of Session) to all receivers that currently exist. When a receiver joins an active transport, this immediatelygenerates a BOS event. When the last topic on a transport session concludes or when a transport path is broken in thenetwork (also referred to as a TCP breakage), UM tears down the transport session and notifies all receivers with anEOS (End Of Session) event. There is no correlation between the deletion of a source by an application and when anEOS is received by a receiver, except if it is the last source sharing the transport.

Note: Non-multicast UM transport types can also use source-side filtering to decrease user-space filtering on thereceiving side by doing the filtering on the sending side. However, while this might sound attractive at first glance, beaware that system resources consumed on the source side affect all receivers, and that the filtering for multiplereceivers must be done serially, whereas letting the receivers do the filtering allows that filtering to be done in parallel,only affecting those receivers that need the filtering.

See “Transport Objects” on page 12.

Multi-Transport ThreadsPart of UM's design is a single threaded model for message data delivery which reduces latency in the receiving CPU.UM, however, also has the ability to distribute data delivery across multiple CPUs by using a receiving thread pool.Receivers created with the configuration option, use_transport_thread set to 1 use a thread from the thread poolinstead of the context thread. The option, receive_thread_pool_size controls the pool size.

As receivers discover new sources through Topic Resolution, UM assigns the network sockets created for thereceivers to receive data to either the context thread (default) or to a thread from the pool if use_transport_thread isset for the receiver. It is important to understand that thread assignment occurs at the socket level - not the transportlevel. Transports aggregated on to the same network socket use the same thread.

UM distributes data from different sockets to different threads allowing better process distribution and higheraggregate throughput. Distributing transports across threads also ensures that activity on each transport has noimpact on transports assigned to other threads leading to lower latencies in some traffic patterns, e.g. heavy lossconditions.

The following lists restrictions to using multi-transport threads.

¨ Only LBT-RM, LBT-RU, TCP and TCP-LB transport types may be distributed to threads.

¨ Multi-Transport threads are not supported under sequential mode .

¨ UM processes sources using the same transport socket, e.g. multicast address and port, on the same thread(regardless of the use_transport_thread setting. To leverage threading of different sources, assign each source toa different transport destination, e.g. multicast address/port.

¨ Hot failover sources using LBT-RM on the same topic must not be distributed across threads because they mustshare the same multicast address and port.

¨ Hot failover sources using other transport types may not be distributed across threads and must use the contextthread.

¨ Each transport thread has its own Unicast Listener (request) port. Ultra Messaging recommends that you expandthe range request_tcp_port_low - request_tcp_port_high to a larger range when using transport threads. Whenlate join is occurring, UM creates a TCP connection from the transport thread to the source.

¨ Multi-transport threads are not recommended for use over the UM Router.

¨ Multi-Transport Threads are not compatible with UMDS Server or UMCache

4 Chapter 2: Fundamental Concepts

Event DeliveryThere are many different events that UM may want to deliver to the application. Many events carry data with them (e.g.received messages); some do not (e.g. end-of-stream events). Some examples of UM events:

1. A received message on a topic that the application has expressed interest in.

2. A timer expiring. Applications can schedule timers to expire in a desired number of milliseconds (although the OSmay not deliver them with millisecond precision).

3. An application-managed file descriptor event. The application can register its own file descriptors with UM to bemonitored for state changes (readable, writable, error, etc).

4. New source notification. UM can inform the application when sources are discovered by topic resolution.

5. Receiver loss. UM can inform the application when a data gap is detected that could not be recovered through thenormal retransmission mechanism.

6. End of Stream. UM can inform a receiving application when a data stream (transport session) has terminated.

UM delivers events to the application by callbacks. The application explicitly gives UM a pointer to one of its functionsto be the handler for a particular event, and UM calls that function to deliver the event, passing it the parameters thatthe application requires to process the event. In particular, the last parameter of each callback type is a client datapointer (clientdp). This pointer can be used at the application's discretion for any purpose. It's value is specified by theapplication when the callback function is identified to UM (typically when UM objects are created), and that same valueis passed back to the application when the callback function is called.

There are two methods that UM can use to call the application callbacks: through context thread callback, or eventqueue dispatch.

In the context thread callback method (sometimes called direct callback), the UM context thread calls the applicationfunction directly. This offers the lowest latency, but imposes significant restrictions on the application function. See “Event Queue Object” on page 11.

The event queue dispatch of application callback introduces a dynamic buffer into which the UM context thread writesevents. The application then uses a thread of its own to dispatch the buffered events. Thus, the application callbackfunctions are called from the application thread, not directly from the context thread.

With event queue dispatching, the use of the application thread to make the callback allows the application function tomake full, unrestricted use of the UM API. It also allows parallel execution of UM processing and applicationprocessing, which can significantly improve throughput on multi-processor hardware. The dynamic buffering providesresilience between the rate of event generation and the rate of event consumption (e.g. message arrival rate v.s.message processing rate).

In addition, an UM event queue allows the application to be warned when the queue exceeds a threshold of eventcount or event latency. This allows the application to take corrective action if it is running too slow, such as throwingaway all events older than a threshold, or all events that are below a given priority.

Rate ControlsFor UDP-based transports (LBT-RU and LBT-RM), UM network stability is insured through the use of rate controls.Without rate controls, sources can send UDP data so fast that the network can be flooded. Using rate controls, thesource's bandwidth usage is limited. If the source attempts to exceed its bandwidth allocation, it is slowed down.

Setting the rate controls properly requires some planning; see"Topics in High Performance Messaging, Group Rate Control" for details.

Event Delivery 5

Operational StatisticsUM maintains a variety of transport-level statistics which gives a real-time snapshot of UM's internal handling. Forexample, it gives counts for transport messages transferred, bytes transferred, retransmissions requested,unrecoverable loss, etc.

The UM monitoring API provides framework to allow the convenient gathering and transmission of UM statistics to acentral monitoring point. See Chapter 6, “Monitoring UMS” on page 83.

6 Chapter 2: Fundamental Concepts

C H A P T E R 3

UM ObjectsThis chapter includes the following topics:

¨ Overview, 7

¨ Context Object, 7

¨ Topic Object, 8

¨ Source Object, 8

¨ Receiver Object, 10

¨ Event Queue Object, 11

¨ Transport Objects, 12

OverviewMany UM documents use the term object. Be aware that with the C API, they do not refer to formal objects assupported by C++ (i.e. class instances). The term is used here in an informal sense to denote an entity that can becreated, used, and (usually) deleted, has functionality and data associated with it, and is managed through the API.The handle that is used to refer to an object is usually implemented as a pointer to a data structure (defined in lbm.h),but the internal structure of an object is said to be opaque, meaning that application code should not read or write thestructure directly.

However, the UM Java JNI and C# .NET APIs are object oriented, with formal Java/C# objects. See the Java APIdocumentation and .NET API documentation for more information.

Context ObjectA UM context object conceptually is an environment in which UM runs. An application creates a context, typicallyduring initialization, and uses it for most other UM operations. In the process of creating the context, UM normallystarts an independent thread (the context thread) to do the necessary background processing such as thefollowing.

¨ Topic resolution

¨ Enforce rate controls for sending messages

¨ Manage timers

¨ Manage state

7

¨ Implement UM protocols

¨ Manage transport sessions

You create a context with lbm_context_create(). Your application can give a context a name, which are optional butshould be unique across your UM network. You can set a context name before calling lbm_context_create() in thefollowing ways.

¨ If you are using XML UM configuration files, call lbm_context_attr_set_from_xml() orlbm_context_attr_create_from_xml() and set the name in the context_name parameter.

¨ If you are using plain text UM configuration files, call lbm_context_attr_setopt() and specify context_name as theoptname and the context's name as the optval. Don't forget to set the optlen.

¨ Create a plain text UM configuration file with the option context_name set to the name of the context.

Context names are optional but should be unique within a process. UM does not enforce uniqueness, rather issues alog warning if it encounters duplicate context names. Application context names are only used to load template andindividual option values within an XML UM configuration file.

One of the more important functions of a context is to hold configuration information that is of context scope. See theUM Configuration Guide for options that are of context scope.

Most UM applications create a single context. However, there are some specialized circumstances where anapplication would create multiple contexts. For example, with appropriate configuration options, two contexts canprovide separate topic name spaces. Also, multiple contexts can be used to portion available bandwidth across topicsub-spaces (in effect allocating more bandwidth to high-priority topics).

Attention: Regardless of the number of contexts created by your application, a good practice is to keep them openthroughout the life of your application. Do not close them until you close the application.

Topic ObjectA UM topic object is conceptually very simple; it is little more than a string (the topic name). However, UM uses thetopic object to hold a variety of state information used by UM for internal processing. It is conceptually contained withina context. Topic objects must be bound to source or receiver objects.

A data source creates a topic by calling lbm_src_topic_alloc(). A data receiver doesn't explicitly create topic objects;UM does that as topics are discovered and cached. Instead, the receiving application calls lbm_rcv_topic_lookup()to find the topic object.

Unlike other objects, the topic object is not created or deleted by the application. UM creates, manages and deletesthem internally as needed. However, the application does use them, so the API has functions that give the applicationaccess to them when needed (lbm_src_topic_alloc() and lbm_rcv_topic_lookup()).

Source ObjectA UM source object is used to send messages to the topic that it is bound to. It is conceptually contained within acontext.

You create a source object by calling lbm_src_create(). One of its parameters is a topic object that must have beenpreviously allocated. A source object can be bound to only one topic. (A topic object, however, can be bound to manysources provided the sources exist in separate contexts.)

8 Chapter 3: UM Objects

Message Properties ObjectThe message property object allows your application to insert named, typed metadata to topic messages andimplement functionality that depends on the message properties. UM allows eight property types: boolean, byte,short, int, long, float, double, and string.

To use message properties, create a message properties object with lbm_msg_properties_create(). Then sendtopic messages with lbm_src_send_ex() (or LBMSource.send() in the Java API or .NET API) passing the messageproperties object through lbm_src_send_ex_info_t object. Set the LBM_SRC_SEND_EX_FLAG_PROPERTIESflag on the lbm_src_send_ex_info_t object to indicate that it includes properties.

Upon a receipt of a message with properties, your application can access the properties directly through themessages properties field, which is null if no properties are present. Individual property values can be retrieveddirectly by name, or you can iterate over the collection of properties to determine which properties are present atruntime.

To mitigate any performance impacts in the C API, reuse properties objects, lbm_src_send_ex_info_t objects anditerators whenever possible. Also limit the number of properties associated with a message. (UM sends the propertyname and additional indexing information with every message.) In the Java API or .NET API, also make use of theZOD feature by calling Dispose() on each message before returning from the application callback. This allowsproperty objects to be reused as well.

Note: The Message Properties Object does not support receivers using the arrival order without reassembly setting(option value = 0) of ordered_delivery .

Source Configuration and Transport SessionsAs with contexts, a source holds configuration information that is of source scope. This includes network options,operational options and reliability options for LBT-RU and LBT-RM. For example, each source can use a differenttransport and would therefore configure a different network address to which to send topic messages. See the UMConfiguration Guide for source configuration options.

As stated in “Transports” on page 3, many topics (and therefore sources) can be mapped to a single transport. Many ofthe configuration options for sources actually control or influence transport session activity. If many sources aresending topic messages over a single transport session (TCP, LBT-RU or LBT-RM), UM only uses the configurationoptions for the first source assigned to the transport.

For example, if the first source to use a LBT-RM transport session sets thetransport_lbtrm_transmission_window_size to 24 MB and the second source sets the same option to 2 MB, UMSassigns 24 MB to the transport session's transport_lbtrm_transmission_window_size .

The UM Configuration Guide identifies the source configuration options that may be ignored when UM assigns thesource to an existing transport session. Log file warnings also appear when UM ignores source configurationoptions.

Zero Object Delivery (Source)The Zero Object Delivery (ZOD) feature for Java and .NET lets sources deliver events to an application with no per-event object creation. (ZOD can also be utilized with context source events.) See “Zero Object Delivery (ZOD)” onpage 10 for information on how to employ ZOD.

Source Object 9

Receiver ObjectA UM receiver object is used to receive messages from the topic that it is bound to. It is conceptually contained within acontext. Messages are delivered to the application by an application callback function, specified when the receiverobject is created.

You create a receiver object by calling lbm_rcv_create(). One of its parameters is a topic object that must have beenpreviously looked up. A receiver object can be bound to only one topic. Multiple receiver objects can be created for thesame topic.

Receiver Configuration and Transport SessionsA receiver holds configuration information that is of receiver scope. This includes network options, operational optionsand reliability options for LBT-RU and LBT-RM. See the UM Configuration Guide for receiver configuration options.

As stated above in “Source Configuration and Transport Sessions” on page 9, many topics (and therefore receivers)can be mapped to a single transport. As with source configuration options, many receiver configuration options controlor influence transport session activity. If many receivers are receiving topic messages over a single transport session(TCP, LBT-RU or LBT-RM), UM only uses the configuration options for the first receiver assigned to the transport.

For example, if the first receiver to use a LBT-RM transport session sets thetransport_lbtrm_nak_generation_interval to 10 seconds and the second receiver sets the same option to 2 seconds,UMS assigns 10 seconds to the transport session's transport_lbtrm_nak_generation_interval .

The UM Configuration Guide identifies the receiver configuration options that may be ignored when UM assigns thereceiver to an existing transport session. Log file warnings also appear when UM ignores receiver configurationoptions.

Wildcard ReceiverYou create a wildcard receiver object by calling lbm_wildcard_rcv_create(). Instead of a topic object, the callersupplies a pattern which UM uses to match multiple topics. Because the application does not explicitly lookup thetopics, UM passes the topic attribute into lbm_wildcard_rcv_create() so that it can set options. Also, wildcardreceivers have their own set of options, such as pattern type.

The wildcard pattern supplied for matching is a PCRE regular expression that Perl recognizes. See http://perldoc.perl.org/perlrequick.html for details about PCRE. See also the wildcard_receiver pattern_type option inthe UM Configuration Guide.

Note: Ultra Messaging has deprecated two other wildcard receiver pattern types, regex POSIX extended regularexpressions and appcb application callback, as of UM Version 6.1.

Be aware that some platforms may not support all of the regular expression wildcard types. For example, UM does notsupport the use of Unicode PCRE characters in wildcard receiver patterns on any system that communicates with aHP-UX or AIX system. See the Informatica Knowledgebase article, Platform-Specific Dependencies for details.

For an example of wildcard usage, see lbmwrcv.c

TIBCO™ SmartSockets™ users see the Informatica Knowledgebase article, Wildcard Topic Regular Expressions.

Zero Object Delivery (ZOD)The Zero Object Delivery (ZOD) feature for Java and .NET lets receivers (and sources) deliver messages and eventsto an application with no per-message or per-event object creation. This facilitates source/receiver applications thatwould require little to no garbage collection at runtime, producing lower and more consistent message latencies.

10 Chapter 3: UM Objects

To take advantage of this feature, you must call dispose() on a message to mark it as available for reuse. To accessdata from the message when using ZOD, you use a specific pair of LBMMessage-class methods (see below) to extractmessage data directly from the message, rather than the standard data() method. Using the latter method creates abyte array, and consequently, an object. It is the subsequent garbage collecting to recycle those objects that canaffect performance.

For using ZOD, the LBMMessage class methods are:

¨ Java: dispose(), dataBuffer(), and dataLength()

¨ .NET: dispose(), dataPointer(), and length()

On the other hand, you may need to keep the message as an object for further use after callback. In this case, ZOD isnot appropriate and you must call promote() on the message, and also you can use data() to extract messagedata.

For more details see the Java API Overview or the .Net LBMMessage Class description. This feature does not applyto the C API.

Event Queue ObjectA UM event queue object is conceptually a managed data and control buffer. UM delivers events (including receivedmessages) to your application by means of application callback functions. Without event queues, these callbackfunctions are called from the UM context thread, which places the following restrictions on the application functionbeing called:

1. The application function is not allowed to make certain API calls (mostly having to do with creating or deleting UMobjects).

2. The application function must execute very quickly without blocking.

3. The application does not have control over when the callback executes. It can't prevent callbacks during criticalsections of application code.

Some circumstances require the use of UM event queues. As mentioned above, if the receive callback needs to useUM functions that create or delete objects. Or if the receive callback performs operations that potentially block. Youmay also want to use an event queue if the receive callback is CPU intensive and can make good use of multiple CPUhardware. Not using an event queue provides the lowest latency, however, high message rates or extensive messageprocessing can negate the low latency benefit if the context thread continually blocks.

Of course, your application can create its own queues, which can be bounded, blocking queues or unbounded, non-blocking queues. For transports that are flow-controlled, a bounded, blocking application queue preserves flowcontrol in your messaging layer because the effect of a filled or blocked queue extends through the message path allthe way to source. The speed of the application queue becomes the speed of the source.

UM event queues are unbounded, non-blocking queues and provide the following unique features.

1. Your application can set a queue size threshold with queue_size_warning and be warned when the queuecontains too many messages.

2. Your application can set a delay threshold with queue_delay_warning and be warned when events have been inthe queue for too long.

3. The application callback function has no UM API restrictions.

4. Your application can control exactly when UM delivers queued events with lbm_event_dispatch(). And you canhave control return to your application either when specifically asked to do so (by callinglbm_event_dispatch_unblock()), or optionally when there are no events left to deliver.

Event Queue Object 11

5. Your application can take advantage of parallel processing on multiple processor hardware since UM processesasynchronously on a separate thread from your application's processing of received messages. By using multipleapplication threads to dispatch an event queue, or by using multiple event queues, each with its own dispatchthread, your application can further increase parallelism.

You create an UM event queue in the C API by calling lbm_event_queue_create(). In the Java API and the .NET API,use the LBMEventQueue class. An event queue object also holds configuration information that is of event queue scope.See Event Queue Options.

Transport ObjectsThis section discusses the following topics.

¨ “Transport TCP” on page 12

¨ “Transport TCP-LB” on page 13

¨ “Transport LBT-RU” on page 13

¨ “Transport LBT-RM” on page 13

¨ “Transport LBT-IPC” on page 14

¨ “Transport LBT-SMX” on page 20

¨ “Transport LBT-RDMA” on page 31

Transport TCPThe TCP UM transport uses normal TCP connections to send messages from sources to receivers. This is the defaulttransport when it's not explicitly set. TCP is a good choice when:

1. Flow control is desired. For example, when one or more receivers cannot keep up, you wish to slow down thesource. This is a "better late than never" philosophy.

2. Equal bandwidth sharing with other TCP traffic is desired. I.e. when it is desired that the source slow down whengeneral network traffic becomes heavy.

3. There are few receivers listening to each topic. Multiple receivers for a topic requires multiple transmissions ofeach message, which places a scaling burden on the source machine and the network.

4. The application is not sensitive to latency. Use of TCP as a messaging transport can result in unboundedlatency.

5. The messages must pass through a restrictive firewall which does not pass multicast traffic.

UM's TCP transport includes a Session ID. A UM source using the TCP transport generates a unique, 32-bit non-zerorandom Session ID for each TCP transport (IP:port) it uses. The source also includes the Session ID in its TopicResolution advertisement (TIR). When a receiver resolves its topic and discovers the transport information, thereceiver also obtains the transport's Session ID. The receiver sends a message to the source to confirm the SessionID.

The TCP Session ID enables multiple receivers for a topic to connect to a source across UM Router(s). In the event ofa UM Router failure, UM establishes new topic routes which can cause cached Topic Resolution and transportinformation to be outdated. Receivers use this cached information to find sources. Session IDs add a unique identifierto the cached transport information. If a receiver tries to connect to a source with outdated transport information, thesource recognizes an incorrect Session ID and disconnects the receiver. The receiver can then attempt to reconnectwith different cached transport information.

12 Chapter 3: UM Objects

You can turn off TCP Session IDs with the UM configuration option, transport_tcp_use_session_id .

Note: TCP transports may be distributed to receiving threads. See “Multi-Transport Threads” on page 4 for moreinformation.

Transport TCP-LBThe TCP-LB UMS transport is a variation on the TCP transport which adds latency-bounded behavior. The source isnot flow-controlled as a result of network congestion or slow receivers. So, for applications that require a "better neverthan late" philosophy, TCP-LB can be a better choice.

However, latency cannot be controlled as tightly as with UDP-based transports (see below). In particular, latency canstill be introduced because TCP-LB shares bandwidth equally with other TCP traffic. It also has the same scalingissues as TCP when multiple receivers are present for each topic.

Note: TCP-LB transports may be distributed to receiving threads. See “Multi-Transport Threads” on page 4 for moreinformation.

Transport LBT-RUThe LBT-RU UMS transport adds reliable delivery to unicast UDP to send messages from sources to receivers. Thisprovides greater flexibility in the control of latency. For example, the application can further limit latency by allowingthe use of arrival order delivery. See the UM Knowledgebase FAQ, Why can't I have low-latency delivery and in-orderdelivery?. Also, LBT-RU is less sensitive to overall network load; it uses source rate controls to limit its maximum sendrate.

Since it is based on unicast addressing, LBT-RU can pass through most firewalls. However, it has the same scalingissues as TCP when multiple receivers are present for each topic.

UM's LBT-RU transport includes a Session ID. A UM source using the LBT-RU transport generates a unique, 32-bitnon-zero random Session ID for each transport it uses. The source also includes the Session ID in its Topic Resolutionadvertisement (TIR). When a receiver resolves its topic and discovers the transport information, the receiver alsoobtains the transport's Session ID.

The LBT-RU Session ID enables multiple receivers for a topic to connect to a source across UM Router(s). In theevent of a UM Router failure, UM establishes new topic routes which can cause cached Topic Resolution andtransport information to be outdated. Receivers use this cached information to find sources. Session IDs add a uniqueidentifier to the cached transport information. If a receiver tries to connect to a source with outdated transportinformation, the transport drops the received data and times out. The receiver can then attempt to reconnect withdifferent cached transport information.

You can turn off LBT-RU Session IDs with the UM configuration option, transport_lbtru_use_session_id .

Note: LBT-RU can use Datagram Bypass Layer (DBL) acceleration in conjunction with DBL-enabled Myricom 10-Gigabit Ethernet NICs for Linux and Microsoft Windows. DBL is a kernel-bypass technology that accelerates sendingand receiving UDP traffic. See Transport Acceleration Options in the UM configuration Guide for more information.

Note: LBT-RU transports may be distributed to receiving threads. See “Multi-Transport Threads” on page 4 for moreinformation.

Transport LBT-RMThe LBT-RM transport adds reliable multicast to UDP to send messages. This provides the maximum flexibility in thecontrol of latency. In addition, LBT-RM can scale effectively to large numbers of receivers per topic using networkhardware to duplicate messages only when necessary at wire speed. One limitation is that multicast is often blockedby firewalls.

Transport Objects 13

LBT-RM is a UDP-based, reliable multicast protocol designed with the use of UM and its target applicationsspecifically in mind. The protocol is very similar to PGM, but with changes to aid low latency messagingapplications.

¨ Topic Mapping - Several topics may map onto the same LBT-RM session. Thus a multiplexing mechanism toLBT-RM is used to distinguish topic level concerns from LBT-RM session level concerns (such as retransmissions,etc.). Each message to a topic is given a sequence number in addition to the sequence number used at the LBT-RM session level for packet retransmission.

¨ Negative Acknowledgments (NAKs) - LBT-RM uses NAKs as PGM does. NAKs are unicast to the sender. Forsimplicity, LBT-RM uses a similar NAK state management approach as PGM specifies.

¨ Time Bounded Recovery - LBT-RM allows receivers to specify a a maximum time to wait for a lost piece of data tobe retransmitted. This allows a recovery time bound to be placed on data that has a definite lifetime of usefulness.If this time limit is exceeded and no retransmission has been seen, then the piece of data is marked as anunrecoverable loss and the application is informed. The data stream may continue and the unrecoverable loss willbe ordered as a discrete event in the data stream just as a normal piece of data.

¨ Flexible Delivery Ordering - LBT-RM receivers have the option to have the data for an individual topic delivered"in order" or "arrival order". Messages delivered "in order" will arrive in sequence number order to the application.Thus loss may delay messages from being delivered until the loss is recovered or unrecoverable loss isdetermined. With "arrival-order" delivery, messages will arrive at the application as they are received by the LBT-RM session. Duplicates are ignored and lost messages will have the same recovery methods applied, but theordering may not be preserved. Delivery order is a topic level concern. Thus loss of messages in one topic will notinterfere or delay delivery of messages in another topic.

¨ Session State Advertisements - In PGM, SPM packets are used to advertise session state and to perform PGMrouter assist in the routers. For LBT-RM, these advertisements are only used when data is not flowing. Once datastops on a session, advertisements are sent with an exponential back-off (to a configurable maximum interval) sothat the bandwidth taken up by the session is minimal.

¨ Sender Rate Control - LBT-RM can control a sender's rate of injection of data into the network by use of a ratelimiter. This rate is configurable and will back pressure the sender, not allowing the application to exceed the ratelimit it has specified. In addition, LBT-RM senders have control over the rate of retransmissions separately fromnew data. This allows sending application to guarantee a minimum transmission rate even in the face of massiveloss at some or all receivers.

¨ Low Latency Retransmissions - LBT-RM senders do not mandate the use of NCF packets as PGM does.Because low latency retransmissions is such an important feature, LBT-RM senders by default sendretransmissions immediately upon receiving a NAK. After sending a retransmission, the sender ignores additionalNAKs for the same data and does not repeatedly send NCFs. The oldest data being requested in NAKs has priorityover newer data so that if retransmissions are rate controlled, then LBT-RM sends the most importantretransmissions as fast as possible.

Note: LBT-RM can use Datagram Bypass Layer (DBL) acceleration in conjunction with DBL-enabled Myricom 10-Gigabit Ethernet NICs for Linux and Microsoft Windows. DBL is a kernel-bypass technology that accelerates sendingand receiving UDP traffic. See Transport Acceleration Options in the UM configuration Guide for more information.

Note: LBT-RM transports may be distributed to receiving threads. See “Multi-Transport Threads” on page 4 for moreinformation.

Transport LBT-IPCThe LBT-IPC transport is an Interprocess Communication (IPC) UM transport that allows sources to publish topicmessages to a shared memory area managed as a static ring buffer from which receivers can read topic messages.Message exchange takes place at memory access speed which can greatly improve throughput when sources andreceivers can reside on the same host. LBT-IPC can be either source-paced or receiver-paced.

14 Chapter 3: UM Objects

The LBT-IPC transport uses a "lock free" design that eliminates calls to the Operating System and allows receiversquicker access to messages. An internal validation method enacted by receivers while reading messages from theShared Memory Area ensures message data integrity. The validation method compares IPC header information atdifferent times to ensure consistent, and therefore, valid message data. Sources can send individual messages or abatch of messages, each of which possesses an IPC header.

Restriction: Transport LBT-IPC is not supported on the OpenVMS® platform.

LBT-IPC Shared Memory AreaThe following diagram illustrates the Shared Memory Area used for LBT-IPC.

Figure 1. LBT-IPC Shared Memory Layout

Header

The Header contains information about the shared memory area resource.

¨ Shared Lock - shared receiver pool semaphore (mutex on Microsoft Windows) to ensure mutually exclusiveaccess to the receiver pool.

Transport Objects 15

¨ Version - LBT-IPC version number which is independent of any UM product version number.

¨ Buffer Length - size of shared memory area.

¨ Receiver Map Size - Number of entries available in the Receiver Pool which you configure with the source option,transport_lbtipc_maximum_receivers_per_transport .

¨ New Client Flag - set by the receiver after setting its Receiver Pool entry and before releasing the Shared Lock.Indicates to the source that a new receiver has joined the transport.

¨ Receiver Paced - Indicates if you've configured the transport for receiver-pacing.

¨ Old Message Start - pointer indicating messages that may be reclaimed.

¨ New Message Start - pointer indicating messages that may be read.

¨ New Message End - pointer indicating the end of messages that may be read, which may not be the same as theOld Message Start pointer.

Receiver Pool

The receiver pool is a collection of receiver connections maintained in the Shared Memory Area. The source reads thisinformation if you've configured receiver-pacing to determine if a message can be reclaimed or to monitor a receiver.Each receiver is responsible for finding a free entry in the pool and marking it as used.

¨ In Use flag - set by receiver while holding the Shared Lock, which effectively indicates the receiver has joined thetransport session. Using the Shared Lock ensures mutually exclusive access to the receiver connection pool.

¨ Oldest Message Start - set by receiver after reading a message. If you enable receiver-pacing the source reads itto determine if message memory can be reclaimed.

¨ Monitor Shared Lock - checked by the source to monitor a receiver. (semaphore on Linux, event on MicrosoftWindows) See Receiver Monitoring.

¨ Signal Shared Lock - Set by source to notify receiver that new data has been written. (semaphore on Linux, mutexon Microsoft Windows) If you set transport_lbtipc_receiver_thread_behavior to busy_wait, the receiver sets thissemaphore to zero and the source does not notify.

Source-to-Receivr Message Buffer

This area contains message data. You specify the size of the shared memory area with a source option,transport_lbtipc_transmission_window_size . The size of the shared memory area cannot exceed your platform'sshared memory area maximum size. UM stores the memory size in the shared memory area's header. The OldMessage Start and New Message Start point to positions in this buffer.

Sources and LBT-IPCWhen you create a source with lbm_src_create() and you've set the transport option to IPC, UM creates a sharedmemory area object. UM assigns one of the transport IDs to this area specified with the UM context configurationoptions, transport_lbtipc_id_high and transport_lbtipc_id_low . You can also specify a shared memory locationoutside of this range with a source configuration option, transport_lbtipc_id , to prioritize certain topics, if needed.

UM names the shared memory area object according to the format, LBTIPC_%x_%d where %x is the hexadecimal SessionID and %d is the decimal Transport ID. Examples names are LBTIPC_42792ac_20000 or LBTIPC_66e7c8f6_20001.Receivers access a shared memory area with this object name to receive (read) topic messages.

Using the configuration option, transport_lbtipc_behavior , you can choose source-paced or receiver-paced messagetransport. See Transport LBT-IPC Operation Options in the UM Configuration Guide.

Sending over LBT-IPC

To send on a topic (write to the shared memory area) the source writes to the Shared Memory Area starting at theOldest Message Start position. It then increments each receiver's Signal Lock if the receiver has not set this tozero.

16 Chapter 3: UM Objects

Receivers and LBT-IPCReceivers operate identically to receivers for all other UM transports. A receiver can actually receive topic messagesfrom a source sending on its topic over TCP, LBT-RU or LBT-RM and from a second source sending on LBT-IPC without any special configuration. The receiver learns what it needs to join the LBT-IPC session through the topicadvertisement.

Topic Resolution and LBT-IPC

Topic resolution operates identically with LBT-IPC as other UM transports albeit with a new advertisement type,LBMIPC. Advertisements for LBT-IPC contain the Transport ID, Session ID and Host ID. Receivers obtain LBT-IPCadvertisements in the normal manner (resolver cache, advertisements received on the multicast resolveraddress:port and responses to queries.) Advertisements for topics from LBT-IPC sources can reach receivers ondifferent machines if they use the same topic resolution configuration, however, those receivers silently ignore thoseadvertisements since they cannot join the IPC transport. See “Sending to Both Local and Remote Receivers” on page18.

Receiver Pacing

Although receiver pacing is a source behavior option, some different things must happen on the receiving side toensure that a source does not reclaim (overwrite) a message until all receivers have read it. When you use the defaulttransport_lbtipc_behavior (source-paced), each receiver's Oldest Message Start position in the Shared MemoryArea is private to each receiver. The source writes to the Shared Memory Area independently of receivers' reading.For receiver-pacing, however, all receivers share their Oldest Message Start position with the source. The source willnot reclaim a message until all receivers have successfully read that message.

Receiver Monitoring

To ensure that a source does not wait on a receiver that is not running, the source monitors a receiver via the MonitorShared Lock allocated to each receiving context. (This lock is in addition to the semaphore already allocated forsignaling new data.) A new receiver takes and holds the Monitor Shared Lock and releases the resource when it dies.If the source is able to obtain the resource, it knows the receiver has died. The source then clears the receiver's In Useflag in it's Receiver Pool Connection.

Similarities with Other UM TransportsAlthough no actual network transport occurs, UM functions in much the same way as if you send packets across thenetwork as with other UM transports.

¨ If you use a range of LBT-IPC transport IDs, UM assigns multiple topics sent by multiple sources to all the transportsessions in a round robin manner just like other UM transports.

¨ Transport sessions assume the configuration option values of the first source assigned to the transport session.

¨ Sources are subject to message batching.

Differences from Other UM Transports¨ Unlike LBT-RM which uses a transmission window to specify a buffer size to retain messages in case they must be

retransmitted, LBT-IPC uses the transmission window option to establish the size of the shared memory.

¨ LBT-IPC does not retransmit messages. Since LBT-IPC transport is essentially a memory write/read operation,messages should not be be lost in transit. However, if the shared memory area fills up, new messages overwriteold messages and the loss is absolute. No retransmission of old messages that have been overwritten occurs.

¨ Receivers also do not send NAKs when using LBT-IPC.

¨ LBT-IPC does not support Ordered Delivery options. However, if you set ordered_delivery 1 or -1 , LBT-IPCreassembles any large messages.

¨ LBT-IPC does not support Rate Control.

Transport Objects 17

¨ LBT-IPC creates a separate receiver thread in the receiving context.

Sending to Both Local and Remote ReceiversA source application that wants to support both local and remote receivers should create two UM Contexts withdifferent topic resolution configurations, one for IPC sends and one for sends to remote receivers. Separate contextsallows you to use the same topic for both IPC and network sources. If you simply created two source objects (one IPC,one say LBT-RM) in the same UM Context, you would have to use separate topics and suffer possible higher latencybecause the sending thread would be blocked for the duration of two send calls.

A UM source will never automatically use IPC when the receivers are local and a network transport for remotereceivers because the discovery of a remote receiver would hurt the performance of local receivers. An applicationthat wants transparent switching can implement it in a simple wrapper.

LBT-IPC Configuration ExampleThe following diagram illustrates how sources and receivers interact with the shared memory area used in the LBT-IPC transport.

Figure 2. Sending and Receiving with LBT-IPC

In the diagram above, 3 sources send (write) to two Shared Memory Areas while four receivers in two differentcontexts receive (read) from the areas. The assignment of sources to Shared Memory Areas demonstrate UM's roundrobin method. UM assigns the source sending on Topic A to Transport 20001, the source sending on Topic B toTransport 20002 and the source sending on Topic C back to the top of the transport ID range, 20001.

18 Chapter 3: UM Objects

The diagram also shows the UM configuration options that set up this scenario.

¨ The options transport_lbtipc_id_high and transport_lbtipc_id_low establish the range of Transport IDs between20001 and 20002.

¨ The option transport_lbtipc sets the source's transport to LBT-IPC.

¨ The option transport_lbtipc_transmission_window_size sets the size of each Shared Memory Area to 24 MB.

Required AuthoritiesLBT-IPC requires no special operating system authorities, except on Microsoft Windows Vista and Microsoft WindowsServer 2008, which require Administrator privileges. In addition, on Microsoft Windows XP, applications must bestarted by the same user, however, the user is not required to have administrator privileges. In order for applications tocommunicate with a service, the service must use a user account that has Administrator privileges.

Host Resource Usage and LimitsLBT-IPC contexts and sources consume host resources as follows.

¨ Per Source - 1 shared memory segment, 1 shared lock (semaphore on Linux, mutex on Microsoft Windows)

¨ Per Receiving Context - 2 shared locks (semaphores on Linux, one event and one mutex on Microsoft Windows)

Across most operating system platforms, these resources have the following limits.

¨ 4096 shared memory segments, though some platforms use different limits

¨ 32,000 shared semaphores (128 shared semaphore sets * 250 semaphores per set)

Consult your operating system documentation for specific limits per type of resource. Resources may be displayedand reclaimed using the “LBT-IPC Resource Manager” on page 19. See also Managing LBT-IPC Host Resources.

LBT-IPC Resource ManagerDeleting an IPC source with lbm_src_delete() or deleting an IPC receiver with lbm_rcv_delete() reclaims the sharedmemory area and locks allocated by the IPC source or receiver. However, if a less than graceful exit from a processoccurs, global resources remain allocated but unused. To address this possibility, the LBT-IPC Resource Managermaintains a resource allocation database with a record for each global resource (memory or semaphore) allocated orfreed. You can use the LBT-IPC Resource Manager to discover and reclaim resources. See the three example outputsbelow.

Displaying Resources

$> lbtipc_resource_manager Displaying Resources (to reclaim you must type '-reclaim' exactly)

--Memory Resources-- Memory resource: Process ID: 24441 SessionID: ab569cec XportID: 20001

--Semaphore Resources-- Semaphore key: 0x68871d75 Semaphore resource Index 0: reserved Semaphore resource: Process ID: 24441 Sem Index: 1 Semaphore resource: Process ID: 24436 Sem Index: 2

Reclaiming Unused Resources

$> lbtipc_resource_manager -reclaim

Reclaiming Resources Process 24441 not found: reclaiming Memory resource (SessionID: ab569cec XPortID: 20001) Process 24441 not found: reclaiming Semaphore resource: Key: 0x68871d75 Sem Index: 1 Process 24436 not found: reclaiming Semaphore resource: Key: 0x68871d75 Sem Index: 2

Transport Objects 19

Discovering Resources in Use

$> lbtipc_resource_manager -reclaim

Reclaiming Resources Process 24441 still active! Memory resource not reclaimed (SessionID: ab569cec XPortID: 20001) Process 24441 still active! Semaphore resource not reclaimed (Key: 0x68871d75 Sem Index: 1) Process 24436 still active! Semaphore resource not reclaimed (Key: 0x68871d75 Sem Index: 2)

Transport LBT-SMXThe LBT-SMX (shared memory acceleration) transport is an Interprocess Communication (IPC) transport you can usefor the lowest latency message streaming. LBT-SMX is faster than the LBT-IPC transport. Like LBT-IPC, sources canpublish topic messages to a shared memory area from which receivers can read topic messages. Unlike LBT-IPC, thenative APIs for the LBT-SMX transport are not thread safe and do not support all UM features such as messagebatching or fragmentation.

You can use either the native LBT-SMX API calls, lbm_src_buff_acquire() and lbm_src_buffs_complete() to sendover LBT-SMX or you can use lbm_src_send_*() API calls. The existing send APIs are thread safe with SMX, but theyincur a synchronization overhead and thus are slower than the native LBT-SMX API calls.

The example applications, lbmlatping.* and lbmlatpong.* show how to use the native LBT-SMX API calls. All threeAPIs (C API, Java API, and .NET API) have identically named example applications. Other example applications canuse the LBT-SMX transport with the use of a UM configuration file containing source transport lbtsmx. You cannotuse LBT-SMX with example applications for features not supported by LBT-SMX, such as lbmreq.*, lbmresp.*,lbmrcvq.* or lbmwrcvq.*.

The LBT-SMX configuration options are similar to the LBT-IPC transport options. See Transport LBT-SMX OperationOptions in the UM Configuration Guide for a full explanation of these options.

You can use Automatic Monitoring, UM API retrieve/reset calls, and LBMMON APIs to access LBT-SMX source andreceiver transport statistics. The Ultra Messaging SNMP Agent, however, cannot access LBT-SMX statistics. Toincrease performance, the LBT-SMX transport does not collect statistics by default. Set the UM configuration option,context transport_lbtsmx_message_statistics_enabled to 1 to enable the collection of transport statistics.

Sources and LBT-SMXWhen you create a source with lbm_src_create() and you've set the source's transport configuration option to LBT-SMX, UM creates a shared memory area object. UM assigns one of the transport IDs to this area from a range oftransport IDs specified with the UM context configuration options, transport_lbtsmx_id_high andtransport_lbtsmx_id_low . You can also specify a shared memory location inside or outside of this range with a sourceconfiguration option, transport_lbtsmx_id , to group certain topics in the same shared memory area, if needed. SeeTransport LBT-SMX Operation Options in the UM Configuration Guide.

Note: For every context created by your application, UM creates an additional shared memory area for controlinformation. The name for these control information memory areas ends with the suffix, _0, which is the TransportID.

UM names the shared memory area object according to the format, LBTSMX_%x_%d where %x is the hexadecimal SessionID and %d is the decimal Transport ID. Examples names are LBTSMX_42792ac_20000 or LBTSMX_66e7c8f6_20001.Receivers access a shared memory area with this object name to receive (read) topic messages.

Sending on a topic with the native LBT-SMX APIs requires the two API calls lbm_src_buff_acquire() andlbm_src_buffs_complete(). A third convenience API, lbm_src_buffs_complete_and_acquire(), combines a call tolbm_src_buffs_complete() followed by a call to lbm_src_buff_acquire() into one function call to eliminate theoverhead of an additional function call.

20 Chapter 3: UM Objects

Important: The native LBT-SMX APIs are not thread safe at the source object or LBT-SMX transport session levels forperformance reasons. Applications that use the native API LBT-SMX calls for either the same source or a group ofsources that map to the same LBT-SMX transport session must serialize the calls either directly in the application orthrough their own mutex.

Note: The native LBT-SMX APIs fail with an appropriate error message if a sending application uses them for a sourceconfigured to use a transport other than LBT-SMX.

Sending over LBT-SMX with Native APIsSending with LBT-SMX's native API is a two-step process.

1. The sending application first calls lbm_src_buff_acquire(), which returns a pointer into which the sendingapplication writes the message data.

The pointer points directly into the shared memory region. UM guarantees that the shared memory area has atleast the value specified with the len parameter of contiguous bytes available for writing whenlbm_src_buff_acquire() returns. If your application set the LBM_SRC_NONBLOCK flag withlbm_src_buff_acquire(), UM returns an LBM_EWOULDBLOCK error condition if the shared memory regiondoes not have enough contiguous space available.

Because LBT-SMX does not support fragmentation, your application must limit message lengths to a maximumequal to the value of the source's configured transport_lbtsmx_datagram_max_size option minus 16 bytes forheaders.

After the user acquires the pointer into shared memory and writes the message data, the application may calllbm_src_buff_acquire() repeatedly to send a batch of messages to the shared memory area. If your applicationwrites multiple messages in this manner, sufficient space must exist in the shared memory area.lbm_src_buff_acquire() returns an error if the available shared memory space is less than the size of the nextmessage.

2. The sending application calls one of the two following APIs.

¨ lbm_src_buffs_complete(), which publishes the message or messages to all listening receivers.

¨ lbm_src_buffs_complete_and_acquire(), which publishes the message or messages to all listeningreceivers and returns another pointer.

Sending over LBT-SMX with Existing APIsLBT-SMX supports lbm_src_send_* API calls. These API calls are fully thread-safe. The LBT-SMX featurerestrictions still apply, however, when using lbm_src_send_* API calls. The lbm_src_send_ex_info_t argument to thelbm_src_send_ex() and lbm_src_sendv_ex() APIs must be NULL when using an LBT-SMX source, because LBT-SMX does not support any of the features that the lbm_src_send_ex_info_t parameter can enable. See “DifferencesBetween LBT-SMX and Other UM Transports” on page 22

Since LBT-SMX does not support an implicit batcher or corresponding implicit batch timer, UM flushes all messagesfor all sends on LBT-SMX transports done with lbm_src_send_* APIs, which is similar to setting theLBM_MSG_FLUSH flag. LBT-SMX also supports the lbm_src_flush() API call, which behaves like a thread-safeversion of lbm_src_buffs_complete().

Attention: Users should not use both the native LBT-SMX APIs and the lbm_src_send_* API calls in the sameapplication. Users should choose one or the other type of API for consistency and to avoid thread safety problems.

The lbm_src_topic_alloc() API call generates log warnings if the given attributes specify an LBT-SMX transport andenable any of the features that LBT-SMX does not support. The lbm_src_topic_alloc() call succeeds, but UM doesnot enable the unsupported features indicated in the log warnings.

Other API functions that operate on lbm_src_t objects, such as lbm_src_create(), lbm_src_delete(), orlbm_src_topic_dump(), operate with LBT-SMX sources normally.

Transport Objects 21

Because LBT-SMX does not support fragmentation, your application must limit message lengths to a maximum equalto the value of the source's configured transport_lbtsmx_datagram_max_size option minus 16 bytes for headers. Anysend API calls with a length parameter greater than this configured value fail.

Receivers and LBT-SMXReceivers operate identically over LBT-SMX to receivers as all other UM transports. The msg->data pointer of adelivered lbm_msg_t object points directly into the shared memory region.

The lbm_msg_retain() API function operates differently for LBT-SMX. lbm_msg_retain() creates a full copy of themessage in order to access the data outside the receiver callback.

Attention: You application should not pass the msg->data pointer to other threads or outside the receiver callbackuntil your application has called lbm_msg_retain() on the message.

Caution: Any API calls documented as not safe to call from a context thread callback are also not safe to call from anLBT-SMX receiver thread.

Topic Resolution and LBT-SMX

Topic resolution operates identically with LBT-SMX as other UM transports albeit with the advertisement type, LBMSMX.Advertisements for LBT-SMX contain the Transport ID, Session ID, and Host ID. Receivers get LBT-SMXadvertisements in the normal manner, either from the resolver cache, advertisements received on the multicastresolver address:port, or responses to queries.

Similarities Between LBT-SMX and Other UM TransportsAlthough no actual network transport occurs, UM functions in much the same way as if you send packets across thenetwork as with other UM transports.

¨ If you use a range of LBT-SMX transport IDs, UM assigns multiple topics sent by multiple sources to all thetransport sessions in a round robin manner just like other UM transports.

¨ Transport sessions assume the configuration option values of the first source assigned to the transport session.

¨ Source applications and receiver applications based on any of the three available APIs can interoperate with eachother. For example, sources created by a C sending application can send to receivers created by a Java receivingapplication.

Differences Between LBT-SMX and Other UM Transports¨ Unlike LBT-RM which uses a transmission window to specify a buffer size to retain messages for retransmission,

LBT-SMX uses the transmission window option to establish the size of the shared memory. LBT-SMX usestransmission window sizes that are powers of 2. You can set transport_lbtsmx_transmission_window_size to anyvalue, but UM rounds the option value up to the nearest power of 2.

¨ The largest transmission window size for Java applications is 1 GB.

¨ LBT-SMX does not retransmit messages. Since LBT-SMX transport is a memory write/read operation, messagesshould not be lost in transit. No retransmission of old messages that have been overwritten occurs.

¨ Receivers do not send NAKs when using LBT-SMX.

You cannot use the following UM features with LBT-SMX:

¨ Arrival Order Delivery

¨ Late Join

¨ Off Transport Recovery

¨ Request and Response

22 Chapter 3: UM Objects

¨ Multi-transport Threads

¨ Source-side Filtering

¨ Hot Failover

¨ Message Properties

¨ Application Headers

¨ Implicit and Explicit Message Batching

¨ Fragmentation and Reassembly

¨ Immediate Messaging

¨ Receiver thread behaviors other than "busy_wait"

¨ Sequential mode receiver threads

LBT-SMX does not support the following UM products:

¨ Dynamic Routing Option

¨ Ultra Messaging Persistence Edition

¨ Ultra Messaging Queuing Edition

¨ Ultra Messaging Desktop Services

¨ Ultra Messaging Cache

¨ Ultra Messaging SNMP Agent

Transport Objects 23

LBT-SMX Configuration ExampleThe following diagram illustrates how sources and receivers interact with the shared memory area used in the LBT-SMX transport.

Figure 3. Sending and Receiving with LBT-SMX

In the diagram above, three sources send (write) to two Shared Memory Areas while four receivers in two differentcontexts receive (read) from the areas. The assignment of sources to Shared Memory Areas demonstrate UM's roundrobin method. UM assigns the source sending on Topic A to Transport 30001, the source sending on Topic B toTransport 30002 and the source sending on Topic C back to the top of the transport ID range, 20001.

The diagram also shows the UM configuration options that set up this scenario.

¨ The options source transport_lbtsmx_id_high and source transport_lbtsmx_id_low establish the range ofTransport IDs between 30001 and 30002.

¨ The option source transport lbtsmx sets the source's transport to LBT-SMX.

¨ The option source transport_lbtsmx_transmission_window_size sets the size of each Shared Memory Area to33554432 bytes or 32 MB. This option's value must be a power of 2. If you configured the transmission window sizeto 25165824 bytes (24 MB) for example, UM logs a warning message and then rounds the value of this option up tothe next power of 2 or 33554432 bytes or 32 MB.

24 Chapter 3: UM Objects

Java Code Examples for LBT-SMXThe Java code examples for LBT-SMX send and receive one million messages. Start the receiver example applicationbefore you start the source example application.

Java Source Exampleimport java.nio.ByteBuffer;import com.latencybusters.lbm.*;

public class SimpleSrc { private LBMContext ctx; private LBMSource src; public static void main(String[] args) { try { SimpleSrc test = new SimpleSrc(); test.sendMessages(); System.out.println("Send Complete"); } catch (LBMException ex) { System.err.println(ex.getMessage()); ex.printStackTrace(); } }

public SimpleSrc() throws LBMException { ctx = new LBMContext(); LBMSourceAttributes sattr = new LBMSourceAttributes(); sattr.setValue("transport", "lbtsmx"); LBMTopic top = ctx.allocTopic("SimpleSmx", sattr); src = ctx.createSource(top); } public void sendMessages() throws LBMException { /* Keep a reference to the source buffer, which does not change */ final ByteBuffer srcBuffer = src.getMessagesBuffer(); /* Sends will block waiting for receivers */ final int flags = LBM.SRC_BLOCK; final int msgLength = 8; int pos; try { Thread.sleep(1000); } catch (Exception ex) { } for (long i = 0; i < 1000000; i++) { /* Acquire a position in the buffer */ pos = src.acquireMessageBufferPosition(msgLength, flags); /* Place data at acquired position */ srcBuffer.putLong(pos, i); /* Inform receivers data has been written */ src.messageBuffersComplete(); } try { Thread.sleep(1000); } catch (Exception ex) { } src.close(); ctx.close(); } }

The source sends one million messages using the native LBT-SMX Java APIs. sendMessages() obtains a referenceto the source's message buffer, which does not change for the life of the source. The callacquireMessageBufferPosition(int, int) contains the requested message length of 8 bytes. When this call returns, itgives an integer position into the previously obtained messages buffer, which is the position of the message data. UMguarantees that you can safely write the value of the counter i into the buffer at this position.

Java Receiver Exampleimport java.nio.ByteBuffer;import com.latencybusters.lbm.*;/* Extend LBMReceiver to avoid onReceive synchronization */public class SimpleSmxRcv extends LBMReceiver { protected SimpleSmxRcv(LBMContext lbmctx, LBMTopic lbmtopic) throws LBMException {

Transport Objects 25

super(lbmctx, lbmtopic); } long lastReceivedValue = -1; /* Override LBMReceiver onReceive method */ protected int onReceive(LBMMessage lbmmsg) { if (lbmmsg.type() == LBM.MSG_DATA) { /* New API gets byte buffer with position and limit set */ ByteBuffer msgsBuffer = lbmmsg.getMessagesBuffer(); /* Get the message data directly from the buffer */ lastReceivedValue = msgsBuffer.getLong(); } return 0; }

public static void main(String[] args) { LBMContext ctx = null; SimpleSmxRcv rcv = null; try { ctx = new LBMContext(); LBMTopic top = ctx.lookupTopic("SimpleSmx"); rcv = new SimpleSmxRcv(ctx, top); } catch (LBMException ex) { System.out.println(ex.getMessage()); ex.printStackTrace(); System.exit(1); } while (rcv.lastReceivedValue < 999999) { try { Thread.sleep(250); } catch (Exception ex) {} } try { rcv.close(); ctx.close(); System.out.println("Last Received Value: " + rcv.lastReceivedValue); } catch (LBMException ex) { System.out.println(ex.getMessage()); ex.printStackTrace(); } }}

The receiver reads messages from an LBT-SMX Source using the new API on LBMMessage. The example extends theLBMReceiver class so that you can overwrite the onReceive() method, which bypasses synchronization of multiplereceiver callbacks. As a result, the addReceiver() and removeReceiver() methods do not work with this class, but wedon't want them anyway. In the overridden onReceive() callback, we call getMessagesBuffer(), which returns aByteBuffer view of the underlying transport. This allows the application to do zero copy reads directly from the memorythat stores the message data. The returned ByteBuffer position and limit is set to the beginning and end of themessage data. The message data does not start at position 0. The application reads a long out of the buffer, which isthe same long that was placed by the source example.

Batchingpublic void sendMessages() throws LBMException{ ... for (long i = 0; i < 1000000; i += 2) { /* Acquire a position in the buffer */ pos = src.acquireMessageBufferPosition(msgLength, flags); /* Place data at acquired position */ srcBuffer.putLong(pos, i); pos = src.acquireMessageBufferPosition(msgLength, flags); srcBuffer.putLong(pos, i+1); /* Inform receivers two messages have been written */ src.messageBuffersComplete(); } ...}

26 Chapter 3: UM Objects

You can implement a batching algorithm at the source by doing multiple acquires before calling complete. Whenreceivers notice that there are new message available, they deliver all new messages in a single loop.

Blocking and Non-blocking Sendspublic void sendMessages() throws LBMException{ ... /* Acquire will return -1 if need to wait for receivers */ final int flags = LBM.SRC_NONBLOCK; ... for (long i = 0; i < 1000000; i++) { /* Acquire a position in the buffer */ pos = src.acquireMessageBufferPosition(msgLength, flags); while (pos == -1) { /* Implement a backoff algorithm here */ try { Thread.sleep(1); } catch (Exception ex) { } pos = src.acquireMessageBufferPosition(msgLength, flags); } /* Place data at acquired position */ srcBuffer.putLong(pos, i); /* Inform receivers data has been written */ src.messageBuffersComplete(); } ...}

By default, acquireMessageBufferPosition() waits for receivers to catch up before it writes the requested number ofbytes to the buffer. The resulting spin wait block happens only if you did not set the flags argument toLBM.SRC_NONBLOCK. If the flags argument sets the LBM.SRC_NONBLOCK value, then the function returns -1 ifthe call would have blocked. For performance reasons, acquireMessageBufferPosition() does not throw newLBMEWouldBlock exceptions like standard send APIs.

Complete and Acquire Functionpublic void sendMessages() throws LBMException{ ... for (long i = 0; i < 1000000; i++) { /* Mark previous acquires complete and reserve space */ pos = src.messageBuffersCompleteAndAcquirePosition(msgLength, flags); /* Place data at acquired position */ srcBuffer.putLong(pos, i); } /* final buffers complete after loop */ src.messageBuffersComplete(); ...}

The function, messageBuffersCompleteAndAcquirePosition(), is a convenience function for the source and callsmessageBuffersComplete() followed immediately by acquireMessageBufferPosition(), which reduces thenumber of method calls per message.

.NET Code Examples for LBT-SMXThe .NET code examples for LBT-SMX send and receive one million messages. Start the receiver exampleapplication before you start the source example application.

.NET Source Exampleusing System;using System.Collections.Generic;using System.Text;using System.Threading;using System.Runtime.InteropServices;using com.latencybusters.lbm;

namespace UltraMessagingApplication.SimpleSrc{ class SimpleSrc

Transport Objects 27

{ LBMContext ctx; LBMSource src;

static void Main(string[] args) { SimpleSrc test = new SimpleSrc(); test.sendMessages(); Console.WriteLine("Send Complete"); }

public SimpleSrc() { ctx = new LBMContext(); LBMSourceAttributes sattr = new LBMSourceAttributes(); sattr.setValue("transport", "lbtsmx"); LBMTopic top = ctx.allocTopic("SimpleSmx", sattr); src = ctx.createSource(top); }

private void sendMessages() { IntPtr writePtr; // Sends will block waiting for receivers int flags = LBM.SRC_BLOCK; uint msgLength = 8;

Thread.Sleep(1000);

for (long i = 0; i < 1000000; i++) { // Acquire a position in the buffer src.buffAcquire(out writePtr, msgLength, flags); // Place data at acquired position Marshal.WriteInt64(writePtr, i); // Inform receivers data has been written src.buffsComplete(); }

Thread.Sleep(1000); src.close(); ctx.close(); } }}

You can access the shared memory region directly with the IntPtr structs. The src.buffAcquire() API modifieswritePtr to point to the next available location in shared memory. When buffAcquire() returns, you can safely write tothe writePtr location up to the length specified in buffAcquire(). The Marshal.WriteInt64() writes 8 bytes of data tothe shared memory region. The call to buffsComplete() signals new data to connected receivers.

.NET Receiver Exampleusing System;using System.Collections.Generic;using System.Text;using System.Threading;using System.Runtime.InteropServices;using com.latencybusters.lbm;

namespace UltraMessagingApplication.SimpleRcv{ class SimpleRcv { private LBMContext ctx; private LBMReceiver rcv; private long lastReceivedValue = -1;

static void Main(string[] args) { SimpleRcv simpleRcv = new SimpleRcv(); while (simpleRcv.lastReceivedValue < 999999) { Thread.Sleep(250); }

28 Chapter 3: UM Objects

simpleRcv.rcv.close(); simpleRcv.ctx.close(); Console.WriteLine("Last Received Value: {0}", simpleRcv.lastReceivedValue); }

public SimpleRcv() { ctx = new LBMContext(); LBMTopic top = new LBMTopic(ctx, "SimpleSmx"); rcv = new LBMReceiver(ctx, top, new LBMReceiverCallback(onReceive), null); }

public int onReceive(Object obj, LBMMessage msg) { if (msg.type() == LBM.MSG_DATA) { // Read data out of shared memory lastReceivedValue = Marshal.ReadInt64(msg.dataPointerSafe()); } // dispose the message so the LBMMessage object can be re-used msg.dispose(); return 0; } }}

The application calls the simpleRcv::onReceive callback after the source places new data in the shared memoryregion. The msg.dataPointerSafe() API returns an IntPtr to the data, which does not create any new objects. TheMarshal.ReadInt64 API then reads data directly from the shared memory.

Batchingprivate void sendMessages(){ ... for (int i = 0; i < 1000000; i += 2) { // Acquire a position in the buffer src.buffAcquire(out writePtr, msgLength, flags); // Place data at acquired position Marshal.WriteInt32(writePtr, i); // Acquire a position in the buffer src.buffAcquire(out writePtr, msgLength, flags); // Place data at acquired position Marshal.WriteInt32(writePtr, i); // Inform receivers two messages has been written src.buffsComplete(); } ...}

You can implement a batching algorithm at the source by doing multiple acquires before calling complete. Whenreceivers notice that new message are available, they deliver all new messages in a single loop.

Blocking and Non-blocking Sendsprivate void sendMessages(){ ... // buffAcquire will return -1 if need to wait for receivers int flags = LBM.SRC_NONBLOCK; ... for (long i = 0; i < 1000000; i++) { // Acquire a position in the buffer int rc = src.buffAcquire(out writePtr, msgLength, flags); while (rc == -1) { // Implement a backoff algorithm here Thread.Sleep(0); rc = src.buffAcquire(out writePtr, msgLength, flags); } // Place data at acquired position Marshal.WriteInt64(writePtr, i); // Inform receivers that a message has been written src.buffsComplete(); }

Transport Objects 29

...}

By default, buffAcquire() waits for receivers to catch up before it writes the requested number of bytes to the buffer.The resulting spin wait block happens only if you did not set the flags argument to LBM.SRC_NONBLOCK. If the flagsargument sets the LBM.SRC_NONBLOCK value, then the function returns -1 if the call would have blocked. Forperformance reasons, buffAcquire() does not throw new LBMEWouldBlock exceptions like standard send APIs.

Complete and Acquire Functionprivate void sendMessages(){ ... for (long i = 0; i < 1000000; i++) { // Acquire a position in the buffer src.buffsCompleteAndAcquire(out writePtr, msgLength, flags); // Place data at acquired position Marshal.WriteInt64(writePtr, i); } // final buffsComplete after loop src.buffsComplete();

...}

The function, buffsCompleteAndAcquire(), is a convenience function for the source and calls buffsComplete()followed immediately by buffAcquire(), which reduces the number of method calls per message.

Reduce Synchronization Overheadpublic SimpleRcv(){ ctx = new LBMContext(); LBMReceiverAttributes rattr = new LBMReceiverAttributes(); // Set the enableSingleReceiverCallback attribute to 'true' rattr.enableSingleReceiverCallback(true); LBMTopic top = new LBMTopic(ctx, "SimpleSmx", rattr); // With enableSingleReceiverCallback, a callback must be specified in the ver constructor. rcv = new LBMReceiver(ctx, top, new LBMReceiverCallback(onReceive), null); // rcv.addReceiver and rcv.removeReceiver will result in log warnings.}

Delivery latency to an LBMReceiver callback can be reduced with a single callback. CallLBMReceiverAttributes::enableSingleReceiverCallback on the attributes object used to create the LBMReceiver.The addReceiver() and removeReceiver() APIs become defunct, and your application calls the application receivercallback without any locks taken. The enableSingelReceiverCallback() API eliminates callback relatedsynchronization overhead.

Note: In Java, inheriting from LBMReceiver and overriding the onReceive can achieve the same thing.

Increase Performance with unsafe Code Constructsfor (long i = 0; i < 1000000; i++) { // Acquire a position in the buffer src.buffAcquire(out writePtr, msgLength, flags); // Place data at acquired position unsafe { *((long*)(writePtr)) = i; } // Inform receivers data has been written src.buffsComplete();}public int onReceive(Object obj, LBMMessage msg){ if (msg.type() == LBM.MSG_DATA) { unsafe { lastReceivedValue = *((long*)msg.dataPointer()); } } // dispose the message so the object can be re-used

30 Chapter 3: UM Objects

msg.dispose(); return 0;}

Using .NET unsafe code constructs can increase performance. By manipulating pointers directly, you can eliminatecalls to external APIs, resulting in lower latencies.

Transport LBT-RDMAThe LBT-RDMA transport is Remote Direct Memory Access (RDMA) UM transport that allows sources to publish topicmessages to a shared memory area from which receivers can read topic messages. LBT-RDMA runs acrossInfiniBand and 10 Gigabit Ethernet hardware.

Note: Use of the LBT-RDMA transport requires the purchase and installation of the Ultra Messaging RDMA TransportModule. See your Ultra Messaging representative for licensing specifics.

Restriction: Transport LBT-RDMA is not supported on the OpenVMS® platform.

When you create a source with lbm_src_create() and you've set the transport option to RDMA, UM creates a sharedmemory area object on the sending machine's Host Channel Adapter (HCA) card. UM assigns one of the RDMAtransport ports to this area specified with the UM context configuration options, transport_lbtrdma_port_high andtransport_lbtrdma_port_low . You can also specify a shared memory location outside of this range with a sourceconfiguration option, transport_lbtrdma_port , to prioritize certain topics, if needed.

When you create a receiver with lbm_rcv_create() for a topic being sent over LBT-RDMA, UM creates a sharedmemory area on the receiving machine's HCA card. The network hardware immediately copies any new data from thesending HCA to the receiving HCA. UM receivers monitor the receiving shared memory area for new topic messages.You configure receiver monitoring with transport_lbtrdma_receiver_thread_behavior .

Transport Objects 31

LBT-RDMA Object DiagramThe following diagram illustrates how sources and receivers interact with the shared memory area used in the LBT-RDMA transport.

Figure 4. Sending and Receiving with LBT-RDMA

Similarities with Other UMS TransportsUM functions in much the same way as if you send packets across a traditional Ethernet network as with other UMtransports.

¨ If you use a range of ports, UM assigns multiple topics that have been sent by multiple sources in a round robinmanner to all the transport sessions configured my the port range.

¨ Transport sessions assume the configuration option values of the first source assigned to the transport session.

¨ Sources are subject to message batching.

¨ Topic resolution operates identically with LBT-RDMA as other UM transports albeit with a new advertisement type,LBMRDMA.

Differences from Other UMS Transports¨ Unlike LBT-RM which uses a transmission window to specify a buffer size to retain messages in case they must be

retransmitted, LBT-RDMA uses the transmission window option to establish the size of the shared memory.

¨ LBT-RDMA does not retransmit messages. Since LBT-RDMA transport is essentially a memory write/readoperation, messages should not be be lost in transit. However, if the shared memory area fills up, new messagesoverwrite old messages and the loss is absolute. No retransmission of old messages that have been overwrittenoccurs.

32 Chapter 3: UM Objects

¨ Receivers also do not send NAKs when using LBT-RDMA.

¨ LBT-RDMA does not support Ordered Delivery. However, if you set ordered_delivery 1 or -1 , LBT-RDMAreassembles any large messages.

¨ LBT-RDMA does not support Rate Control.

¨ LBT-RDMA creates a separate receiver thread in the receiving context.

Transport Objects 33

C H A P T E R 4

ArchitectureThis chapter includes the following topics:

¨ Overview, 34

¨ Embedded Mode, 34

¨ Sequential Mode, 34

¨ Topic Resolution, 35

¨ Message Batching, 44

¨ Ordered Delivery, 47

¨ Loss Detection Using TSNIs, 48

¨ Receiver Keepalive Using Sesssion Messages, 49

OverviewUM is designed to be a flexible architecture. Unlike many messaging systems, UM does not require an intermediatedaemon to handle routing issues or protocol processing. This increases the performance of UM and returns valuablecomputation time and memory back to applications that would normally be consumed by messaging daemons.

Embedded ModeWhen you create a context (lbm_context_create()) with the UM configuration option operational_mode set toembedded (the default), UM creates an independent thread, called the context thread, which handles timer and socketevents, and does protocol-level processing, like retransmission of dropped packets.

Sequential ModeWhen you create a context (lbm_context_create()) with the UM configuration option operational_mode set tosequential, the context thread is NOT created. It becomes the application's responsibility to donate a thread to UM bycalling lbm_context_process_events() regularly, typically in a tight loop. Use Sequential mode for circumstanceswhere your application wants control over the attributes of the context thread. For example, some applications raise

34

the priority of the context thread so as to obtain more consistent latencies. In sequential mode, no separate thread isspawned when a context is created.

You enable Sequential mode with the following configuration option.

context operational_mode sequential

Topic ResolutionTopic resolution is the discovery of a topic's transport session information by a receiver to enable the receipt of topicmessages. By default, UM relies on multicast requests and responses to resolve topics to transport sessions. (Youcan also use Unicast requests and responses, if needed.) UM receivers multicast their topic requests, or queries, to anIP multicast address and UDP port configured with the UM configuration options, resolver_multicast_address andresolver_multicast_port ). UM sources also multicast their advertisements and responses to receiver queries to thesame multicast address and UDP port.

Topic Resolution offers 3 distinct phases that can be implemented.

¨ Initial Phase - Period that allows you to resolve a topic aggressively. Can be used to resolve all known topicsbefore message sending begins. This phase can be configured to run differently from the defaults or completelydisabled.

¨ Sustaining Phase - Period that allows new receivers to resolve a topic after the Initial Phase. Can also be theprimary period of topic resolution if you disable the Initial Phase. This phase can also be configured to rundifferently from the defaults or completely disabled.

¨ Quiescent Phase - The "steady state" period during which a topic is resolved and UM uses no system resourcesfor topic resolution.

This section discusses the following topics.

¨ “Multicast Topic Resolution” on page 36

¨ “Topic Resolution Phases” on page 38

¨ “Topic Resolution Configuration Options” on page 41

¨ “Unicast Topic Resolution” on page 42

¨ Unicast Topic Resolution Across Administrative Domains

Topic Resolution 35

Multicast Topic ResolutionThe following diagram depicts the UM topic resolution using multicast.

Figure 5. Topic Resolution via Multicast

UM performs topic resolution automatically. Your application does not need to call any API functions to initiate topicresolution, however, you can influence topic resolution with “Topic Resolution Configuration Options” on page 41.Moreover, you can set configuration options for individual topics by using the lbm_*_attr_setopt() functions in yourapplication. See “Assigning Different Configuration Options to Individual Topics” on page 41

Topic Resolution also occurs across UM Routers, which means between Topic Resolution Domains. A TopicResolution Domain refers to all the UM contexts that use the same UM topic resolution configuration values, such asresolver_multicast_address and resolver_multicast_port . UM Routers automatically assign Topic ResolutionDomain IDs and manage Topic resolution traffic across them. See the UM Router Guide for more information.

Note: Multicast topic resolution traffic can use Datagram Bypass Layer (DBL) acceleration in conjunction with DBL-enabled Myricom 10-Gigabit Ethernet NICs for Linux and Microsoft Windows. DBL is a kernel-bypass technology thataccelerates sending and receiving UDP traffic. See Transport Acceleration Options in the UM Configuration Guide formore information.

36 Chapter 4: Architecture

Restriction: Multicast Topic Resolution is not directly supported on the OpenVMS® platform. UM applications runningon the OpenVMS® platform, however, can use multicast topic resolution running on a different platform, such asMicrosoft Windows® or Linux.

Sources AdvertiseUM sources help UM receivers discover transport information in the following ways.

¨ Advertise Active Topics - Each source advertises its active topic first upon its creation and subsequently accordingto the resolver_advertisement_*_interval configuration options for the Initial and Sustaining Phases. Sourcesadvertise by sending a Topic Information Record (TIR). (You can prevent a source from sending an advertisementupon creation with resolver_send_initial_advertisement .)

¨ Respond to Topic Queries - Each source responds immediately to queries from receivers about its topic.

Both a topic advertisement and a query response contain the topic's transport session information. Based on thetransport type, a receiver can join the appropriate multicast group (for LBT-RM), send a connection request (for LBT-RU), connect to the source (for TCP) or access a shared memory area (for LBT-IPC). The address and portinformation potentially contained within a TIR includes:

¨ For a TCP transport, the source address, TCP port and Session ID.

¨ For an LBT-RM transport, the unicast UDP port (to which NAKs are sent) and the UDP destination port.

¨ For an LBT-RU transport, the source address, UDP port and Session ID.

¨ For an LBT-IPC transport, the Host ID, LBT-IPC Session ID and Transport ID.

For an LBT-RDMA transport, the source address, RDMA port and Session ID.

See Resolver Operation Options in the UM Configuration Guide for more information.

Receivers QueryReceivers can discover transport information in the following ways.

¨ Search advertisements collected in the resolver cache maintained by the UM context.

¨ Listen for source advertisements on the resolver_multicast_address:port.

¨ Send a topic query (TQR).

A new receiver queries for its topic according to the resolver_query_*_interval configuration options for the Initialand Sustaining Phases.

Note: The resolver_query_minimum_initial_interval actually begins after you call prior to creating the receiver. Ifyou have disabled the Initial Phase for the topic's resolution, the resolver_query_sustaining_interval begins afteryou call lbm_rcv_topic_lookup().

A Topic Query Record (TQR) consists primarily of the topic string. Receivers continue querying on a topic until theydiscover the number of sources configured by resolution_number_of_sources_query_threshold . However the largedefault of this configuration option (10,000,000) allows a receiver to continue to query until both the initial andsustaining phase of topic resolution complete.

See Resolver Operation Options in the UM Configuration Guide for more information.

Wildcard ReceiversWildcard receivers can discover transport information in the following ways.

¨ Search advertisements collected in the resolver cache maintained by the UM context.

¨ Listen for source advertisements on the resolver_multicast_address:port.

Topic Resolution 37

¨ Send a wildcard receiver topic query (WC-TQR).

UM implements only one phase of wildcard receiver queries, sending wildcard receiver queries according to wildcardreceiver resolver_query_*_interval configuration options until the topic pattern has been queried for theresolver_query_minimum_duration . The wildcard receiver topic query (WC-TQR) contains the topic pattern and thepattern_type .

See Wildcard Receiver Options in the UM Configuration Guide for more information.

Topic Resolution PhasesThe phases of topic resolution pertain to individual topics. Therefore if your system has 100 topics, 100 different topicresolution advertisement and query phases may be running concurrently. This describes the three phases of UltraMessaging topic resolution.

¨ “Initial Phase” on page 38

¨ “Sustaining Phase” on page 39

¨ “Quiescent Phase” on page 41

Initial PhaseThe initial topic resolution phase for a topic is an aggressive phase that can be used to resolve all topics beforesending any messages. During the initial phase, network traffic and CPU utilization might actually be higher. You cancompletely disable this phase, if desired. See Disabling Aspects of Topic Resolution in the UM ConfigurationGuide.

Advertising in the Initial Phase

For the initial phase default settings, the resolver issues the first advertisement as soon as the scheduler can processit. The resolver issues the second advertisement 10 ms later, or at theresolver_advertisement_minimum_initial_interval . For each subsequent advertisement, UM doubles the intervalbetween advertisements. The source sends an advertisement at 20 ms, 40 ms, 80 ms, 160 ms, 320 ms and finally at500 ms, or the resolver_advertisement_maximum_initial_interval . These 8 advertisements require a total of 1130ms. The interval between advertisements remains at the maximum 500 ms, resulting in 7 more advertisements beforethe total duration of the initial phase reaches 5000 ms, or the resolver_advertisement_minimum_initial_duration .This concludes the initial advertisement phase for the topic.

Figure 6. Initial Advertisement Phase

38 Chapter 4: Architecture

The initial phase for a topic can take longer than the resolver_advertisement_minimum_initial_duration if manytopics are in resolution at the same time. The configuration options, resolver_initial_advertisements_per_secondand resolver_initial_advertisement_bps enforce a rate limit on topic advertisements for the entire UM context. Alarge number of topics in resolution - in any phase - or long topic names may exceed these limits.

If a source advertising in the initial phase receives a topic query, it responds with a topic advertisement. UMrecalculates the next advertisement interval from that point forward as if the advertisement was sent at the nearestinterval.

Querying in the Initial Phase

Querying activity by receivers in the initial phase operates in similar fashion to advertising activity, although withdifferent interval defaults. The resolver_query_minimum_initial_interval default is 20 ms. Subsequent intervalsdouble in length until the interval reaches 200 ms, or the resolver_query_maximum_initial_interval . The queryinterval remains at 200 ms until the initial querying phase reaches 5000 ms, or theresolver_query_minimum_initial_duration .

Figure 7. Initial Query Phase

The initial query phase completes when it reaches the resolver_query_minimum_initial_duration . The initial queryphase also has UM context-wide rate limit controls ( resolver_initial_queries_per_second andresolver_initial_query_bps ) that can result in the extension of a phase's duration in the case of a large number oftopics or long topic names.

Sustaining PhaseThe sustaining topic resolution phase follows the initial phase and can be a less active phase in which a new receiverresolves its topic. It can also act as the sole topic resolution phase if you disable the initial phase. The sustainingphase defaults use less network resources than the initial phase and can also be modified or disabled completely. SeeDisabling Aspects of Topic Resolution in the UM Configuration Guide.

Advertising in the Sustaining Phase

For the sustaining phase defaults, a source sends an advertisement every second( resolver_advertisement_sustain_interval ) for 1 minute ( resolver_advertisement_minimum_sustain_duration ).

Topic Resolution 39

When this duration expires, the sustaining phase of advertisement for a topic ends. If a source receives a topic query,the sustaining phase resumes for the topic and the source completes another duration of advertisements.

Figure 8. Sustaining Advertisement Phase

The sustaining advertisement phase has UM context-wide rate limit controls( resolver_sustain_advertisements_per_second and resolver_sustain_advertisement_bps ) that can result in theextension of a phase's duration in the case of a large number of topics or long topic names.

Querying in the Sustaining Phase

Default sustaining phase querying operates the same as advertising. Unresolved receivers query every second( resolver_query_sustain_interval ) for 1 minute ( resolver_query_minimum_sustain_duration ). When this durationexpires, the sustaining phase of querying for a topic ends.

Figure 9. Sustaining Query Phase

Sustaining phase queries stop when one of the following events occurs.

¨ The receiver discovers multiple sources that equal resolution_number_of_sources_query_threshold .

40 Chapter 4: Architecture

¨ The sustaining query phase reaches the resolver_query_minimum_sustain_duration .

The sustaining query phase also has UM context-wide rate limit controls ( resolver_sustain_queries_per_second andresolver_sustain_query_bps ) that can result in the extension of a phase's duration in the case of a large number oftopics or long topic names.

Quiescent PhaseThis phase is the absence of topic resolution activity for a given topic. It is possible that some topics may be in thequiescent phase at the same time other topics are in initial or sustaining phases of topic resolution. This phase ends ifeither of the following occurs.

¨ A new receiver sends a query.

¨ Your application calls lbm_context_topic_resolution_request() that provokes the sending of topic queries forany receiver or wildcard receiver in this state.

Topic Resolution Configuration OptionsRefer to the UM Configuration Guide for specific information about Topic Resolution Configuration Options.

¨ Resolver Operation Options

¨ Multicast Resolver Network Options

¨ Unicast Resolver Network Options

¨ Wildcard Receiver Options

Assigning Different Configuration Options to Individual TopicsYou can assign different configuration option values to individual topics by accessing the topic attribute table(lbm_*_topic_attr_t_stct) before creating the source, receiver or wildcard receiver.

Creating a Source with Different Topic Resolution Options

1. Call lbm_src_topic_attr_setopt() to set new option value

2. Call lbm_src_topic_alloc()3. Call lbm_src_create()Creating a Receiver with Different Topic Resolution Options

1. Call lbm_rcv_topic_attr_setopt() to set new option value

2. Call lbm_rcv_topic_lookup()3. Call lbm_rcv_create()Creating a Wildcard Receiver with Different Topic Resolution Options

1. Call lbm_wildcard_rcv_attr_setopt() to set new wildcard receiver option value

2. Call lbm_wildcard_rcv_create()

Multicast Network OptionsEssentially, the _incoming and _outgoing versions of resolver_multicast_address/port provide more fine-grainedcontrol of topic resolution. By default, the resolver_multicast_address and resolver_multicast_port and the_incoming and _outgoing address and port are set to the same value. If you want your context to listen to a particularmulticast address/port and send on another address/port, then you can set the _incoming and _outgoing configurationoptions to different values.

Topic Resolution 41

See Resolver Operation Options in the UM Configuration Guide for more information.

Unicast Topic ResolutionThis section also discusses the following topics.

¨ “Unicast Topic Information Records” on page 42

¨ “Unicast Topic Resolution Resilience” on page 43

¨ Unicast Topic Resolution Across Administrative Domains

By default UM expects multicast connectivity between all sources and receivers. When only unicast connectivity isavailable, you may configure all sources and receivers to use unicast topic resolution. This requires that you run oneor more UM unicast topic resolution daemon(s) ( Chapter 7, “Manpage for lbmrd” on page 98), which perform thesame topic resolution activities as multicast topic resolution. You configure each instance of the unicast topicresolution daemon with resolver_unicast_daemon .

The lbmrd can run on any machine, including the source or receiver (enter lbmrd -h for instructions). Of course,sources will also have to select a transport protocol that uses unicast addressing (e.g. TCP, TCP-LB, or LBT-RU). Thelbmrd maintains a table of clients (address and port pairs) from which it has received a topic resolution message, whichcan be any of the following.

¨ Topic Information Records (TIR) - also known as topic advertisements

¨ Topic Query Records (TQR)

¨ keepalive messages, which are only used in unicast topic resolution

After lbmrd receives a TQR or TIR, it forwards it to all known clients. If a client (i.e. source or receiver) is not sendingeither TIRs or TQRs, it sends a keepalive message to lbmrd according to the resolver_unicast_keepalive_interval .This registration with the lbmrd allows the client to receive advertisements or queries from lbmrd. lbmrd maintains nostate about topics, only about clients.

Restriction: Unicast Topic Resolution is not supported on the OpenVMS® platform. UM applications running on theOpenVMS® platform, however, can use unicast topic resolution running on a different platform, such as MicrosoftWindows® or Linux.

LBMRD with the UM Router Best PracticeIf you're using the lbmrd for topic resolution across UM Routers, you may want all of your domains discovered and allroutes to be known before creating any topics. If so, change the UM configuration option,resolver_unicast_force_alive , from the default setting to 1 so your contexts start sending keepalives to lbmrdimmediately. This makes your startup process cleaner by allowing your contexts to discover the other TopicResolution Domains and establish the best routes. The tradeoff is a little more network traffic every 5 seconds.

Unicast Topic Information RecordsOf all topic resolution messages, only the TIR contains address and port information. This tells a receiver how it canget the data being published. Based on the transport type, a receiver can join the appropriate multicast group (forLBT-RM), send a connection request (for LBT-RU), or connect to the source (for TCP).

The address and port information potentially contained within a TIR includes:

¨ For a TCP transport, the source address and TCP port.

¨ For an LBT-RM transport, the unicast UDP port (to which NAKs are sent) and the UDP destination port.

¨ For an LBT-RU transport, the source address and UDP port.

For unicast-based transports (TCP and LBT-RU), the TIR source address is 0.0.0.0, not the actual source address.

Topic resolution messages (whether received by the application via multicast, or by the unicast topic resolutiondaemon via unicast) are always UDP datagrams. They are received via a recvfrom() call, which also obtains the

42 Chapter 4: Architecture

address and port from which the datagrams were received. If the address 0.0.0.0 (INADDR_ANY) appears for one ofthe addresses, lbmrd replaces it with the address from which the datagram is received. The net effect is as if the actualsource address had originally been put into the TIR.

Unicast Topic Resolution ResilienceRunning multiple instances of lbmrd allows your applications to continue operation in the face of a lbmrd failure. Yourapplications' sources and receivers send topic resolution messages as usual, however, rather than sending everymessage to each lbmrd instance, UM directs messages to lbmrd instances in a round-robin fashion. Since the lbmrddoes not maintain any resolver state, as long as one lbmrd instance is running, UM continues to forward LBMRpackets to all connected clients. UM switches to the next active lbmrd instance every 250-750 ms.

lbmrd Configuration FileThis section presents the syntax of the lbmrd configuration file, which is an XML file. Descriptions of elements alsoappear below. See also Unicast Resolver Example Configuration in the UM Configuration Guide for an example lbmrdconfiguration file.

<?xml version="1.0" encoding="UTF-8" ?><lbmrd version="1.0"> <domains> <domain name="domain-name-1"> <network>network-specification</network> </domain> <domain name="domain-name-2"> <network>network-specification</network> </domain> </domains> <transformations> <transform source="source-domain-name" destination="destination-domain-name"> <rule> <match address="original-address" port="original-port"/> <replace address="replacement-address" port="replacement-port"/> </rule> </transform> </transformations></lbmrd>

<lbmrd> Element

The <lbmrd> element is the root element. It requires a single attribute, version, which defines the version of the DTD tobe used. Currently, only version 1.0 is supported. The <lbmrd> element must contain a single <domains> element anda single <transformations> element.

<domains> Element

The <domains> element defines the set of network domains. The <domains> element may contain one or more<domain> elements. Each defines a separate domain.

<domain> Element Element

The <domain> element defines a single network domain. Each domain must be named via the name attribute. Thisname is referenced in <map> elements, which are discussed below. Each domain name must be unique. The<domain> element may contain one or more <network> elements.

<network> Element Element

The <network> element defines a single network specification which is to be considered part of the enclosing<domain>. The network specification must contain either an IP address, or a network specification in CIDR form.

<transformations> Element

Topic Resolution 43

The <transformations> element defines and contains the set of transformations to be applied to the TIRs. The<transformations> element contains one or more <transform> elements, described below.

<transformation> Element

The <transform> element defines a set of transformation tuples. Each tuple applies to a TIR sent from a specificnetwork domain (specified using the source attribute), and destined for a specific network domain (specified using thedestination attribute). The source and destination attributes must specify a network domain name as defined by the<domain> elements. The <transform> element contains one or more <rule> elements, described below.

<rule> Element

Each <rule> element is associated with the enclosing <transform> element, and completes the transformation tuple.The <rule> element must contain one <match> element, and one <replace> element, described below.

<match> Element

The <match> element defines the address and port to match within the TIR. The attributes address and port specifythe address and port. address must specify a full IP address (a network specification is not permitted). port specifiesthe port in the TIR. To match any port, specify port="*" (which is the default).

<replace> Element

The <replace> element defines the address and port which are to replace those matched in the TIR. The attributesaddress and port specify the address and port. address must specify a full IP address (a network specification is notpermitted). To leave the TIR port unchanged, specify port="*" (which is the default).

It is valid to specify port="*" for both <match> and <replace>. This effectively matches all ports for the given addressand changes only the address. It is important to note that TIR addresses and ports are considered together. Forexample, the Ultra Messaging R for the Enterprise option in the TIR contains the source address and port, and thestore address and port. When processing a transformation tuple, the source address and source port are considered(and transformed) together, and the store address and store port are considered (and transformed) together.

Message BatchingBatching many small messages into fewer network packets decreases the per-message CPU load, thereby increasingthroughput. Let's say it costs 2 microseconds of CPU to fully process a message. If you process 10 messages persecond, you won't notice the load. If you process half a million messages per second, you saturate the CPU. So toachieve high message rates, you have to reduce the per-message CPU cost with some form of message batching.These per-message costs apply to both the sender and the receiver. However, the implementation of batching isalmost exclusively the realm of the sender.

Many people are under the impression that while batching improves CPU load, it increases message latency. While itis true that there are circumstances where this can happen, it is also true that careful use of batching can result insmall latency increases or none at all. In fact, there are circumstances where batching can actually reduce latency.

UM allows the following methods for batching messages.

¨ “Implicit Batching” on page 45 - the default behavior, batching messages for individual transport sessions.

¨ “Adaptive Batching” on page 46 - a convenience feature of UM that monitors sending activity and automaticallydetermines the optimum time to flush the Implicit Batch buffer.

¨ “Intelligent Batching” on page 46 - a method that makes use of your application's knowledge of the messages itmust send, clearing the Implicit Batching buffer when sending the only remaining message.

¨ “Explicit Batching” on page 46 - provides greater control to your application through lbm_src_send() messageflags and also operates in conjunction with the Implicit Batching mechanism.

44 Chapter 4: Architecture

¨ “Application Batching” on page 47 - your application groups messages and sends them in a single batch.

Implicit BatchingUM automatically batches smaller messages into transport session datagrams. The implicit batching configurationoptions, implicit_batching_interval (default = 200 milliseconds) and implicit_batching_minimum_length (default =2048 bytes) govern UM implicit message batching. Although these are source options, they actually apply to thetransport session to which the source was assigned.

See Implicit Batching Options in the UM Configuration Guide.

See also “Source Configuration and Transport Sessions” on page 9.

UM establishes the implicit batching parameters when it creates the transport session. Any sources assigned to thattransport session use the implicit batching limits set for that transport session, and the limits apply to any and allsources subsequently assigned to that transport session. This means that batched transport datagrams can containmessages on multiple topics. See “Explicit Batching” on page 46 for information about topic-level messagebatching.

Implicit Batching OperationImplicit Batching buffers messages until:

¨ the buffer size exceeds the configured implicit_batching_minimum_length or

¨ the oldest message in the buffer has been in the buffer for implicit_batching_interval milliseconds.

When either condition is met, UM flushes the buffer, pushing the messages onto the network.

It may appear this design introduces significant latencies for low-rate topics. However, remember that ImplicitBatching operates on a transport session basis. Typically many low-rate topics map to the same transport session,providing a high aggregate rate. The implicit_batching_interval option is a last resort to prevent messages frombecoming stuck in the Implicit Batching buffer. If your UM deployment frequently uses the implicit_batching_intervalto push out the data (i.e. if the entire transport session has periods of inactivity longer than the value ofimplicit_batching_interval (defaults to 200 ms), then either the implicit batching options need to be fine-tuned(reducing one or both), or you should consider an alternate form of batching. See “Intelligent Batching” on page46.

The minimum value for the implicit_batching_interval is 3 milliseconds. The actual minimum amount of time thatdata stays in the buffer depends on your Operating System and its scheduling clock interval. For example, on a Solaris8 machine, the actual time is approximately 20 milliseconds. On Microsoft Windows machines, the time is probably 16milliseconds. On a Linux 2.6 kernel, the actual time is 3 milliseconds. Using a implicit_batching_interval value of 3guarantees the minimum possible wait for whichever operating system you are using.

Implicit Batching ExampleThe following example demonstrates how the implicit_batching_minimum_length is actually a trigger or floor, forsending batched messages. It is sometimes misconstrued as a ceiling or upper limit.

implicit_batching_minimum_length = 2000

1. The first send by your application puts 1900 bytes into the batching buffer, which is below the minimum, so UMholds it.

2. The second send fills the batching buffer to 3800 bytes, well over the minimum. UM sends it down to the transportlayer, which builds a 3800-byte (plus overhead) datagram and sends it.

Message Batching 45

3. The Operating System fragments the datagram into packets independently of UM and reassembles them on thereceiving end.

4. UM reads the datagram from the socket at the receiver.

5. UM parses out the two messages and delivers them to the appropriate topic levels, which deliver the data.

The proper setting of the implicit batching parameters often represents a tradeoff between latency and efficiency,where efficiency affects the highest throughput attainable. In general, a large minimum length setting increasesefficiency and allows a higher peak message rate, but at low message rates a large minimum length can increaselatency. A small minimum length can lower latency at low message rates, but does not allow the message rate to reachthe same peak levels due to inefficiency. An intelligent use of implicit batching and application-level flushing can beused to implement an adaptive form of batching known as “Intelligent Batching” on page 46 which can provide lowlatency and high throughput with a single setting.

Adaptive BatchingAdaptive Batching is a convenience batching feature that attempts to send messages immediately during periods oflow volume and automatically batch messages during periods of higher volume. The goal of Adaptive Batching is toautomatically optimize throughput and latency by monitoring such things as the time between calls tolbm_src_send(), the time messages spend in the Implicit Batching queue, the Rate Controller queue, and othersending activities. With this information, Adaptive Batching determines if sending batched messages now or laterproduces the least latency.

Adaptive Batching will not satisfy everyone's requirements of throughput and latency. You only need to turn it on anddetermine if it produces satisfactory performance. If it does, you need do nothing more. If you are not satisfied with theresults, simply turn it off.

You enable Adaptive Batching by setting implicit_batching_type to adaptive. When using Adaptive Batching, it isadvisable to increase the implicit_batching_minimum_length option to a higher value.

Intelligent BatchingIntelligent Batching uses Implicit Batching along with your application's knowledge of the messages it must send. It isa form of dynamic adaptive batching that automatically adjusts for different message rates. Intelligent Batching canprovide significant savings of CPU resources without adding any noticeable latency.

For example, your application might receive input events in a batch, and therefore know that it must produce acorresponding batch of output messages. Or the message producer works off of an input queue, and it can detectmessages in the queue.

In any case, if the application knows that it has more messages to send without going to sleep, it simply does normalsends to UM, letting Implicit Batching send only when the buffer meets the implicit_batching_minimum_lengththreshold. However, when the application detects that it has no more messages to send after it sends the currentmessage, it sets the FLUSH flag (LBM_MSG_FLUSH) when sending the message which instructs UM to flush theimplicit batching buffer immediately by sending all messages to the transport layer. Refer to lbm_src_send() in theUMS API documentation ( UM C API, UM Java API or UM .NET API) for all the available send flags.

When using Intelligent Batching, it is usually advisable to increase the implicit_batching_minimum_length option to10 times the size of the average message, to a maximum value of 8196. This tends to strike a good balance betweenbatching length and flushing frequency, giving you low latencies across a wide variation of message rates.

Explicit BatchingUM allows you to batch messages for a particular topic with explicit batching. When your application sends a message(lbm_src_send()) it may flag the message as being the start of a batch (LBM_MSG_START_BATCH) or the end of a

46 Chapter 4: Architecture

batch (LBM_MSG_END_BATCH). All messages sent between the start and end are grouped together. The flag usedto indicate the end of a batch also signals UM to send the message immediately to the implicit batching buffer. At thispoint, “Implicit Batching” on page 45 completes the batching operation. UM includes the start and end flags in themessage so receivers can process the batched messages effectively.

Unlike Intelligent Batching which allows intermediate messages to trigger flushing according to theimplicit_batching_minimum_length option, explicit batching holds all messages until the batch is completed. Thisfeature is useful if you configure a relatively small implicit_batching_minimum_length and your application has abatch of messages to send that exceeds the implicit_batching_minimum_length. By releasing all the messages atonce, Implicit Batching maximizes the size of the network datagrams.

Explicit Batching ExampleThe following example demonstrates explicit batching.

implicit_batching_minimum_length = 8000

1. Your application performs 10 sends of 100 bytes each as a single explicit batch.

2. At the 10th send (which completes the batch), UM delivers the 1000 bytes of messages to the implicit batchbuffer.

3. Let's assume that the buffer already has 7899 bytes of data in it from other topics on the same transportsession

4. UM adds the first 100-byte message to the buffer, bringing it to 7999.

5. UM adds the second 100-byte message, bringing it up to 8099 bytes, which exceedsimplicit_batching_minimum_length but is below the 8192 maximum datagram size.

6. UM sends the 8099 bytes (plus overhead) datagram.

7. UM adds the third through tenth messages to the implicit batch buffer. These messages will be sent when eitherimplicit_batching_minimum_length is again exceeded, or the implicit_batching_interval is met, or a messagearrives in the buffer with the flush flag (LBM_MSG_FLUSH) set.

Application BatchingIn all of the above situations, your application sends individual messages to UM and lets UM decide when to push thedata onto the wire (often with application help). With application batching, your application buffers messages itself andsends a group of messages to UM with a single send. Thus, UM treats the send as a single message. On the receivingside, your application needs to know how to dissect the UM message into individual application messages.

This approach is most useful for Java or .NET applications where there is a higher per-message cost in delivering anUM message to the application. It can also be helpful when using an event queue to deliver received messages. Thisimposes a thread switch cost for each UM message. At low message rates, this extra overhead is not noticeable.However, at high message rates, application batching can significantly reduce CPU overhead.

Ordered DeliveryWith the Ordered Delivery feature, a receiver's delivery controller can deliver messages to your application insequence number order or arrival order. This feature can also reassemble fragmented messages or leave reassemblyto the application. You can set Ordered Delivery via UM configuration option to one of three modes:

¨ Sequence Number Order, Fragments Reassembled

Ordered Delivery 47

¨ Arrival Order, Fragments Not Reassembled

¨ Arrival Order, Fragments Reassembled

Sequence Number Order, Fragments Reassembled (Default Mode)In this mode, a receiver's delivery controller delivers messages in sequence number order (the same order in whichthey are sent). This feature also guarantees reassembly of fragmented large messages. To enable sequence numberordered delivery, set the ordered_delivery configuration option as shown:

receiver ordered_delivery 1

Please note that ordered delivery can introduce latency when packets are lost.

Arrival Order, Fragments Not ReassembledThis mode allows messages to be delivered to the application in the order they are received. If a message is lost, UMwill retransmit the message. In the meantime, any subsequent messages received are delivered immediately to theapplication, followed by the dropped packet when its retransmission is received. This mode guarantees the lowestlatency.

With this mode, the receiver delivers messages larger than the transport's maximum datagram size as individualfragments. (See transport_*_datagram_max_size in the Ultra Messaging Configuration Guide.) The C API function,lbm_msg_retrieve_fragment_info() returns fragmentation information for the message you pass to it, and can be usedto reassemble large messages. (In Java and .NET, LBMMessage provides methods to return the same fragmentinformation.) Note that reassembly is not required for small messages.

To enable this no-reassemble arrival-order mode, set the following configuration option as shown:

receiver ordered_delivery 0

When developing message reassembly code, consider the following:

¨ Message fragments don't necessarily arrive in sequence number order.

¨ Some message fragments may never arrive (unrecoverable loss), so you must time out partial messages.

Arrival Order, Fragments ReassembledThis mode delivers messages in the order they are received, except for fragmented messages, which UMreassembles before delivering to your application. Your application can then use the sequence_number field oflbm_msg_t objects to order or discard messages.

To enable this arrival-order-with-reassembly mode, set the following configuration option as shown:

receiver ordered_delivery -1

Loss Detection Using TSNIsWhen a source enters a period during which it has no data traffic to send, that source issues timed Topic SequenceNumber Info (TSNI) messages. The TSNI lets receivers know that the source is still active and also reminds receiversof the sequence number of the last message. This helps receivers become aware of any lost messages betweenTSNIs.

Sources send TSNIs over the same transport and on the same topic as normal data messages. You can set a timevalue of the TSNI interval with configuration option transport_topic_sequence_number_info_interval. You can also set

48 Chapter 4: Architecture

a time value for the duration that the source sends contiguous TSNIs with configuration optiontransport_topic_sequence_number_info_active_threshold, after which time the source stops issuing TSNIs.

Receiver Keepalive Using Sesssion MessagesWhen an LBT-RM, LBT-RU, or LBT-IPC transport session enters a period during which it has no data traffic to send,UM issues timed Session Messages (SMs). For example, suppose all topics in a session stop sending data. One byone, they then send TSNIs, and if there is still no data to send, their TSNI periods eventually expire. After the lastquiescent topic's TSNIs stop, UM begins transmitting SMs.

You can set time values for SM interval and duration with configuration options specific to their transport type.

Receiver Keepalive Using Sesssion Messages 49

C H A P T E R 5

UMS FeaturesThis chapter includes the following topics:

¨ Using Late Join, 50

¨ Off-Transport Recovery (OTR), 55

¨ Request/Response Model, 57

¨ Self Describing Messaging, 59

¨ Pre-Defined Messaging, 59

¨ Multicast Immediate Messaging, 73

¨ Spectrum, 77

¨ Hot Failover, 77

Using Late JoinThis section introduces the use of UM Late Join in default and specialized configurations. Specifically, this section onUM Late Join includes:

¨ “Late Join Overview” on page 50

¨ “Late Join Options Summary” on page 52

¨ “Using Default Late Join Options” on page 52

¨ “Specifying a Range of Messages to Retransmit” on page 53

¨ “Retransmitting Only Recent Messages” on page 54

¨ “Configuring Late Join for Large Numbers of Messages” on page 54

See the UM Configuration Guide for specific information about Late Join configuration options.

Note: If your application is running within a UM context with configuration option request_tcp_bind_request_port setto zero, then request port binding has been turned off, which also disables the Late Join feature.

Late Join OverviewThe Late Join feature enables newly created receivers to receive previously transmitted messages. Sourcesconfigured for Late Join maintain a retention buffer (not to be confused with a transport retransmission window), whichholds transmitted messages for late-joining receivers.

50

A Late Join operation follows the following sequence:

1. A new receiver configured for Late Join with use_late_join completes topic resolution. Topic advertisements fromthe source contain a flag that indicates the source is configured for Late Join with late_join.

2. The new receiver sends a Late Join Initiation Request (LJIR) to request a previously transmitted messages. Thereceiver configuration option, retransmit_request_outstanding_maximum, determines the number of messages thereceiver requests.

3. The source responds with a Late Join Information (LJI) message containing the sequence numbers for theretained messages that are available for retransmission.

4. The source unicasts the messages.

5. When “Configuring Late Join for Large Numbers of Messages” on page 54, the receiver issues additionalrequests, and the source retransmits these additional groups of older messages, oldest first.

Figure 10. Late Join Message Path

The source's retention buffer's is not pre-allocated and occupies an increasing amount of memory as the sourcesends messages and adds them to the buffer. If a retention buffer grows to a size equal to the value of the sourceconfiguration option, retransmit_retention_size_threshold, the source deletes older messages as it adds new ones.The source configuration option retransmit_retention_age_threshold, controls message deletion based on messageage.

Note: UM uses control-structure overhead memory on a per-message basis for messages held in the retentionbuffer, in addition to the retention buffer's memory. Such memory usage can become significantly higher whenretained messages are smaller in size, since more of them can then fit in the retention buffer.

Attention: If you set the receiver configuration option ordered_delivery to 1, the receiver must deliver messages toyour application in sequence number order. The receiver holds out-of-order messages in an ordered list cache untilmessages arrive to fill the sequence number gaps. If an out-of-order message arrives with a sequence number thatcreates a message gap greater than the value of retransmit_message_caching_proximity, the receiver creates a burstloss event and terminates the Late Join recovery operation. You can increase the value of the proximity option andrestart the receiver, but a burst loss is a significant event and you should investigate your network and messagesystem components for failures.

Using Late Join 51

Late Join Options SummaryFollowing is a summary of Late join configuration options. Please refer to UM Configuration Guide for full descriptionsof these options.

scope (object) option

source late_join

source retransmit_retention_age_threshold

source retransmit_retention_size_limit

source retransmit_retention_size_threshold

receiver use_late_join

receiver retransmit_initial_sequence_number_request

receiver retransmit_message_caching_proximity

receiver retransmit_request_message_timeout

receiver retransmit_request_interval

receiver retransmit_request_maximum

receiver retransmit_request_outstanding_maximum

Using Default Late Join OptionsTo implement Late Join with default options, set the Late Join configuration options to activate the feature on both asource and receiver in the following manner.

1. Create a configuration file with source and receiver Late Join activation options set to 1. For example, filecfg1.cfg containing the two lines:

source late_join 1 receiver use_late_join 1

2. Run an application that starts a Late-Join-enabled source. For example:

lbmsrc -c cfg1.cfg -P 1000 topicName

3. Wait a few seconds, then run an application that starts a Late-Join-enabled receiver. For example:

lbmrcv -c cfg1.cfg -v topicName

The output for each should closely resemble the following.

LBMSRC

$ lbmsrc -c cfg1.cfg -P 1000 topicName LOG Level 5: NOTICE: Source "topicName" has no retention settings (1 message retained max) Sending 10000000 messages of size 25 bytes to topic [topicName] Receiver connect [TCP:10.29.3.77:34200]

52 Chapter 5: UMS Features

LBMRCV

$ lbmrcv -c cfg1.cfg -v topicName Immediate messaging target: TCP:10.29.3.77:4391 [topicName][TCP:10.29.3.76:4371][2]-RX-, 25 bytes 1.001 secs. 0.0009988 Kmsgs/sec. 0.1998 Kbps [topicName][TCP:10.29.3.76:4371][3], 25 bytes 1.002 secs. 0.0009982 Kmsgs/sec. 0.1996 Kbps [topicName][TCP:10.29.3.76:4371][4], 25 bytes 1.003 secs. 0.0009972 Kmsgs/sec. 0.1994 Kbps [topicName][TCP:10.29.3.76:4371][5], 25 bytes 1.003 secs. 0.0009972 Kmsgs/sec. 0.1994 Kbps

Note that the source only retained 1 Late Join message (due to default retention settings) and that this messageappears as a retransmit (-RX-). Also note that it is possible to sometimes receive 2 RX messages in this scenario (see“Retransmitting Only Recent Messages” on page 54.)

Specifying a Range of Messages to RetransmitTo receive more than one or two Late Join messages, increase the source's retransmit_retention_size_thresholdfrom its default value of 0. Once the buffer exceeds this threshold, the source allows the next new message enteringthe retention buffer to bump out the oldest one. Note that this threshold's units are bytes (which includes a smalloverhead per message).

While the retention threshold endeavors to keep the buffer size close to its value, it does not set hard upper limit forretention buffer size. For this, the retransmit_retention_size_limit configuration option (also in bytes) sets thisboundary.

Follow the steps below to demonstrate how a source can retain about 50MB of messages, but no more than 60MB:

1. Create a second configuration file (cfg2.cfg) with the following options:

source late_join 1 source retransmit_retention_size_threshold 50000000 source retransmit_retention_size_limit 60000000 receiver use_late_join 1

2. Run lbmsrc -c cfg2.cfg -P 1000 topicName.

3. Wait a few seconds and run lbmrcv -c cfg2.cfg -v topicName.

The output for each should closely resemble the following.

LBMSRC

$ lbmsrc -c cfg2.cfg -P 1000 topicName Sending 10000000 messages of size 25 bytes to topic [topicName] Receiver connect [TCP:10.29.3.76:34444]

LBMRCV

$ lbmrcv -c cfg2.cfg -v topicName Immediate messaging target: TCP:10.29.3.76:4391 [topicName][TCP:10.29.3.77:4371][0]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][1]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][2]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][3]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][4]-RX-, 25 bytes 1.002 secs. 0.004991 Kmsgs/sec. 0.9981 Kbps [topicName][TCP:10.29.3.77:4371][5], 25 bytes 1.002 secs. 0.0009984 Kmsgs/sec. 0.1997 Kbps [topicName][TCP:10.29.3.77:4371][6], 25 bytes 1.002 secs. 0.0009983 Kmsgs/sec. 0.1997 Kbps [topicName][TCP:10.29.3.77:4371][7], 25 bytes

Using Late Join 53

Note that lbmrcv received live messages with sequence numbers 7, 6, and 5, and RX messages going from 4 all theway back to Sequence Number 0.

Retransmitting Only Recent MessagesThus far we have worked with only source late join settings, but suppose that you want to receive only the last 10messages. To do this, configure the receiver option retransmit_request_maximum to set how many messages torequest backwards from the latest message.

Follow the steps below to set this option to 10.

1. Add the following line to cfg2.cfg and rename it cfg3.cfg.receiver retransmit_request_maximum 10

2. Run lbmsrc -c cfg3.cfg -P 1000 topicName.

3. Wait a few seconds and run lbmrcv -c cfg3.cfg -v topicName.

The output for each should closely resemble the following.

LBMSRC

$ lbmsrc -c cfg3.cfg -P 1000 topicName Sending 10000000 messages of size 25 bytes to topic [topicName] Receiver connect [TCP:10.29.3.76:34448]

LBMRCV

$ lbmrcv -c cfg3.cfg -v topicName Immediate messaging target: TCP:10.29.3.76:4391 [topicName][TCP:10.29.3.77:4371][13]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][14]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][15]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][16]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][17]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][18]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][19]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][20]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][21]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][22]-RX-, 25 bytes [topicName][TCP:10.29.3.77:4371][23]-RX-, 25 bytes 1.002 secs. 0.01097 Kmsgs/sec. 2.195 Kbps [topicName][TCP:10.29.3.77:4371][24], 25 bytes 1.002 secs. 0.0009984 Kmsgs/sec. 0.1997 Kbps [topicName][TCP:10.29.3.77:4371][25], 25 bytes 1.002 secs. 0.0009984 Kmsgs/sec. 0.1997 Kbps [topicName][TCP:10.29.3.77:4371][26], 25 bytes

Note that 11, not 10, retransmits were actually received. This can happen because network and timing circumstancesmay have one RX already in transit while the specific RX amount is being processed. (Hence, it is not possible toguarantee one and only one RX message for every possible Late Join recovery.)

Configuring Late Join for Large Numbers of MessagesSuppose you have a receiver that comes up at midday and must gracefully catch up on the large number of messagesit has missed. The following discussion explains the relevant Late Join options and how to use them.

retransmit_request_outstanding_maximum (receiver)When a receiver comes up and begins requesting Late Join messages, it does not simply request messages startingat Sequence Number 0 through 1000000. Rather, it requests the messages a little at a time, depending upon howoption retransmit_request_outstanding_maximum is set. set. For example, when set to the default of 200, the receiver

54 Chapter 5: UMS Features

sends requests the first 200 messages (Sequence Number 0 - 199). Upon receiving Sequence Number 0, it thenrequests the next message (200), and so on, limiting the number of outstanding unfulfilled requests to 200.

Note that in some environments, the default of 200 messages may be too high and overwhelm receivers with RXs,which can cause loss in a live LBT-RM stream. However, in other situations higher values can increase the rate of RXsreceived.

retransmit_message_caching_proximity (receiver)When sequence number delivery order is used, long recoveries of active sources can create receiver memory cacheproblems due to the processing of both new and retransmitted messages. This option provides a method to controlcaching and cache size during recovery.

It does this by comparing the option value (default 2147483647) to the difference between the newest (live) receivedsequence number and the latest received RX sequence number. If the difference is less than the option's value, thereceiver caches incoming live new messages. Otherwise, new messages are dropped and not cached (with theassumption that they can be requested later as retransmissions).

For example, as shown in the figure below, a receiver may be receiving both live streaming messages (latest, #200)and catch-up retransmissions (latest, #100). The difference here is 100. If retransmit_message_caching_proximity is75, the receiver caches the live messages and will deliver them when it is all caught up with the retransmissions.However, if this option is 150, streamed messages are dropped and later picked up again as a retransmission.

The default value of this option is high enough to still encourage caching most of the time, and should be optimal formost receivers.

If your source streams faster than it retransmits, caching is beneficial, as it ensures new data is received only once,thus reducing recovery time. If the source retransmits faster than it streams, which is the optimal condition, you canlower the value of this option to use less memory during recovery, with little performance impact.

Off-Transport Recovery (OTR)Off-Transport Recovery (OTR) is a lost-message-recovery feature that provides a level of hedging against thepossibility of brief and incidental unrecoverable loss at the transport level or from a UM Router. This section describesthe OTR feature.

OTR OverviewWhen a transport cannot recover lost messages, OTR engages and looks to the source for message recovery. It doesthis by accessing the source's retention buffer (used also by the Late Join feature) to re-request messages that nolonger exist in a transport's transmission window or other places such as a UMP store or redundant source.

OTR functions in a manner very similar to that of Late Join, but differs mainly in that it activates in message losssituations rather than following the creation of a receiver, and shares only the source late_join option setting.

Off-Transport Recovery (OTR) 55

Upon detecting loss, a receiver initiates OTR by sending repeated, spaced, OTR requests to the source, until itrecovers lost messages or a timeout period elapses.

OTR operates independently from transport-level recovery mechanisms such as NAKs for LBT-RU or LBT-RM. Whenyou enable OTR for a receiver with use_otr, the otr_request_initial_delay period starts as soon as the deliverycontroller detects a sequence gap. If the gap is not resolved by the end of the delay interval, OTR recovery initiates.OTR recovery can occur before, during or after transport-level recovery attempts.

When a receiver initiates OTR, the intervals between OTR requests increases twofold after each request, until themaximum interval is reached (assuming the receiver is still waiting to receive the retransmission). You useconfiguration options otr_request_minimum_interval and otr_request_maximum_interval to set the initial (minimum)and maximum intervals, respectively.

The source retransmits lost messages to the recovered receiver via unicast.

OTR with Sequence Number Ordered DeliveryWhen sequence number delivery order is used and a gap of missing messages occurs, a receiver buffers the newincoming messages while it attempts to recover the earlier missing ones. Long recoveries of actively streamingsources can cause excessive receiver cache memory growth due to the processing of both new and retransmittedmessages. You can control caching and cache size during recovery with options otr_message_caching_threshold andretransmit_message_caching_proximity.

The option otr_message_caching_threshold sets the maximum number of messages a receiver can buffer. When thenumber of cached messages hits this threshold, new streamed messages are dropped and not cached, with theassumption that they can be requested later as retransmissions.

The retransmit_message_caching_proximity, which is also used by Late Join (see “retransmit_message_caching_proximity (receiver)” on page 55), turns off this caching if there are too manymessages to buffer between the last delivered message and the currently streaming messages.

Both of these option thresholds must be satisfied before caching resumes.

OTR Options SummaryThe following set of configuration options govern OTR functionality. Please refer to the Ultra Messaging ConfigurationGuide for full descriptions of these options. You can click the individual links below for each option's description.

scope (object) option

source late_join

source retransmit_retention_age_threshold

source retransmit_retention_size_limit

source retransmit_retention_size_threshold

receiver use_otr

receiver otr_request_message_timeout

receiver otr_request_initial_delay

receiver otr_request_log_alert_cooldown

56 Chapter 5: UMS Features

scope (object) option

receiver otr_request_maximum_interval

receiver otr_request_minimum_interval

receiver otr_request_outstanding_maximum

receiver otr_message_caching_threshold

receiver retransmit_message_caching_proximity

Request/Response ModelThis section discusses the following topics.

¨ “Request Message” on page 57

¨ “Response Message” on page 57

¨ “TCP Management” on page 58

¨ “Configuration” on page 58

¨ “Example Applications” on page 58

Request MessageUM provides three ways to send a request message.

¨ lbm_send_request() to send a request to a topic via a source object. Uses the standard source-based transports(TCP, LBT-RM, LBT-RU).

¨ lbm_multicast_immediate_request() to send a request to a topic as a multicast immediate message. See “Multicast Immediate Messaging” on page 73.

¨ lbm_unicast_immediate_request() to send a request to a topic as a unicast immediate message. See “MulticastImmediate Messaging” on page 73.

The request function returns a request object and defines an application callback for responses that allows thereceiving application to send a response directly to the requesting application via a special TCP connection instead ofa normal data transport. The requesting application -- not UM -- determines how many responses it needs. Therefore,it must delete the request object when it no longer wants to receive responses by calling lbm_request_delete(). Itdiscards any responses that arrive after the request object has been deleted.

Response MessageAn application responds to an UM request message by calling lbm_send_response(). Contained within that requestmessage's header is a response object, which serves as a return address to the requester. UM passes the responseobject to lbm_send_response(). Since the response object is part of the message header, it is deleted at the sametime that the message is deleted. Therefore, if the sending of the response cannot be done within the responder'sreceive callback, the message must be retained and subsequently deleted.

Request/Response Model 57

TCP ManagementUM creates and manages the special TCP connections for responses, maintaining a list of active responseconnections . When an application sends a response, UM scans that list for an active connection to the destination. If itdoesn't find a connection for the response, it creates a new connection and adds it to the list. After thelbm_send_response() function returns, UM schedules the response_tcp_deletion_timeout, which defaults to 2seconds. If a second request comes in from the same application before the timer expires, the responding applicationsimply uses the existing connection and restarts the deletion timer.

It is conceivable that a very large response could take more than the response_tcp_deletion_timeout default (2seconds) to send to a slow-running receiver. In this case, UM automatically increases the deletion timer as needed toensure the last message completes.

ConfigurationSee the UM Configuration Guide for the descriptions of the Request/Response configuration options.

¨ Request Network Options

¨ Request Operations Options

¨ Response Operation Options

Note: If your application is running within an UM context where the configuration option,request_tcp_bind_request_port has been set to zero, request port binding has been turned off, which also disablesthe Request/Response feature.

Example ApplicationsUM includes two example applications that illustrate Request/Response.

¨ lbmreq.c - application that sends requests on a given topic (single source) and waits for responses. See also theJava example, lbmreq.java, and the .NET example, lbmreq.cs.

¨ lbmresp.c - application that waits for requests and sends responses back on a given topic (single receiver). Seealso the Java example, lbmresp.java, and the .NET example, lbmresp.cs.

We can demonstrate a series of 5 requests and responses with the following procedure.

1. Run lbmresp -v topicname2. Run lbmreq -R 5 -v topicnameLBMREQ

Output for lbmreq should resemble the following.

$ lbmreq -R 5 -q topicnameEvent queue in useUsing TCP port 4392 for responsesDelaying requests for 1000 millisecondsSending request 0Starting event pump for 5 seconds.Receiver connect [TCP:10.29.1.78:4958]Done waiting for responses. 1 responses (25 bytes) received. Deleting request. Sending request 1Starting event pump for 5 seconds.Done waiting for responses. 1 responses (25 bytes) received. Deleting request. Sending request 2Starting event pump for 5 seconds.Done waiting for responses. 1 responses (25 bytes) received. Deleting request. Sending request 3Starting event pump for 5 seconds.Done waiting for responses. 1 responses (25 bytes) received. Deleting request. Sending request 4Starting event pump for 5 seconds.Done waiting for responses. 1 responses (25 bytes) received. Deleting request.Quitting...

58 Chapter 5: UMS Features

LBMRESP

Output for lbmresp should resemble the following.

$ lbmresp -v topicnameRequest [topicname][TCP:10.29.1.78:14371][0], 25 bytesSending response. 1 responses of 25 bytes each (25 total bytes).Done sending responses. Deleting response.Request [topicname][TCP:10.29.1.78:14371][1], 25 bytesSending response. 1 responses of 25 bytes each (25 total bytes).Done sending responses. Deleting response.Request [topicname][TCP:10.29.1.78:14371][2], 25 bytesSending response. 1 responses of 25 bytes each (25 total bytes).Done sending responses. Deleting response.Request [topicname][TCP:10.29.1.78:14371][3], 25 bytesSending response. 1 responses of 25 bytes each (25 total bytes).Done sending responses. Deleting response.Request [topicname][TCP:10.29.1.78:14371][4], 25 bytesSending response. 1 responses of 25 bytes each (25 total bytes).Done sending responses. Deleting response.[topicname][TCP:10.29.1.78:14371], End of Transport Session

Self Describing MessagingThe UM Self-Describing Messaging (SDM) feature provides an API that simplifies the creation and use of messagesby your applications. An SDM message contains one or more fields and each field consists of the following.

¨ A name

¨ A type

¨ A value

Each named field may appear only once in a message. If multiple fields of the same name and type are needed, arrayfields are available. A field in a nested message may have the same name as a field in the outer message.

SDM is particularly helpful for creating messages sent across platforms by simplifying the creation of data formats.SDM automatically performs platform-specific data translations, eliminating Endianess conflicts.

Using SDM also simplifies message maintenance because the message format or structure can be independent of thesource and receiver applications. For example, if your receivers query SDM messages for particular fields and ignorethe order of the fields within the message, a source can change the field order if necessary with no modification of thereceivers needed.

Use the following links to access a complete reference of SDM functions, field types and message field operations.

¨ C Application Programmer's Interface — click on the Files tab at the top and select lbmsdm.h.

¨ Java Application Programmer's Interface — select com.latencybusters.lbm.sdm under Packages.

¨ .NET Application Programmer's Interface — select the com.latencybusters.lbm.sdm Namespace.

Restriction: The Self-Describing Messaging (SDM) feature is not supported on the OpenVMS® platform.

Pre-Defined MessagingThe UM Pre-Defined Messaging (PDM) feature provides an API similar to the SDM API, but allows you to definemessages once and then use the definition to create messages that may contain self-describing data. Eliminating the

Self Describing Messaging 59

need to repeatedly send a message definition increases the speed of PDM over SDM. The ability to use arrays createdin a different programming language also improves performance.

The PDM library lets you create, serialize, and deserialize messages using pre-defined knowledge about the possiblefields that may be used. You can create a definition that a) describes the fields to be sent and received in a message,b) creates the corresponding message, and c) adds field values to the message. This approach offers severalperformance advantages over SDM, as the definition is known in advance. However, the usage pattern is slightlydifferent than the SDM library, where fields are added directly to a message without any type of definition.

A PDM message contains one or more fields and each field consists of the following.

¨ A name

¨ A type

¨ A value

Each named field may appear only once in a message. If multiple fields of the same name and type are needed, arrayfields are available. A field in a nested message may have the same name as a field in the outer message.

See the C, Java, and .NET Application Programmer's Interfaces for complete references of PDM functions, field typesand message field operations. The C API also has information and code samples about how to create definitions andmessages, set field values in a message, set the value of array fields in a message, serialize, deserialize and disposeof messages, and fetch values from a message. See the following API documentation:

¨ C Application Programmer's Interface — click on the Files tab at the top and select lbmpdm.h.

¨ Java Application Programmer's Interface — select com.latencybusters.lbm.pdm under Packages.

¨ .NET Application Programmer's Interface — select the com.latencybusters.lbm.pdm Namespace.

Restriction: The Pre-Defined Messaging (PDM) feature is not supported on the OpenVMS® platform.

Typical PDM Usage PatternsThe typical PDM usage patterns can usually be broken down into two categories: sources (which need to serialize amessage for sending) and receivers (which need to deserialize a message to extract field values). However, foroptimum performance for both sources and receivers, first set up the definition and a single instance of the messageonly once during a setup or initialization phase, as in the following example workflow:

1. Create a definition and set its id and version.

2. Add field information to the definition to describe the types of fields to be in the message.

3. Create a single instance of a message based on the definition.

Set up a source to do the following:

1. Add field values to the message instance.

2. Serialize the message so that it can be sent.

Likewise, set up a receiver to do the following:

1. Deserialize the received bytes into the message instance.

2. Extract the field values from the message.

Getting StartedPDM APIs are provided in C, Java, and C#, however, the examples in this section are Java based.

60 Chapter 5: UMS Features

PDM Code Example, SourceTranslating the Typical PDM Usage Patterns to Java for a source produces the following:

private PDMDefinition defn;private PDMMessage msg;private PDMFieldInfo fldInfo100;private PDMFieldInfo fldInfo101;private PDMFieldInfo fldInfo102;

public void setupPDM() { //Create the definition with 3 fields and using int field names defn = new PDMDefinition(3, true); //Set the definition id and version defn.setId(1001); defn.setMsgVersMajor((byte)1); defn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float fields (all required) fldInfo100 = defn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); fldInfo101 = defn.addFieldInfo(101, PDMFieldType.INT32, true); fldInfo102 = defn.addFieldInfo(102, PDMFieldType.FLOAT, true); //Finalize the definition and create the message defn.finalizeDef(); msg = new PDMMessage(defn);}

public void sourceUsePDM() { //Call the function to setup the definition and message setupPDM(); //Example values for the message boolean fld100Val = true; int fld101Val = 7; float fld102Val = 3.14F; //Set each field value in the message msg.setFieldValue(fldInfo100, fld100Val); msg.setFieldValue(fldInfo101, fld101Val); msg.setFieldValue(fldInfo102, fld102Val); //Serialize the message to bytes byte[] buffer = msg.toBytes();}

PDM Code Example, ReceiverTranslating the Typical PDM Usage Patterns to Java for a receiver produces the following:

private PDMDefinition defn;private PDMMessage msg;private PDMFieldInfo fldInfo100;private PDMFieldInfo fldInfo101;private PDMFieldInfo fldInfo102;

public void setupPDM() { //Create the definition with 3 fields and using int field names defn = new PDMDefinition(3, true); //Set the definition id and version defn.setId(1001); defn.setMsgVersMajor((byte)1); defn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float field (all required) fldInfo100 = defn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); fldInfo101 = defn.addFieldInfo(101, PDMFieldType.INT32, true); fldInfo102 = defn.addFieldInfo(102, PDMFieldType.FLOAT, true);

Pre-Defined Messaging 61

//Finalize the definition and create the message defn.finalizeDef(); msg = new PDMMessage(defn);}

public void receiverUsePDM(byte[] buffer) { //Call the function to setup the definition and message setupPDM(); //Values to be retrieved from the message boolean fld100Val; int fld101Val; float fld102Val; //Deserialize the bytes into a message msg.parse(buffer); //Get each field value from the message fld100Val = msg.getFieldValueAsBoolean(fldInfo100); fld101Val = msg.getFieldValueAsInt32(fldInfo101); fld102Val = msg.getFieldValueAsFloat(fldInfo102);}

PDM Code Example NotesIn the examples above, the setupPDM() function is called once to set up the PDM definition and message. It isidentical in both the source and receiver cases and simply sets up a definition that contains three required fields withinteger names (100, 101, 102). Once finalized, it can create a message that leverages its pre-defined knowledgeabout these three required fields. The source example adds the three sample field values (a boolean, int32, and float)to the message, which is then serialized to a byte array. In the receiver example, the message parses a byte array intothe message and then extracts the three field values.

Using the PDM APIThe following code snippets expand upon the previous examples to demonstrate the usage of additional PDMfunctionality (but use "..." to eliminate redundant code).

Reusing the Message ObjectAlthough the examples use a single message object (which provides performance benefits due to reduced messagecreation and garbage collection), it is not explicitly required to reuse a single instance. However, multiple threadsshould not access a single message instance.

Number of FieldsAlthough the number of fields above is initially set to 3 in the PDMDefinition constructor, if you add more fields to thedefinition with the addFieldInfo method, the definition grows to accommodate each field. Once the definition isfinalized, you cannot add additional field information because the definition is now locked and ready for use in amessage.

String Field NamesThe examples above use integer field names in the setupPDM() function when creating the definition. You can alsouse string field names when setting up the definition. However, you still must use a FieldInfo object to set or get a fieldvalue from a message, regardless of field name type. Notice that false is passed to the PDMDefinition constructor toindicate string field names should be used. Also, the overloaded addFieldInfo function uses string field names(.Field100.) instead of the integer field names.

...

62 Chapter 5: UMS Features

public void setupPDM() { //Create the definition with 3 fields and using string field names defn = new PDMDefinition(3, false); ... //Create information for a boolean, int32, and float field (all required)fldInfo100 = defn.addFieldInfo("Field100", PDMFieldType.BOOLEAN, true); fldInfo101 = defn.addFieldInfo("Field101", PDMFieldType.INT32, true); fldInfo102 = defn.addFieldInfo("Field102", PDMFieldType.FLOAT, true); ...}...

Retrieving FieldInfo from the DefinitionAt times, it may be easier to lookup the FieldInfo from the definition using the integer name (or string name if used).This eliminates the need to store the reference to the FieldInfo when getting or setting a field value in a message, butit does incur a performance penalty due to the lookup in the definition to retrieve the FieldInfo. Notice that there are nolonger FieldInfo objects being used when calling addFieldInfo and a lookup is being done for each call tomsg.getFieldValueAs* to retrieve the FieldInfo by integer name.

private PDMDefinition defn;private PDMMessage msg;

public void setupPDM() { ... //Create information for a boolean, int32, and float field (all required) defn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); defn.addFieldInfo(101, PDMFieldType.INT32, true); defn.addFieldInfo(102, PDMFieldType.FLOAT, true); ...}

public void receiverUsePDM(byte[] buffer) { ... //Get each field value from the message fld100Val = msg.getFieldValueAsBoolean(defn.getFieldInfo(100)); fld101Val = msg.getFieldValueAsInt32(defn.getFieldInfo(101)); fld102Val = msg.getFieldValueAsFloat(defn.getFieldInfo(102));}

Required and Optional FieldsWhen adding field information to a definition, you can indicate that the field is optional and may not be set for everymessage that uses the definition. Do this by passing false as the third parameter to the addFieldInfo function. Usingrequired fields (fixed-required fields specifically) produces the best performance when serializing and deserializingmessages, but causes an exception if all required fields are not set before serializing the message. Optional fieldsallow the concept of sending "null" as a value for a field by simply not setting that field value on the source side beforeserializing the message. However, after parsing a message, a receiver should check the isFieldValueSet function foran optional field before attempting to read the value from the field to avoid the exception mentioned above.

...private PDMFieldInfo fldInfo103;...public void setupPDM() { ...//Create information for a boolean, int32, and float field (all required) // as well as an optional int8 fieldfldInfo100 = defn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); fldInfo101 = defn.addFieldInfo(101, PDMFieldType.INT32, true); fldInfo102 = defn.addFieldInfo(102, PDMFieldType.FLOAT, true); fldInfo103 = defn.addFieldInfo(103, PDMFieldType.INT8, false); ...}

public void sourceUsePDM() { ...

Pre-Defined Messaging 63

//Set each field value in the message // except do not set the optional field msg.setFieldValue(fldInfo100, fld100Val); msg.setFieldValue(fldInfo101, fld101Val); msg.setFieldValue(fldInfo102, fld102Val);...}

...private PDMFieldInfo fldInfo103;...public void setupPDM() { ...//Create information for a boolean, int32, and float field (all required) // as well as an optional int8 field fldInfo103 = defn.addFieldInfo(103, PDMFieldType.INT8, false); ...}public void receiverUsePDM(byte[] buffer) { ... byte fld103Val; ... if(msg.isFieldValueSet(fldInfo103)) { fld103Val = msg.getFieldValueAsInt8(fldInfo103); }}

Fixed String and Fixed Unicode Field TypesA variable length string typically does not have the performance optimizations of fixed-required fields. However, byindicating "required", as well as the field type FIX_STRING or FIX_UNICODE and specifying an integer number offixed characters, PDM sets aside an appropriate fixed amount of space in the message for that field and treats it as anoptimized fixed-required field. Strings of a smaller length can still be set as the value for the field, but the messageallocates the specified fixed number of bytes for the string. Specify unicode strings in the same manner (withFIX_UNICODE as the type) and in "UTF-8" format.

...private PDMFieldInfo fldInfo104;...public void setupPDM() { ... fldInfo104 = defn.addFieldInfo(104, PDMFieldType.FIX_STRING, 12, true); ...}

public void sourceUsePDM() { ... String fld104Val = "Hello World!"; //Set each field value in the message // except do not set the optional field msg.setFieldValue(fldInfo100, fld100Val); msg.setFieldValue(fldInfo101, fld101Val); msg.setFieldValue(fldInfo102, fld102Val); msg.setFieldValue(fldInfo104, fld104Val);...}

...private PDMFieldInfo fldInfo104;...public void setupPDM() { ... fldInfo104 = defn.addFieldInfo(104, PDMFieldType.FIX_STRING, 12, true); ...}

64 Chapter 5: UMS Features

public void receiverUsePDM(byte[] buffer) { ... String fld104Val; ... fld104Val = msg.getFieldValueAsString(fldInfo104);}

Variable Field TypesThe field types of STRING, UNICODE, BLOB, and MESSAGE are all variable length field types. They do not require alength to be specified when adding field info to the definition. You can use a BLOB field to store an arbitrary binaryobjects (in Java as an array of bytes) and a MESSAGE field to store a PDMMessage object, which enables "nesting"PDMMessages inside other PDMMessages. Creating and using a variable length string field is nearly identical to theprevious fixed string example.

...private PDMFieldInfo fldInfo105;...public void setupPDM() { ... fldInfo105 = defn.addFieldInfo(105, PDMFieldType.STRING, true); ...}

public void sourceUsePDM() { ... String fld105Val = "variable length value"; ... msg.setFieldValue(fldInfo105, fld105Val);...}

...private PDMFieldInfo fldInfo105;...public void setupPDM() { ... fldInfo105 = defn.addFieldInfo(105, PDMFieldType.STRING, true); ...}public void receiverUsePDM(byte[] buffer) { ... String fld105Val; ... fld105Val = msg.getFieldValueAsString(fldInfo105);}

Retrieve the BLOB field values with the getFieldValueAsBlob function, and the MESSAGE field values with thegetFieldValueAsMessage function.

Array Field TypesFor each of the scalar field types (fixed and variable length), a corresponding array field type uses the convention*_ARR for the type name (ex: BOOLEAN_ARR, INT32_ARR, STRING_ARR, etc). This lets you set and get Javavalues such as an int[] or string[] directly into a single field. In addition, all of the array field types can specify a fixednumber of elements for the size of the array when they are defined, or if not specified, behave as variable size arrays.Do this by passing an extra parameter to the addFieldInfo function of the definition.

To be treated as a fixed-required field, an array type field must be required as well as be specified as a fixed size arrayof fixed length elements. For instance, a required BOOLEAN_ARR field defined with a size of 3 would be treated as afixed-required field. Also, a required FIX_STRING_ARR field defined with a size of 5 and fixed string length of 7 would

Pre-Defined Messaging 65

be treated as a fixed-required field. However, neither a STRING_ARR field nor a BLOB_ARR field are treated as afixed length field even if the size of the array is specified, since each element of the array can be variable in length. Inthe example below, field 106 and field 108 are both treated as fixed-required fields, but field 107 is not because it is avariable size array field type.

...private PDMFieldInfo fldInfo106;private PDMFieldInfo fldInfo107;private PDMFieldInfo fldInfo108;...public void setupPDM() { ... //Create information for a boolean, int32, and float field (all required) // as well as an optional int8 field ... //A required, fixed size array of 3 boolean elements fldInfo106 = defn.addFieldInfo(106, PDMFieldType.BOOLEAN_ARR, true, 3); //An optional, variable size array of int32 elements fldInfo107 = defn.addFieldInfo(107, PDMFieldType.INT32_ARR, false); //A required, fixed size array of 2 element which are each 5 character strings fldInfo108 = defn.addFieldInfo(108, PDMFieldType.FIX_STRING_ARR, 5, true, 2); ...}

public void sourceUsePDM() {... //Example values for the message ... boolean fld106Val[] = {true, false, true}; int fld107Val[] = {1, 2, 3, 4, 5}; String fld108Val[] = {"aaaaa", "bbbbb"}; //Set each field value in the message ... msg.setFieldValue(fldInfo106, fld106Val); msg.setFieldValue(fldInfo107, fld107Val); msg.setFieldValue(fldInfo108, fld108Val); ...}

...private PDMFieldInfo fldInfo106;private PDMFieldInfo fldInfo107;private PDMFieldInfo fldInfo108;...public void setupPDM() { ... //Create information for a boolean, int32, and float field (all required) // as well as an optional int8 field ... //A required, fixed size array of 3 boolean elements fldInfo106 = defn.addFieldInfo(106, PDMFieldType.BOOLEAN_ARR, true, 3); //An optional, variable size array of int32 elements fldInfo107 = defn.addFieldInfo(107, PDMFieldType.INT32_ARR, false); //A required, fixed size array of 2 element which are each 5 character strings fldInfo108 = defn.addFieldInfo(108, PDMFieldType.FIX_STRING_ARR, 5, true, 2); ...}

public void receiverUsePDM(byte[] buffer) { ... //Values to be retrieved from the message ... boolean fld106Val[]; int fld107Val[]; String fld108Val[]; //Deserialize the bytes into a message msg.parse(buffer);

66 Chapter 5: UMS Features

//Get each field value from the message ... fld106Val = msg.getFieldValueAsBooleanArray(fldInfo106); if(msg.isFieldValueSet(fldInfo107)) { fld107Val = msg.getFieldValueAsInt32Array(fldInfo107); } fld108Val = msg.getFieldValueAsStringArray(fldInfo108); }

Definition Included In MessageOptionally, a PDM message can also include the definition when it is serialized to bytes. This enables receivers toparse a PDM message without having pre-defined knowledge of the message, although including the definition withthe message affects message size and performance of message deserialization. Notice that thesetIncludeDefinition function is called with an argument of true for a source that serializes the definition as part of themessage.

private PDMDefinition defn;private PDMMessage msg;

public void setupPDM() { //Create the definition with 3 fields and using int field names defn = new PDMDefinition(3, true); ...

//Finalize the definition and create the message defn.finalizeDef(); msg = new PDMMessage(defn);

//Set the flag to indicate that the definition should also be serialized msg.setIncludeDefinition(true);}

...

For a receiver, the setupPDM function does not need to set any flags for the message but rather should define amessage without a definition, since we assume the source provides the definition. If a definition is set for a message, itwill attempt to use that definition instead of the definition on the incoming message (unless the ids are different).

private PDMDefinition defn;private PDMMessage msg;

public void setupPDM() { //Don.t define a definition

//Create a message without a definition since the incoming message will have it

msg = new PDMMessage();}

...

The PDM Field IteratorYou can use the PDM Field Iterator to check all defined message fields to see if set, or to extract their values. You canextract a field value as an Object using this method, but due to the casting involved, we recommend you use the typespecific get method to extract the exact value. Notice the use of field.isValueSet to check to see if the field value is setand the type specific get methods such as getBooleanValue and getFloatValue.

...

Pre-Defined Messaging 67

public void setupPDM() { //Create the definition with 3 fields and using int field names defn = new PDMDefinition(3, true); //Set the definition id and version defn.setId(1001); defn.setMsgVersMajor((byte)1); defn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float field (all required) // as well as an optional int8 field fldInfo100 = defn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); fldInfo101 = defn.addFieldInfo(101, PDMFieldType.INT32, true); fldInfo102 = defn.addFieldInfo(102, PDMFieldType.FLOAT, true); fldInfo103 = defn.addFieldInfo(103, PDMFieldType.INT8, false); fldInfo104 = defn.addFieldInfo(104, PDMFieldType.FIX_STRING, 12, true); fldInfo105 = defn.addFieldInfo(105, PDMFieldType.STRING, true); //A required, fixed size array of 3 boolean elements fldInfo106 = defn.addFieldInfo(106, PDMFieldType.BOOLEAN_ARR, true, 3); //An optional, variable size array of int32 elements fldInfo107 = defn.addFieldInfo(107, PDMFieldType.INT32_ARR, false); //A required, fixed size array of 2 element which are each 5 character strings fldInfo108 = defn.addFieldInfo(108, PDMFieldType.FIX_STRING_ARR, 5, true, 2); //Finalize the definition and create the message defn.finalizeDef(); msg = new PDMMessage(defn);}

public void receiveAndIterateMessage(byte[] buffer) { msg.parse(buffer); PDMFieldIterator iterator = msg.createFieldIterator(); PDMField field = null; while(iterator.hasNext()) { field = iterator.next(); System.out.println("Field set? " +field.isValueSet()); switch(field.getIntName()) { case 100: boolean val100 = field.getBooleanValue(); System.out.println( "Field 100's value is: " + val100); break; case 101: int val101 = field.getInt32Value(); System.out.println( "Field 101's value is: " + val101); break; case 102: float val102 = field.getFloatValue(); System.out.println( "Field 102's value is: " + val102); break; default: //Casting to object is possible but not recommended Object value = field.getValue(); int name = field.getIntName(); System.out.println( "Field " + name + "'s value is: " + value); } }}

Sample Output (106, 107, 108 are array objects as expected):

Field set? trueField 100's value is: trueField set? trueField 101's value is: 7Field set? trueField 102's value is: 3.14Field set? falseField 103's value is: nullField set? true

68 Chapter 5: UMS Features

Field 104's value is: Hello World!Field set? trueField 105's value is: VariableField set? trueField 106's value is: [Z@527736bdField set? trueField 107's value is: [I@10aadc97Field set? trueField 108's value is: [Ljava.lang.String;@4178460d

Using the Definition CacheThe PDM Definition Cache assists with storing and looking up definitions by their id and version. In some scenarios, itmay not be desirable to maintain the references to the message and the definition from a setup phase by theapplication. A source could optionally create the definition during the setup phase and store it in the definition cache.At a later point in time, it could retrieve the definition from the cache and use it to create the message without needingto maintain any references to the objects.

public void createAndStoreDefinition() { PDMDefinition myDefn = new PDMDefinition(3, true); //Set the definition id and version myDefn.setId(2001); myDefn.setMsgVersMajor((byte)1); myDefn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float field (all required) myDefn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); myDefn.addFieldInfo(101, PDMFieldType.INT32, true); myDefn.addFieldInfo(102, PDMFieldType.FLOAT, true);

myDefn.finalizeDef(); PDMDefinitionCache.getInstance().put(myDefn);}

public void createMessageUsingCache() { PDMDefinition myFoundDefn = PDMDefinitionCache.getInstance().get(2001, 1, 0); if(myFoundDefn != null) { PDMMessage myMsg = new PDMMessage(myFoundDefn); //Get FieldInfo from defn and then set field values in myMsg //... }}

A more advanced use of the PDM Definition Cache is by a receiver which may need to receive messages with differentdefinitions and the definitions are not being included with the messages. The receiver can create the definitions inadvance and then set a flag that allows automatic lookup into the definition cache when parsing a message (which isnot on by default). Before receiving messages, the receiver should do something similar tocreateAndStoreDefinition (shown below) to set up definitions and put them in the definition cache. Then the flag toallow automatic lookup should be set as shown below in the call to setTryToLoadDefFromCache(true). This allowsthe PDMMessage to be created without a definition and still successfully parse a message by leveraging the definitioncache.

public void createAndStoreDefinition() { PDMDefinition myDefn = new PDMDefinition(3, true); //Set the definition id and version myDefn.setId(2001); myDefn.setMsgVersMajor((byte)1); myDefn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float field (all required) myDefn.addFieldInfo(100, PDMFieldType.BOOLEAN, true); myDefn.addFieldInfo(101, PDMFieldType.INT32, true); myDefn.addFieldInfo(102, PDMFieldType.FLOAT, true); myDefn.finalizeDef();

Pre-Defined Messaging 69

PDMDefinitionCache.getInstance().put(myDefn); //Create and store other definitions //...}

public void receiveKnownMessages(byte[] buffer) { PDMMessage myMsg = new PDMMessage(); //Set the flag that enables messages to try // looking up the definition in the cache automatically // when parsing a byte buffer myMsg.setTryToLoadDefFromCache(true); myMsg.parse(buffer); if(myMsg.getDefinition().getId() == 2001 && myMsg.getDefinition().getMsgVersMajor() == 1 && myMsg.getDefinition().getMsgVersMinor() == 0) { PDMDefinition myDefn = PDMDefinitionCache.getInstance().get(2001, 1, 0); PDMFieldInfo fldInfo100 = myDefn.getFieldInfo(100); PDMFieldInfo fldInfo101 = myDefn.getFieldInfo(101); PDMFieldInfo fldInfo102 = myDefn.getFieldInfo(102); boolean fld100Val; int fld101Val; float fld102Val; //Get each field value from the message fld100Val = myMsg.getFieldValueAsBoolean(fldInfo100); fld101Val = myMsg.getFieldValueAsInt32(fldInfo101); fld102Val = myMsg.getFieldValueAsFloat(fldInfo102); System.out.println(fld100Val + " " + fld101Val + " " + fld102Val); }}

Migrating from SDMApplications using SDM with a known set of message fields are good candidates for migrating from SDM to PDM. WithSDM, the source typically adds fields to an SDM message without a definition. But, as shown above in the PDMexamples, creating/adding a PDM definition before adding field values is fairly straightforward.

However, certain applications may be incapable of building a definition in advance due to the ad-hoc nature of theirmessaging needs, in which case a self-describing format like SDM may be preferred.

Simple Migration ExampleThe following source code shows a basic application that serializes and deserializes three fields using SDM and PDM.The setup method in both cases initializes the object instances so they can be reused by the source and receivermethods.

The goal of the sourceCreateMessageWith functions is to produce a byte array by setting field values in a messageobject. With SDM, actual Field classes are created, values are set, the Field classes are added to a Fields class, andthen the Fields class is added to the SDMessage. With PDM, FieldInfo objects are created during the setup phaseand then used to set specific values in the PDMMessage.

The goal of the receiverParseMessageWith functions is to produce a message object by parsing the byte array andthen extract the field values from the message. With SDM, the specific field is located and casted to the correct fieldclass before getting the field value. With PDM, the appropriate getFieldValueAs function is called with thecorresponding FieldInfo object created during the setup phase to extract the field value.

public class Migration { //SDM Variables

70 Chapter 5: UMS Features

private LBMSDMessage srcSDMMsg; private LBMSDMessage rcvSDMMsg; //PDM Variables private PDMDefinition defn; private PDMFieldInfo fldInfo100; private PDMFieldInfo fldInfo101; private PDMFieldInfo fldInfo102; private PDMMessage srcPDMMsg; private PDMMessage rcvPDMMsg;

public static void main(String[] args) { Migration app = new Migration(); System.out.println("Setting up PDM Definition and Message"); app.setupPDM(); System.out.println("Setting up SDM Messages"); app.setupSDM(); byte[] sdmBuffer; sdmBuffer = app.sourceCreateMessageWithSDM(); app.receiverParseMessageWithSDM(sdmBuffer); byte[] pdmBuffer; pdmBuffer = app.sourceCreateMessageWithPDM(); app.receiverParseMessageWithPDM(pdmBuffer); }

public void setupSDM() { rcvSDMMsg = new LBMSDMessage(); srcSDMMsg = new LBMSDMessage(); } public void setupPDM() { //Create the definition with 3 fields and using int field names defn = new PDMDefinition(3, false); //Set the definition id and version defn.setId(1001); defn.setMsgVersMajor((byte)1); defn.setMsgVersMinor((byte)0); //Create information for a boolean, int32, and float field (all required) // as well as an optional int8 field fldInfo100 = defn.addFieldInfo("Field100", PDMFieldType.INT8, true); fldInfo101 = defn.addFieldInfo("Field101", PDMFieldType.INT16, true); fldInfo102 = defn.addFieldInfo("Field102", PDMFieldType.INT32, true); //Finalize the definition and create the message defn.finalizeDef(); srcPDMMsg = new PDMMessage(defn); rcvPDMMsg = new PDMMessage(defn); } public byte[] sourceCreateMessageWithSDM() { byte[] buffer = null; LBMSDMField fld100 = new LBMSDMFieldInt8("Field100", (byte)0x42); LBMSDMField fld101 = new LBMSDMFieldInt16("Field101", (short)0x1ead); LBMSDMField fld102 = new LBMSDMFieldInt32("Field102", 12345); LBMSDMFields fset = new LBMSDMFields();

try { fset.add(fld100); fset.add(fld101); fset.add(fld102); } catch (LBMSDMException e) { System.out.println ( e ); } srcSDMMsg.set(fset); try { buffer = srcSDMMsg.data(); } catch (IndexOutOfBoundsException e) {

Pre-Defined Messaging 71

System.out.println ( "SDM Exception occurred during build of message:" ); System.out.println ( e.toString() ); } catch (LBMSDMException e) { System.out.println ( e.toString() ); } return buffer; } public byte[] sourceCreateMessageWithPDM() { //Set each field value in the message srcPDMMsg.setFieldValue(fldInfo100, (byte)0x42); srcPDMMsg.setFieldValue(fldInfo101, (short)0x1ead); srcPDMMsg.setFieldValue(fldInfo102, 12345); //Serialize the message to bytes byte[] buffer = srcPDMMsg.toBytes(); return buffer; } public void receiverParseMessageWithSDM(byte[] buffer) { //Values to be retrieved from the message byte fld100Val; short fld101Val; int fld102Val; //Deserialize the bytes into a message try { rcvSDMMsg.parse(buffer); } catch (LBMSDMException e) { System.out.println(e.toString()); } LBMSDMField fld100 = rcvSDMMsg.locate("Field100"); LBMSDMField fld101 = rcvSDMMsg.locate("Field101"); LBMSDMField fld102 = rcvSDMMsg.locate("Field102"); //Get each field value from the message fld100Val = ((LBMSDMFieldInt8)fld100).get(); fld101Val = ((LBMSDMFieldInt16)fld101).get();; fld102Val = ((LBMSDMFieldInt32)fld102).get();; System.out.println("SDM Results: Field100=" + fld100Val + ", Field101=" + fld101Val + ", Field102=" + fld102Val); } public void receiverParseMessageWithPDM(byte[] buffer) { //Values to be retrieved from the message byte fld100Val; short fld101Val; int fld102Val; //Deserialize the bytes into a message rcvPDMMsg.parse(buffer); //Get each field value from the message fld100Val = rcvPDMMsg.getFieldValueAsInt8(fldInfo100); fld101Val = rcvPDMMsg.getFieldValueAsInt16(fldInfo101); fld102Val = rcvPDMMsg.getFieldValueAsInt32(fldInfo102); System.out.println("PDM Results: Field100=" + fld100Val + ", Field101=" + fld101Val + ", Field102=" + fld102Val); } }

Notice that with sourceCreateMessageWithSDM function, the three fields (name and value) are created and addedto the fset variable, which is then added to the SDM message. On the other hand, the

72 Chapter 5: UMS Features

sourceCreateMessageWithPDM function uses the FieldInfo object references to add the field values to themessage for each of the three fields.

Also notice that the receiverParseMessageWithSDM requires a cast to the specific field class (likeLBMSDMFieldInt8) once the field has been located. After the cast, calling the get method returns the expected value.On the other hand the receiverParseMessageWithPDM uses the FieldInfo object reference to directly retrieve thefield value using the appropriate getFieldValueAs* method.

SDM Raw ClassesSeveral SDM classes with Raw in their name could be used as the value when creating an LBMSDMField. Forexample, an LBMSDMRawBlob instance could be created from a byte array and then that the LBMSDMRawBlobcould be used as the value to a LBMSDMFieldBlob as shown in the following example.

byte[] blob = new byte[25]; LBMSDMRawBlob rawSDMBlob = new LBMSDMRawBlob(blob); try { LBMSDMField fld103 = new LBMSDMFieldBlob("Field103",rawSDMBlob); } catch (LBMSDMException e1) { System.out.println(e1); }

The actual field named "Field103" is created in the try block using the rawSDMBlob variable which has been createdto wrap the blob byte array. This field can be added to a LBMSDMFields object, which then uses it in aLBMSDMessage.

In PDM, there are no "Raw" classes that can be created. When setting the value for a field for a message, theappropriate variable type should be passed in as the value. For example, setting the field value for a BLOB field wouldmean simply passing the byte array directly in the setValue method as shown in the following code snippet since thefield is defined as type BLOB.

private PDMFieldInfo fldInfo103;

public void setupPDM() { ... fldInfo103 = defn.addFieldInfo("Field103", PDMFieldType.BLOB, true); ... }... byte[] blob = new byte[25]; srcPDMMsg.setFieldValue(fldInfo103, blob);

The PDM types of DECIMAL, TIMESTAMP, and MESSAGE expect a corresponding instance of PDMDecimal,PDMTimestamp, and PDMMessage as the field value when being set in the message so those types do require aninstantiation instead of using a native Java type. For example, if "Field103" had been of typePDMFieldType.DECIMAL, the following code would be used to set the value.

PDMDecimal decimal = new PDMDecimal((long)2, (byte)32);srcPDMMsg.setFieldValue(fldInfo103, decimal);

Multicast Immediate MessagingAs an alternative to the normal, source-based UM messaging model, Multicast Immediate Messaging (MIM) offersadvantages to short-lived topics and applications that cannot tolerate a delay between source creation and the

Multicast Immediate Messaging 73

sending of the first message. See the UM Knowledgebase article, Delay Before Sending for background on this delayand other head-loss mitigation techniques.

Multicast Immediate Messaging avoids delay by eliminating the topic resolution process. MIM accomplishes this by:

1. Configuring transport information into sending and receiving applications.

2. Including topic strings within each message.

MIM is well-suited to applications where a small number of messages are sent to a topic. By eliminating topicresolution, MIM also reduces one of the causes of head-loss, defined as the loss of initial messages sent over a newtransport session. Messages sent before topic resolution is complete will be lost.

MIM is typically not used for normal streaming data because messages are somewhat less efficiently handled thansource-based messages. Inefficiencies derive from larger message sizes due to the inclusion of the topic name, andon the receiving side, the MIM delivery controller hashing of topic names to find receivers, which consumes someextra CPU. If you have a high-message-rate stream, you should use a source-based method and not MIM. If head-lossis a concern and delay before sending is not feasible, then consider using late join (although this replaces head-losswith some head latency).

Note: Multicast Immediate Messaging can use Datagram Bypass Layer (DBL) acceleration in conjunction with DBL-enabled Myricom 10-Gigabit Ethernet NICs for Linux and Microsoft Windows. DBL is a kernel-bypass technology thataccelerates sending and receiving UDP traffic. See Transport Acceleration Options for more information.

This section discusses the following topics.

¨ “Temporary Transport Session” on page 74

¨ “Receiving Immediate Messages” on page 75

¨ “MIM Configuration” on page 75

¨ “MIM Example Applications” on page 75

Temporary Transport SessionMIM uses the same reliable multicast algorithms as LBT-RM. When a sending application sends a message withlbm_multicast_immediate_message(), MIM creates a temporary transport session. Note that no topic-level sourceobject is created.

MIM automatically deletes the temporary transport session after a period of inactivity defined bymim_src_deletion_timeout which defaults to 30 seconds. A subsequent send creates a new transport session. Due tothe possibility of head-loss in the switch, it is recommended that sending applications use a long deletion timeout ifthey continue to use MIM after significant periods of inactivity.

MIM forces all topics across all sending applications to be concentrated onto a single multicast address to which ALLapplications listen, even if they aren't interested in any of the topics. Thus, all topic filtering must happen in UM.

MIM can also be used to send an UM request message with lbm_multicast_immediate_request(). For example, anapplication can use MIM to request initialization information right when it starts up. MIM sends the response directly tothe initializing application, avoiding the topic resolution delay inherent in the normal source-basedlbm_send_request() function.

MIM NotificationsMIM notifications differ in the following ways from normal UM source-based sending.

¨ When a sending application's MIM transport session times out and is deleted, the receiving applications do notreceive an EOS notification.

¨ Applications with a source notification callback are not informed of a MIM sender. Since source notification isbasically a hook into the topic resolution system, this should not come as a surprise.

74 Chapter 5: UMS Features

¨ MIM sending supports the non-blocking flag. However, it does not provide an LBM_SRC_EVENT_WAKEUPnotification when the MIM session becomes writable again.

¨ MIM sends unrecoverable loss notifications to a context callback, not to a receiver callback. See “LossHandling” on page 75.

Receiving Immediate MessagesMIM does not require any special type of receiver. It uses the topic-based publish/subscribe model so an applicationmust still create a receiver for a topic to receive MIM messages.

Note: If needed, an application can send topic-less messages using MIM. A MIM sender passes in a NULL stringinstead of a topic name. The message goes out on the MIM multicast address and is received by all other receivers. Areceiving application can use lbm_context_rcv_immediate_msgs() to set the callback procedure and deliverymethod for non-topic immediate messages.

Wildcard ReceiversWhen an application receives an immediate message, it's topic is hashed to see if there is at least one regular (non-wildcard) receiver object listening to the topic. If so, then MIM delivers the message data to the list of receivers.

However, if there are no regular receivers for that topic in the receive hash, MIM runs the message topic through allexisting wildcard patterns and delivers matches to the appropriate wildcard receiver objects without creating sub-receivers. The next MIM message received for the same topic will again be run through all existing wildcard patterns.This can consume significant CPU resources since it is done on a per-message basis.

Loss HandlingThe receiving application can set up a context callback to be notified of MIM unrecoverable loss(lbm_mim_unrecloss_function_cb). It is not possible to do this notification on a topic basis because the receiving UMhas no way of knowing which topics were affected by the loss.

Note: The UM API's statistics functions and the UM Monitoring API do not provide access to MIM transport sessionstatistics.

MIM ConfigurationAs of UM 3.1, MIM supports ordered delivery. As of UM 3.3.2, the MIM configuration option, mim_ordered_deliverydefaults to ordered delivery. A byproduct of MIM ordered delivery is cross-topic ordering, which normal source-basedUM senders cannot guarantee.

See the UM Configuration Guide for the descriptions of the MIM configuration options.

¨ Multicast Immediate Messaging Network Options

¨ Multicast Immediate Messaging Reliability Options

¨ Multicast Immediate Messaging Operation Options

Note: Setting mim_incoming_address to 0.0.0.0 turns off MIM.

MIM Example ApplicationsUM includes two example applications that illustrate MIM.

¨ lbmimsg.c - application that sends immediate messages as fast as it can to a given topic (single source). See alsothe Java example, lbmimsg.java and the .NET example, lbmimsg.cs.

Multicast Immediate Messaging 75

¨ lbmireq.c - application that sends immediate requests to a given topic (single source) and waits for responses.

lbmimsg.cWe can demonstrate the default operation of Immediate Messaging with lbmimsg and lbmrcv.

1. Run lbmrcv -v topicName2. Run lbmimsg topicNameThe lbmrcv output should resemble the following.

Immediate messaging target: TCP:10.29.1.78:143911 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][0], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][1], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][2], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][3], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][4], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][5], 25 bytes[topicName][LBTRM:10.29.1.78:14390:644c8862:224.10.10.21:14401][6], 25 bytes

Each line in the lbmrcv output is a message received, showing the topic name, transport type, receiver IP:Port,multicast address and message number.

lbmireq.cSending an UM request by MIM can be demonstrated with lbmireq and lbmrcv, which shows a single request beingsent by lbmireq and received by lbmrcv. (lbmrcv sends no response.)

1. Run lbmrcv -v topicName2. Run lbmireq topicNamelbmrcv

The lbmrcv output should resemble the following.

$ lbmrcv -v topicNameImmediate messaging target: TCP:10.29.1.78:143911 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps[topicName][LBTRM:10.29.1.78:14390:92100885:224.10.10.21:14401][0], Request1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps1 secs. 0 Kmsgs/sec. 0 Kbps

lbmireq

The lbmireq output should resemble the following.

$ lbmireq topicNameUsing TCP port 4392 for responsesSending 1 requests of size 25 bytes to target <> topic <topicName>Sending request 0Sent request 0. Pausing 5 seconds.Done waiting for responses. 0 responses (0 bytes) received. Deleting requestQuitting...Lingering for 5 seconds...

76 Chapter 5: UMS Features

SpectrumUM Spectrum, which refers to a "spectrum of channels", allows a source application to allocate any number ofchannels using lbm_src_channel_create() on which to send (lbm_src_send_ex()) different messages of the sametopic. A receiving application can subscribe receivers to one or more channels with either lbm_rcv_subscribe_channelor lbm_wrcv_subscribe_channel. Since each channel requires a different receiver callback, the receiver application canachieve more granular filtering of messages. Moreover, messages are received in-order across channels since allmessages are part of the same topic stream.

You can accomplish the same level of filtering with a topic space design that creates separate topics for each channel,however, UM cannot guarantee the delivery of messages from multiple sources/topics in any particular order. Not onlycan UM Spectrum deliver the messages over many channels in the order they were sent by the source, but it alsoreduces topic resolution traffic since UM advertises only topics, not channels.

See also the C API documentation.

Performance PlusesThe use of separate callbacks for different channels improves filtering and also relieves the source application of thetask of including filtering information in the message data.

Java and .NET performance also receives a boost because messages not of interest can be discarded before theytransition to the Java or .NET level.

Configuration OptionsSpectrum's default behavior delivers messages on any channels the receiver has subscribed to on the callbacksspecified when subscribing, and all other messages on the receiver's default callback. This behavior can be changedwith the following configuration options.

¨ null_channel_behavior - behavior for messages delivered with no channel information.

¨ unrecognized_channel_behavior - behavior for messages delivered with channel information but are on a channelfor which the receiver has not registered interest.

¨ channel_map_tablesz - controls the size of the table used by a receiver to store channel subscriptions.

Hot FailoverUM Hot Failover (HF) lets you implement sender redundancy in your applications. You can create multiple HF sendersin different UM contexts, or, for even greater resiliency, on separate machines. There is no hard limit to the number ofHF sources, and different HF sources can use different transport types.

Hot Failover receivers filter out the duplicate messages and deliver one message to your application. Thus, sourcescan drop a few messages or even fail completely without causing message loss, as long as the HF receiver receiveseach message from at least one source.

Spectrum 77

The following diagram displays Hot Failover operation.

In the figure above, HF sources send copies of Message X. An HF receiver delivers the first copy of Message X itreceives to the application, and discards subsequent copies coming from the other sources.

Implementing Hot Failover SourcesYou create Hot Failover sources with lbm_hf_src_create(). This returns a source object with internal state informationthat lets it send HF messages. You delete HF sources with the lbm_src_delete() function.

HF sources send HF messages via lbm_hf_src_send_ex() or lbm_hf_src_sendv_ex(). These functions take a sequencenumber, supplied via the exinfo object, that HF receivers use to identify the same message sent from different HFsources. The exinfo has an hf_sequence_number, with a flag (LBM_SRC_SEND_EX_FLAG_HF_32 orLBM_SRC_SEND_EX_FLAG_HF_64) that identifies whether it's a 32- or 64-bit number. Each HF source sends the samemessage content for a given sequence number, which must be coordinated by your application.

If the source needs to restart its sequence number to an earlier value (e.g. start of day; not needed for normalwraparound), delete and re-create the source and receiver objects. Without re-creating the objects, the receiver seesthe smaller sequence number, assumes the data is duplicate, and discards it. In (and only in) cases where this cannotbe done, use lbm_hf_src_send_rcv_reset().

Note: Your application must synchronize calling lbm_hf_src_send_ex() or lbm_hf_src_sendv_ex() with all threadssending on the same source. (One symptom of not doing so is messages appearing at the receiver as insideintentional gaps and being erroneously discarded.)

Please be aware that non-HF receivers created for an HF topic receive multiple copies of each message. Werecommend you establish local conventions regarding the use of HF sources, such as including "HF" in the topicname.

For an example source application, see lbmhfsrc in the UM Examples Page.

78 Chapter 5: UMS Features

Implementing Hot Failover ReceiversYou create HF receivers with lbm_hf_rcv_create(), and delete them using lbm_hf_rcv_delete() andlbm_hf_rcv_delete_ex().

Incoming messages have an hf_sequence_number field containing the sequence number, and a message flag(LBM_MSG_FLAG_HF_32 or LBM_MSG_FLAG_HF_64) noting the bit size.

Note: Previous UM versions used sequence_number for HF message identification. This field holds a 32-bit value andis still set for backwards compatibility, but if the HF sequence numbers are 64-bit lengths, this non-HF sequencenumber is set to 0. Also, you can retrieve the original (non-HF) topic sequence number vialbm_msg_retrieve_original_sequence_number() or, in Java and .NET, via LBMMessage.osqn().

For the maximum time period to recover lost messages, the HF receiver uses the minimum of the LBT-RM and LBT-RU NAK generation intervals (transport_lbtrm_nak_generation_interval,transport_lbtru_nak_generation_interval). Each transport protocol is configured as normal, but the lost messagerecovery timer is the minimum of the two settings.

Some lbm_msg_t objects coming from HF receivers may be flagged as having "passed through" the HF receiver. Thismeans that the message has not been ordered with other HF messages. These messages have theLBM_MSG_FLAG_HF_PASS_THROUGH flag set. UM flags messages sent from HF sources using lbm_src_send() in thismanner, as do all non-HF sources. Also, UM flags EOS, no source notification, and requests in this manner as well.

For an example receiver application, see lbmhfrcv in the UM Examples Page.

Implementing Hot Failover Wildcard ReceiversTo create an HF wildcard receiver, set option hf_receiver to 1, then create a wildcard receiver withlbm_wildcard_rcv_create(). This actually creates individual HF receivers on a per-topic basis, so that each topic canhave its own set of HF sequence numbers. Once the HF wildcard receiver detects that all sources for a particular topicare gone it closes the individual topic HF receivers and discards the HF sequence information (unlike a standard HFreceiver). You can extend or control the delete timeout period of individual HF receivers with optionresolver_no_source_linger_timeout.

Java and .NETFor information on implement the HF feature in a Java application, go to UM Java API and see the documentation forclasses LBMHotFailoverReceiver and LBMHotFailoverSource.

For information on implement the HF feature in a .NET application, go to UM .NET API and navigate to Namespaces ->com.latencybusters.lbm -> LBMHotFailoverReceiver and LBMHotFailoverSource.

Using Hot Failover with UMPWhen implementing Hot Failover with UMP, you must consider the following impact on hardware resources:

¨ Additional storage space required for a UMP disk store

¨ Higher disk activity

¨ Higher network activity

¨ Increased application complexity regarding message filtering

Also note that you must enable UME explicit ACKs and Hot Failover duplicate delivery in each Hot Failover receivingapplication.

For detailed information on using Hot Failover with UMP, see the Knowledge Base article UMP Hot Failover.

Hot Failover 79

Hot Failover Intentional Gap SupportUM supports intentional gaps in HF message streams. Your HF sources can supply message sequence numbers withnumber gaps up to 1073741824. HF receivers automatically detect the gaps and consider any missing messagesequence numbers as not sent and do not attempt recovery for these missing sequence numbers. See the followingexample.

HF source 1 sends message sequence numbers: 10, 11, 12, 13, 25, 26, 38HF source 2 sends message sequence numbers: 10, 11, 12, 13, 25, 26, 38

HF receiver 1 receives message sequence numbers in order with no pause between any messages: 10, 11, 12, 13, 25, 26, 38

Hot Failover Optional MessagesHot Failover sources can send optional messages that HF receivers can be configured to receive or not receive( hf_optional_messages). HF receivers detect an optional message by checking lbm_msg_t.flags forLBM_MSG_FLAG_HF_OPTIONAL. HF sources indicate an optional message by passingLBM_SRC_SEND_EX_FLAG_HF_OPTIONAL in the lbm_src_send_ex_info_t.flags field tolbm_hf_src_send_ex() or lbm_hf_src_sendv_ex(). In the examples below, optional messages appear with an "o"after the sequence number.

HF source 1 sends message sequence numbers: 10, 11, 12, 13o, 14o, 15, 16o, 17o, 18o, 19o, 20HF source 2 sends message sequence numbers: 10, 11, 12, 13o, 14o, 15, 16o, 17o, 18o, 19o, 20

HF receiver 1 receives: 10, 11, 12, 13o, 14o, 15, 16o, 17o, 18o, 19o, 20HF receiver 2, configured to ignore optional messages, receives: 10, 11, 12, 15, 20

Using Hot Failover with Ordered DeliveryAn HF receiver takes some of its operating parameters directly from the receive topic attributes. The ordered_deliverysetting indicates the ordering for the HF receiver. Please see “Ordered Delivery” on page 47 Ordered Delivery forinformation on the different modes of delivery order.

Note: UM supports Arrival Order with HF only when all sources use the same transport type.

Hot Failover Across Multiple ContextsIf you have a receiving application on a multi-homed machine receiving HF messages from HF sources, you can set upthe Hot Failover Across Contexts (HFX) feature. This involves setting up a separate UM context to receive HFmessages over each NIC and then creating an HFX Object, which drops duplicate HF messages arriving over allcontexts. Your receiving application then receives only one copy of each HF message. The HFX feature achieves thesame effect across multiple contexts as the normal Hot Failover feature does within a single context.

80 Chapter 5: UMS Features

The following diagram displays Hot Failover operation across UM contexts.

For each context that receives HF messages, create one HFX Receiver per topic. Each HFX Receiver can beconfigured independently by passing in a UM Receiver attributes object during creation. A unique client data pointercan also be associated with each HFX Receiver. The HFX Object is a special Ultra Messaging object and does not livein any UM context.

Note: You never have to call lbm_topic_lookup() for a HFX Receiver. If you are creating HFX Receivers along withnormal UM receivers for the same topic, do not interleave the calls. For example, call lbm_hfx_create() andlbm_hfx_rcv_create() for the topic. Then call lbm_topic_lookup() and lbm_rcv_create() for the topic to create thenormal UM receivers.

The following outlines the general procedure for HFX.

1. Create an HFX Object for every HF topic of interest with lbm_hfx_create(), passing in an attributes objectcreated with lbm_hfx_attr_create() to specify any attributes desired.

2. Create a context for the first NIC receiving HF messages with lbm_context_create().

3. Create a HFX Receiver for every HF topic with lbm_hfx_rcv_create(), passing in UM Receive TopicAttributes.

4. Repeat steps 2 and 3 for all NICs receiving HF message

5. Receive messages. The HFX Object identifies and drops all duplicates, delivering messages through a singlecallback (and optional event queue) specified when you created the HFX Object.

Delete each HFX Receiver with lbm_hfx_rcv_delete() or lbm_hfx_rcv_delete_ex(). Delete the HFX Object withlbm_hfx_delete().

Note: When writing source-side HF applications for HFX, be aware that HFX receivers do not support hf_sequence,64-bit sequence numbers, the lbm_hf_src_send_rcv_reset() function, or HF wildcard receivers.

See also ...

¨ Hot Failover Operation Options for HFX Configuration Options.

¨ LBMHFX*.java in UM Java API.

Hot Failover 81

¨ LBMHFX*.cs in UM .NET API.

82 Chapter 5: UMS Features

C H A P T E R 6

Monitoring UMSThis chapter includes the following topics:

¨ Introduction, 83

¨ UMS API Functions and Data Structures, 84

¨ UMS Monitoring API, 86

¨ Automatic Monitoring, 93

¨ Monitoring Examples, 93

¨ Interpreting LBT-RM Source Statistics, 97

IntroductionMessaging systems often employ real-time monitoring and rapid human intervention to prevent the system frombecoming unstable. The design of UM encourages stable operation by allowing you to pre-configure how UM will useresources under all traffic and network conditions. Hence manual intervention is not required when those conditionsoccur.

Monitoring UM still fills important roles other than maintaining stable operation. Chiefly among these are capacityplanning and a better understanding of the latency added by UM as it recovers from loss. Collecting accumulatedstatistics from all sources and all receivers once per day is generally adequate for these purposes.

Why Monitor?Monitoring can aid different groups within an organization.

¨ Developers can spot bugs that impact system performance.

¨ Performance tuning groups can pinpoint under-performing receivers.

¨ Testing groups can understand the reaction of a system to stresses like random packet loss during pre-productiontesting.

¨ Network or middleware management groups can use monitoring to ensure a production system continues tooperate within its design criteria.

What to MonitorBefore discussing the monitoring statistics that are built into UM, we mention two things that are probably moreimportant to monitor: connectivity and latency. UM provides some assistance for monitoring these, but the finalresponsibility rests with your applications.

83

ConnectivityIf you monitor only one thing, monitor connectivity, defined as the ability of your system components to talk to eachother when needed Connectivity failures generally indicate a software, hardware, or network failure and generallyrequire prompt attention. UM features like End Of Source (EOS) events, new source notifications, and receiverconnect/disconnect events may help in application connectivity monitoring. See the lbmprice.c example to seetechniques for using these to build an awareness of when components of the system come and go.

Message LatencyIf you monitor only two things, monitor connectivity and the latency of every message. Connectivity monitoring willcatch the hard failures and latency monitoring will catch the soft failures. Many impending hard failures in hardware,software, and networks show up first as rises in average latency or as latency spikes. See our white paper PragmaticAdvice for Handling Market Data Rate Increases for additional comments on the importance of measuring latency.

Monitoring MethodsUM provides the following four methods to monitor your UM activities.

¨ Use UM API function calls within your applications to retrieve statistics and deliver them to your monitoringapplication.

¨ Use the UM Monitoring API to more easily retrieve and send statistics to your monitoring application.

¨ Use Automatic Monitoring to easily employ the UM Monitoring API to monitor UM activity at an UM contextlevel.

¨ Use the Ultra Messaging SNMP Agent and MIB to monitor statistics through a Network Management System. TheUltra Messaging SNMP Agent is purchased separately.

UMS API Functions and Data StructuresThe UM API contains functions that retrieve various statistics for a context, event queue, source or receiver. Thissection lists the functions and constructors you can use to retrieve statistics, along with the data structures UM uses todeliver the statistics. Refer to the UMS API documentation ( UM C API, UM Java API or UM .NET API) for specificinformation about the functions and constructors. Links to the data structures appear in the tables to provide quickaccess to the specific statistics available.

Context StatisticsContext statistics help you monitor topic resolution activity, along with the number of unknown messages received andthe number of sends and responses that were blocked or returned EWOULDBLOCK. Context statistics also containtransport statistics for Multicast Immediate Messaging (MIM) activity and transport statistics for all the sources orreceivers in a context.

C API Function Java or .NET API Constructor Data Structure

lbm_context_retrieve_stats() LBMContextStatistics(LBMContextctx)

lbm_context_stats_t

lbm_context_retrieve_rcv_transport_stats()

LBMReceiverStatistics(LBMContextint maxStats)

lbm_rcv_transport_stats_t

84 Chapter 6: Monitoring UMS

C API Function Java or .NET API Constructor Data Structure

lbm_context_retrieve_src_transport_stats()

LBMSourceStatistics(LBMContextint maxStats)

lbm_src_transport_stats_t

lbm_context_retrieve_mim_rcv_stats()

LBMMIMReceiverStatistics(LBMContext ctx)

lbm_rcv_transport_stats_lbtrm_t

lbm_context_retrieve_mim_src_stats()

LBMMIMSourceStatistics(LBMContextctx)

lbm_src_transport_stats_lbtrm_t

Event Queue StatisticsEvent Queue statistics help you monitor the number of events currently on the queue, how long it takes to service them(maximum, minimum and mean service times) and the total number of events for the monitoring period. Thesestatistics are available for the following types of events.

¨ Data messages

¨ Request messages

¨ Immediate messages

¨ Wildcard receiver messages

¨ I/O events

¨ Timer events

¨ Source events

¨ Unblock events

¨ Cancel events

¨ Callback events

¨ Context source events

¨ Total events

¨ Age of events

When monitoring Event Queue statistics you must enable the Event Queue UM Configuration Options,queue_age_enabled , queue_count_enabled and queue_service_time_enabled . UM disables these options by default,which produces no event queue statistics.

C API Function Java or .NET API Constructor Data Structure

lbm_event_queue_retrieve_stats() LBMEventQueueStatistics(LBMEventQueue evq)

lbm_event_queue_stats_t

Source or Receiver Transport StatisticsYou can retrieve transport statistics for different types of transports (TCP, LBT-RU, LBT-RM, LBT-IPC, LBT-RDMA).In addition, you can limit these transport statistics to a specifc source sending on the particular transport or a specifcreceiver receiving messages over the transport. Source statistics for LBT-RM, for example, include the number ofmessages (datagrams) sent and the number of retransmissions sent. For receiver LBT-RM, statistics include, forexample, the number of messages (datagrams) received and number of UM messages received.

UMS API Functions and Data Structures 85

Note: None of the three types of transport statistics (all, source, or receiver) are topic level statistics. Currently UMdoes not provide topic-specific transport statistics.

C API Function Java or .NET API Constructor Data Structure

lbm_rcv_retrieve_transport_stats()

LBMReceiverStatistics(LBMReceiverlbmrcv source)

lbm_rcv_transport_stats_t

lbm_rcv_retrieve_all_transport_stats()

LBMReceiverStatistics(LBMReceiverlbmrcv int maxStats)

lbm_rcv_transport_stats_t

lbm_src_retrieve_transport_stats()

LBMSourceStatistics(LBMSourcelbmsrc)

lbm_src_transport_stats_t

UMS Monitoring APIThis section discusses the following topics.

¨ “UMS Monitoring Process Flow” on page 87

¨ “API Framework Flexibility” on page 88

¨ “Initial Monitoring Questions” on page 88

¨ “Creating a Monitoring Source” on page 89

¨ “Specifying the Object to Monitor” on page 89

¨ “Receiving Monitoring Data” on page 90

¨ “The UMS Transport Module” on page 92

¨ “The UDP Transport Module” on page 92

¨ “The SNMP Transport Module” on page 93

The UM Monitoring API (see lbmmon.h or the LBMMonitor classes in the Java API and the .NET API) provides aframework to easily gather UMS transport statistics and send them to a monitoring or reporting application. Transportsessions for sources and receivers, along with all transport sessions for a given context can be monitored. This APIcan be implemented in one of two ways.

¨ Build monitoring into your application with the UM Monitoring API functions.

¨ Turn on Automatic Monitoring with UMS configuration options. See “Automatic Monitoring” on page 93.

An application requesting transport monitoring is called a monitor source, and an application accepting statistics is amonitor receiver. These monitoring objects deal only with transport session statistics and should not be confused withUM sources and UM receivers, which deal with UM messages. Statistics for both UM sources and UM receivers canbe forwarded by a monitor source application.

Both a monitor source and monitor receiver comprise three modules:

¨ A format module, responsible for serializing and de-serializing the statistics. The proper transmission betweenmonitor source and monitor receiver requires this serialization.

¨ A transport module that is responsible for sending and receiving statistics data.

¨ A control module, responsible for gathering the statistics, and calling the appropriate functions from the format andtransport modules.

86 Chapter 6: Monitoring UMS

You can substitute format and transport modules of your own choosing or creation. UM Monitoring provides thefollowing sample modules:

¨ LBMMON CSV format module

¨ LBMMON UMS transport module

¨ LBMMON UDP transport module

¨ LBMMON SNMP transport module

To view the source code for all LBMMON transport modules, see LBMMON Example Source Code found on theRelated Pages tab in the C Application Programmer's Interface.

Note: The LBMMON SNMP transport module can be used for non-SNMP based monitoring. The Ultra MessagingSNMP Agent is not required for its use.

UMS Monitoring Process FlowThe overall process flow appears in the diagram below.

Figure 11. UMS Monitoring Process Flow

1. Your application creates the monitor source controller, specifying the format and transport modules to use. It alsocalls lbmmon functions to start monitoring an UM context, UM source or UM receiver.

2. The monitor source controller passes those statistics to the format module serialization function.

UMS Monitoring API 87

3. The monitor source controller passes the resulting serialized data to the transport module send function.

4. The transport module transmits the data over some transport medium (such as a network).

5. The monitor receiver controller transport module receives the serialized data. (Your monitoring application hasalready created the monitor receiver controller specifying the format and transport modules to use, along with theapplication callback functions to use upon the receipt of UM source or UM receiver statistics data.)

6. The monitor receiver controller calls the format module's de-serialization function.

7. Finally, the monitor receiver controller passes the statistics to your monitoring application via the specifiedapplication callback functions.

Your applications only calls functions in the controller modules, which calls the appropriate functions in the transportand format modules.

API Framework FlexibilityThe segregation of UM Monitoring into control, format, and transport modules provides flexibility for monitor receiversin two ways.

¨ Allows you to use languages for which no UM API or binding exists.

¨ Allows you to use monitoring products which do not integrate with UM.

As an example, assume you have a Perl application which currently gathers statistics from other network applications(or, you are simply most comfortable working in Perl for such tasks). There is no Perl binding for UM. However, Perlcan handle UDP packets very nicely, and can pick apart CSV data easily. By implementing a UDP transport module tobe used by the monitor sources, your Perl application can read the UDP packets and process the statistics.

Initial Monitoring QuestionsIf you can answer the following questions, you're already on your way.

1. What format module will you use? LBMMON CSV Format module or a different one.

2. What transport module will you use? One of the 3 LBMMON modules or a different one.

3. Do you want to monitor individual sources/receivers, or an entire context? The difference is in how the statisticsare aggregated.

¨ Monitoring a context aggregates transport statistics for all sources and receivers associated with a context, bytransport. Note that this is not by transport type. The default configuration for TCP, for example, allocates upto 10 ports, forming up to 10 separate transport sessions. Absent any specific instructions, UM allocatessources and receivers to these 10 transports in a round-robin fashion. So the statistics for a specific transporton a context will aggregate all sources and receivers which use that specific transport.

¨ Ultra Messaging recommends that you monitor either a context or source/receiver, but not both. For exampleif Topic1 and Topic2 are mapped to the same transport session (which is the only transport session for thecontext) and you monitor both the receivers and the context, you will get 3 identical sets of statistics: one forTopic1 reporting the stats for it's transport session, one for Topic2 reporting the stats for the same transportsession, and one for the transport session via the context.

¨ In the case of wildcard receivers, only the context may be monitored. UM creates wildcard receiversdynamically as it detects topics which match the wildcard pattern. The application does not have access tothese dynamically-created receivers. So the only way to monitor a wildcard receiver is to monitor the contexton which it was created.

4. Should statistics be sent automatically, or on demand?

¨ Automatic sending of statistics is by far the simplest approach. You simply indicate how often the statisticsshould be gathered and sent. The rest is taken care of.

88 Chapter 6: Monitoring UMS

¨ On-demand is somewhat more involved. Your application decides when statistics should be gathered andsent. If you intend to use the arrival of statistics as a type of heartbeat, this is the method you should use.

The following sections present more discussion and sample source code about starting monitor sources, monitorreceivers and the LBMMON format and transport modules.

Creating a Monitoring SourceThe following examples demonstrate how to use the UM Monitoring API to enable monitoring in your application.

First, create a monitoring source controller:

lbm_context_t * ctx;lbm_src_t * src;lbm_rcv_t * rcv;lbmmon_sctl_t * monctl;

if (lbmmon_sctl_create(&monctl, lbmmon_format_csv_module(), NULL, lbmmon_transport_lbm_module(), NULL) == -1){ fprintf(stderr, "lbmmon_sctl_create() failed\n"); exit(1);}

The above code tacitly assumes that the ctx, src, and rcv variables have been previously assigned via the appropriateUM API calls.

The monitoring source controller object must be passed to subsequent calls to reference a specific source controller.One implication of this is that it is possible to have multiple monitoring source controllers within a single application,each perhaps monitoring a different set of objects.

In the above example, the default CSV format module and default UM transport module are specified via the providedmodule functions lbmmon_format_csv_module() and lbmmon_transport_lbm_module().

Specifying the Object to MonitorOnce a monitoring source controller is created, the application can monitor a specific context using:

if (lbmmon_context_monitor(monctl, ctx, NULL, 10) == -1){ fprintf(stderr, "lbmmon_context_monitor() failed\n"); exit(1);}

The above example indicates that statistics for all transports on the specified context will be gathered and sent every10 seconds.

A UM source can be monitored using:

if (lbmmon_src_monitor(monctl, src, NULL, 10) == -1){ fprintf(stderr, "lbmmon_src_monitor() failed\n"); exit(1);}

Finally, an UM receiver can be monitored using:

if (lbmmon_rcv_monitor(monctl, rcv, NULL, 10) == -1){ fprintf(stderr, "lbmmon_rcv_monitor() failed\n"); exit(1);}

The two above examples also request that statistics for all transports on the specified source or receiver be gatheredand sent every 10 seconds.

UMS Monitoring API 89

Statistics can also be gathered and sent in an on-demand manner. Passing 0 for the Seconds parameter tolbmmon_context_monitor(), lbmmon_src_monitor(), or lbmmon_rcv_monitor() prevents the automaticgathering and sending of statistics. To trigger the gather/send process, use:

lbmmon_sctl_sample(monctl);

Such a call will perform a single gather/send action on all monitored objects (contexts, sources, and receivers) whichwere registered as on-demand.

As part of application cleanup, the created monitoring objects should be destroyed. Each individual object can bede-registered using lbmmon_context_unmonitor(), lbmmon_src_unmonitor(), or lbmmon_rcv_unmonitor(). Finally,the monitoring source controller can be destroyed using:

lbmmon_sctl_destroy(monctl);

Any objects which are still registered will be automatically de-registered by lbmmon_sctl_destroy().

Receiving Monitoring DataTo make use of the statistics, an application must be running which receives the monitor data. This application createsa monitoring receive controller, and specifies callback functions which are called upon the receipt of source orreceiver statistics data.

Use the following to create a monitoring receive controller:

lbmmon_rctl_t * monctl;lbmmon_rctl_attr_t * attr;lbmmon_rcv_statistics_func_t rcvcb = { rcv_statistics_cb };lbmmon_src_statistics_func_t srccb = { src_statistics_cb };lbmmon_evq_statistics_func_t evqcb = { evq_statistics_cb };lbmmon_ctx_statistics_func_t ctxcb = { ctx_statistics_cb };

if (lbmmon_rctl_attr_create(&attr) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_create() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_attr_setopt(attr, LBMMON_RCTL_RECEIVER_CALLBACK, (void *) &rcvcb, sizeof(rcvcb)) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_setopt() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_attr_setopt(attr, LBMMON_RCTL_SOURCE_CALLBACK, (void *) &srccb, sizeof(srccb)) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_setopt() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_attr_setopt(attr, LBMMON_RCTL_EVENT_QUEUE_CALLBACK, (void *) &evqcb, sizeof(evqcb)) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_setopt() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_attr_setopt(attr, LBMMON_RCTL_CONTEXT_CALLBACK, (void *) &sctxcb, sizeof(ctxcb)) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_setopt() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_create(&monctl, lbmmon_format_csv_module(), NULL, lbmmon_transport_lbm_module(), (void *) transport_options, attr) != 0){ fprintf(stderr, "call to lbmmon_rctl_create() failed, %s\n", lbmmon_errmsg()); exit(1);}if (lbmmon_rctl_attr_delete(attr) != 0){ fprintf(stderr, "call to lbmmon_rctl_attr_delete() failed, %s\n", lbmmon_errmsg()); exit(1);}

90 Chapter 6: Monitoring UMS

As in the earlier example, the default CSV format module and default UM transport module are specified via theprovided module functions lbmmon_format_csv_module() and lbmmon_transport_lbm_module().

As an example of minimal callback functions, consider the following example:

void rcv_statistics_cb(const void * AttributeBlock, const lbm_rcv_transport_stats_t * Statistics){ lbm_ulong_t source = LBMMON_ATTR_SOURCE_NORMAL; if (lbmmon_attr_get_source(AttributeBlock, &source) != 0) { source = LBMMON_ATTR_SOURCE_NORMAL; } switch (Statistics->type) { case LBM_TRANSPORT_STAT_TCP: handle_rcv_tcp_statistics(); break; case LBM_TRANSPORT_STAT_LBTRM: switch (source) { case LBMMON_ATTR_SOURCE_IM: handle_rcv_im_lbtrm_statistics(); break; default: handle_rcv_lbtrm_statistics(); break; } break; case LBM_TRANSPORT_STAT_LBTRU: handle_rcv_lbtru_statistics(); break; }}

void src_statistics_cb(const void * AttributeBlock, const lbm_src_transport_stats_t * Statistics){ lbm_ulong_t source = LBMMON_ATTR_SOURCE_NORMAL; if (lbmmon_attr_get_source(AttributeBlock, &source) != 0) { source = LBMMON_ATTR_SOURCE_NORMAL; } switch (Statistics->type) { case LBM_TRANSPORT_STAT_TCP: handle_src_tcp_statistics(); break; case LBM_TRANSPORT_STAT_LBTRM: switch (source) { case LBMMON_ATTR_SOURCE_IM: handle_src_im_lbtrm_statistics(); break; default: handle_src_lbtrm_statistics(); break; } break; case LBM_TRANSPORT_STAT_LBTRU: handle_src_lbtru_statistics(); break; }}

void ctx_statistics_cb(const void * AttributeBlock, const lbm_context_stats_t * Statistics){ /* Handle context stats */}

void evq_statistics_cb(const void * AttributeBlock, const lbm_event_queue_stats_t * Statistics){ /* Handle event queue stats */}

UMS Monitoring API 91

Upon receipt of a statistics message, the appropriate callback function is called. The application can then do whateveris desired with the statistics data, which might include writing it to a file or database, performing calculations, orwhatever is appropriate.

Beyond the actual statistics, several additional pieces of data are sent with each statistics packet. These data arestored in an attribute block, and are accessible via the lbmmon_attr_get_*() functions. Currently, these data includethe IPV4 address of machine which sent the statistics data, the timestamp (as a time_t) at which the statistics weregenerated, and the application ID string supplied by the sending application at the time the object was registered formonitoring. See lbmmon_attr_get_ipv4sender(), lbmmon_attr_get_timestamp(), andlbmmon_attr_get_appsourceid() for more information.

The UMS Transport ModuleThe UM transport module understands several options which may be used to customize your use of the module. Theoptions are passed via the TransportOptions parameter to thelbmmon_sctl_create() and lbmmon_rctl_create()functions, as a null-terminated string containing semicolon-separated name/value pairs.

The following options are available:

¨ config specifies a configuration file. This file is processed in a manner similar to lbm_config(). However, unlikelbm_config(), the current default attributes are not changed. Instead, the options parsed from the configurationfile are applied only to the UM objects created by the module.

¨ topic specifies the topic name to use for sending and receiving statistics. By default, the topic /29west/statisticsis used.

¨ wctopic specifies (for monitor receivers only) a wildcard pattern to be used to receive statistics.

As an example, assume your application needs to use a special configuration file for statistics. The following callallows your application to customize the UM transport module using the configuration file stats.cfg.

lbmmon_sctl_t * monctl;const char * tropt = "config=stats.cfg";if (lbmmon_sctl_create(&smp;monctl, lbmmon_format_csv_module(), NULL, lbmmon_transport_lbm_module(), tropt) == -1){ fprintf(stderr, "lbmmon_sctl_create() failed\n"); exit(1);}

If your application also needs to use a specific topic for statistics, the following code specifies that, in addition to theconfiguration file, the topic StatisticsTopic be used for statistics.

lbmmon_sctl_t * monctl;const char * tropt = "config=stats.cfg;topic=StatisticsTopic";if (lbmmon_sctl_create(&monctl, lbmmon_format_csv_module(), NULL, lbmmon_transport_lbm_module(), tropt) == -1){ fprintf(stderr, "lbmmon_sctl_create() failed\n"); exit(1);}

It is important to use the same topic and configuration for both monitor sources and receivers. Otherwise yourapplications may send the statistics, but the monitor receiver won't be able to receive them.

To view the source code for all LBMMON transport modules, see LBMMON Example Source Code found on theRelated Pages tab in the C Application Programmer's Interface.

The UDP Transport ModuleThe UDP transport module understands several options which may be used to customize your use of the module. Theoptions are passed via the TransportOptions parameter to the lbmmon_sctl_create() and lbmmon_rctl_create()functions, as a null-terminated string containing semicolon-separated name/value pairs.

92 Chapter 6: Monitoring UMS

The UDP module supports sending and receiving via UDP unicast, UDP broadcast, and UDP multicast. The followingoptions are available.

¨ address specifies the unicast IP address to which statistics are sent via UDP. Applicable to sender only.

¨ port is the IP port packets are sent to. Defaults to 2933.

¨ interface specifies the network interface over which multicast UDP is sent or received.

¨ mcgroup is the multicast group on which to send and receive UDP packets.

¨ bcaddress specified the broadcast address to which UDP packets are sent. Applicable to sender only.

¨ ttl specifies the TTL for each multicast UDP packet. Applicable to sender only.

To view the source code for all LBMMON transport modules, see LBMMON Example Source Code found on theRelated Pages tab in the C Application Programmer's Interface.

The SNMP Transport ModuleThe SNMP transport modules operates in identical fashion to the UMS Transport Module. See “The UMS TransportModule” on page 92

To view the source code for all LBMMON transport modules, see LBMMON Example Source Code found on theRelated Pages tab in the C Application Programmer's Interface.

Automatic MonitoringInstead of building a monitoring capability into your application using the UM Monitoring API, automatic monitoringallows you to easily produce monitoring statistics with the UM Monitoring API by setting a few simple UM configurationoptions. Automatic monitoring does not require any changes to your application. You control Automatic Monitoringwith eight configuration options, see Automatic Monitoring Options in the UM Configuration Guide.

You can enable Automatic Monitoring for either or both of the following.

¨ Transport Statistics - Automatic monitoring of transport statistics reflect data for all the transport sessions withinthe UM context. You cannot, however, receive statistics for an individual transport session. Essentially, you turn onautomatic monitoring of a context's transport sessions by specifying a context monitor_interval . The use of theUltra Messaging SNMP Agent requires the lbmsnmp monitor_transport .

¨ Event Queue Statistics - Automatic Monitoring of Event Queues provides statistics for all the Event Queues withinthe UM context. You turn on automatic monitoring of a context's Event Queues by specifying a event_queuemonitor_interval .

You can also set environment variables to turn on automatic monitoring for all UM contexts (transports and eventqueues). See Automatic Monitoring Options for more information.

Monitoring ExamplesThis section demonstrates the use of the two UM monitoring example applications described in /doc/example/index.html. We present advice based on what we have seen productively monitored by customers and our own

Automatic Monitoring 93

knowledge of transport statistics that might be of interest. Of course, what you choose to monitor depends on yourneeds so merge these thoughts with your own needs to determine what is best for you.

¨ “lbmmon.c” on page 94

¨ “lbmmonudp.c and lbmmondiag.pl” on page 95

lbmmon.cThe example application lbmmon.c acts as a Monitor Receiver and is provided in both executable and source form. Itwrites monitoring statistics to the screen and can be used in conjunction with other example applications (which act asthe Monitor Sources). The following procedure uses lbmrcv and lbmsrc to create messaging traffic and adds aconfiguration file in order to specify the LBT-RM transport instead of the TCP default. (The LBT-RM transport displaysmore statistics than TCP.)

Since UM does not generate monitoring statistics by default, you must activate monitoring in your application. For theexample application, use the --monitor-ctx=n option where n is the number of seconds between reports. The followingprocedure activates monitoring on the receiver, specifying the context (ctx) to create a complete set of receiverstatistics. You could activate monitoring in a similar fashion on the source and create source statistics.

To use lbmmon to view statistics from sample application output:

1. Create configuration file with the single option of source transport lbtrm and name it LBTRM.cfg.

2. Run lbmmon --transport-opts="config=LBTRM.cfg"3. Run lbmrcv -c LBTRM.cfg --monitor-ctx="5" Arizona4. Run lbmsrc -c LBTRM.cfg ArizonaAfter lbmsrc completes, the final output for lbmmon should closely resemble the following.

Receiver statistics received from C:\Program Files\29West\UME_1.2.1\Win2k-i386\bin\lbmrcv.exe at 10.29.1.78, sent Wed Jan 09 14:25:49 2008Source: LBTRM:10.29.1.78:4391:323382d8:224.10.10.10:4400Transport: LBT-RMLBT-RM messages received : 45455Bytes received : 370000000LBT-RM NAK packets sent : 0LBT-RM NAKs sent : 0Lost LBT-RM messages detected : 0NCFs received (ignored) : 0NCFs received (shed) : 0NCFs received (retransmit delay) : 0NCFs received (unknown) : 0Loss recovery minimum time : 4294967295msLoss recovery mean time : 0msLoss recovery maximum time : 0msMinimum transmissions per individual NAK : 4294967295Mean transmissions per individual NAK : 0Maximum transmissions per individual NAK : 0Duplicate LBT-RM data messages received : 0LBT-RM messages unrecoverable (window advance) : 0LBT-RM messages unrecoverable (NAK generation expiration): 0LBT-RM LBM messages received : 10000000LBT-RM LBM messages received with no topic : 0LBT-RM LBM requests received : 0

Notes:

¨ Since this procedure was done on a single machine. No packets were lost and therefore lbmrcv did not generateany NAKs and lbmsrc did not send any NCFs. If you run this procedure across a network, packets may be lost andyou would see statistics for NAKs, NCFs and loss recovery.

¨ This procedure activates monitoring on the receiver, specifying the context (--monitor-ctx) to create a completeset of receiver transport statistics. You could activate monitoring in a similar fashion on the source and create

94 Chapter 6: Monitoring UMS

source statistics. Each set of statistics shows one side of the transmission. For example, source statistics containinformation about NAKs received by the source (ignored, shed, retransmit delay, etc.) where receiver statisticscontain data about NCFs received. Each view can be helpful.

¨ Moreover, as explained earlier in Specifying the Object to Monitor, individual receivers or sources can bemonitored instead of all transport activity for a context. For this procedure, use --monitor-rcv or --monitor-src.

¨ You could run this procedure again specifying a different transport (LBT-RU or TCP) in the configuration file andreceive a different set of statistics. For descriptions of all the transport statistics, refer to the transport statisticsdata structures in the C Application Programmer's Interface. Click on the Data Structures tab at the top and click onlbm_rcv_transport_stats_t or lbm_src_transport_stats_t.

lbmmonudp.c and lbmmondiag.plThe example application, lbmmonudp.c receives UM statistics and forwards them as CSV data over a UDP transport.The Perl script, lbmmondiag.pl, can read UDP packets and process the statistics, reporting Severity 1 and Severity 2events. This script only reports on LBT-RM transports.

To run lbmmonudp.c with lbmmondiag.pl, use the following procedure.

1. Create configuration file with the single option of source transport lbtrm and name it LBTRM.cfg.

2. Run lbmmonudp -a 127.0.0.1 --transport-opts="config=LBTRM.cfg"3. Run lbmrcv -c LBTRM.cfg --monitor-ctx="5" Arizona4. Run lbmsrc -c LBTRM.cfg Arizona5. Run lbmmondiag.plThe following sections discuss some of the possible results of this procedure. Your results will vary depending uponconditions in your network or if you run the procedure on a single machine.

Severity 1 — Monitoring Unrecoverable LossThe most severe system problems are often due to unrecoverable datagram loss at the reliable transport level. Theseare reported as severity 1 events by the lbmmondiag.pl example script. Many of the scalability and latency benefits ofUM come from the use of reliable transport protocols like LBT-RM and LBT-RU. These protocols provide lossdetection, retransmission, and recovery up to the limits specified by an application. Unrecoverable loss is reported bythe transport when loss repair is impossible within the specified limits.

Unrecoverable transport loss often (but not always) leads to unrecoverable message loss so it is very significant toapplications that benefit from lossless message delivery.

Unrecoverable loss can be declared by receivers when the transport_lbtrm_nak_generation_interval has endedwithout receipt of repair. Each such loss event is recorded by incrementing the unrecovered_tmo field inlbm_rcv_transport_stats_t. Output from lbmmondiag.pl might look like this:

Sev1: 34 datagrams unrecovered due to NAK generation interval ending

Unrecoverable loss can also be triggered at receivers by notice from a source that the lost datagram has passed out ofthe source's transmission window. Each such loss event is recorded by incrementing the unrecovered_txw field inlbm_rcv_transport_stats_t. Output from lbmmondiag.pl might look like this:

Sev1: 249 datagrams unrecovered due to transmission window advancement

Monitoring Examples 95

Severity 2 — Monitoring Rate Controller ActivityThe data and retransmission rate controllers built into LBT-RM provide for stable operation under all traffic conditions.These rate controllers introduce some latency at the source since that is generally preferable to the alternative of NAKstorms or other unstable states. The lbmmondiag.pl example script reports this activity as a severity 2 event sincelatency is normally the only effect of their operation.

Activity of the rate controller indicates that a source tried to send faster than the configuredtransport_lbtrm_data_rate_limit . Normally, this limit is set to the speed of the fastest receivers. Sending faster thanthis rate would induce loss in all receivers so it is generally best to add latency at the source or avoid sending in suchsituations.

The current number of datagrams queued by the rate controller is given in the rctlr_data_msgs field inlbm_src_transport_stats_t. No more than 10 datagrams are ever queued. Output from lbmmondiag.pl might look likethis:

Sev2: 10 datagrams queued by data rate controller

Activity of the retransmission rate controller indicates that receivers have requested retransmissions in excess of theconfigured transport_lbtrm_retransmit_rate_limit . Latency is added to retransmission requests in excess of thelimit to control the amount of latency they may add to messages being sent the first time. This behavior avoids NAKstorms.

The current number of datagrams queued by the retransmission rate controller is given in the rctlr_rx_msgs field inlbm_src_transport_stats_t. No more than 101 datagrams are ever queued. Output from lbmmondiag.pl might looklike this:

Sev2: 101 datagrams queued by retransmission rate controller

Severity 2 — Monitoring Loss Recovery Activity for a ReceiverIt is important to monitor loss recovery activity because it always adds latency if the loss is successfully repaired. UMdefaults generally provide for quite a bit of loss recovery activity before loss would become unrecoverable. Statisticson such activity are maintained at both the source and receiver. Unrecoverable loss will normally be preceded by aburst of such activity.

UM receivers measure the amount of time required to repair each loss detected. For each transport session, anexponentially weighted moving average is computed from repair times and the maximum and minimum times aretracked.

The total number of losses detected appears in the lost field in lbm_rcv_transport_stats_t. It may be multiplied bythe average repair time given in the nak_stm_mean field in lbm_rcv_transport_stats_t to estimate of the amount oflatency that was added to repair loss. This is probably the single most important metric to track for those interested inminimizing repair latency. The lbmmondiag.pl script reports this whenever the lost field changes and the averagerepair time is nonzero. Output might look like this:

Sev2: 310 datagrams lost Sev2: 112.236 seconds estimated total latency due to repair of 564 losses

Note: This estimate only includes latency added in the recovery of lost messages. Requiring ordered delivery alsoadds latency for all messages that arrive after the time of loss and before the time that repair arrives. See theordered_delivery option to control this.

96 Chapter 6: Monitoring UMS

In addition to counting losses detected, UM reliable receivers also count the number of NAKs generated in thenaks_sent field in lbm_rcv_transport_stats_t. Output from lbmmondiag.pl might look like this:

Sev2: 58 NAKs sent

Those who are new to reliable multicast protocols are sometimes surprised to learn that losses detected do not alwayslead to NAK generation. If a datagram is lost in the network close to the source, it is common for many receivers todetect loss simultaneously when a datagram following the loss arrives. Scalability would suffer if all receivers thatdetected loss reported it by generating a NAK at the same time. To improve scalability, a random delay is added toNAK generation at each receiver. Since retransmissions are multicast, often only one NAK is generated to repair theloss for all receivers. Thus it is common for the number of losses detected to be much larger than the number of NAKssent, especially when there are many receivers with similar loss patterns.

Severity 2 — Monitoring Loss Recovery Activity for a SourceFor sources, the principal concern is often understanding how much the retransmission of messages already sent atleast once slowed down the source. Obviously, bandwidth and CPU time spent servicing retransmission requestscannot be used to send new messages. This is the way that lossy receivers add latency for lossless receivers.

UM sources track the number of NAKs received in the naks_rcved field in lbm_src_transport_stats_t. The number ofdatagrams that they retransmit to repair loss is recorded in the rxs_sent field in lbm_src_transport_stats_t.

The number of retransmitted datagrams may be multiplied by the average datagram size and divided by the wirespeed to estimate the amount of latency added to new messages by retransmission. Output from the examplelbmmondiag.pl script might look like this:

Sev2: 7478 NAKs received Sev2: 50 retransmissions sent Sev2: 0.015056 seconds estimated total latency due to retransmissions

Interpreting LBT-RM Source StatisticsLBT-RM sources maintain many statistics that can be useful in diagnosing reliable multicast problems. See the UMAPI documentation lbm_src_transport_stats_lbtrm_t Structure Reference for a description of the fields. Theremainder of this section gives advice on interpreting the statistics.

Divide naks_rcved by msgs_sent to find the likelihood that sending a message resulted in a NAK being received.Expect no more than a few percent on a network with reasonable loss levels.

Divide rxs_sent by msgs_sent to find the ratio of retransmissions to new data. Many NAKs arriving at a source willcause many retransmissions.

Divide naks_shed by naks_rcved to find the likelihood that excessive NAKs were ignored. Consider reducing loss toavoid NAK generation.

Divide naks_rcved by nak_pckts_rcved to find the likelihood that NAKs arrived individually (~1 -> individual NAKslikely; ~0 -> NAKs likely to have arrived grouped in a single packet). Individual NAKs often indicate sporadic loss whilegrouped NAKs often indicate burst loss.

Divide naks_rx_delay_ignored by naks_ignored to find the likelihood that NAKs arrived during the ignore intervalfollowing a retransmission. The configuration option transport_lbtrm_ignore_interval controls the length of thisinterval.

Interpreting LBT-RM Source Statistics 97

C H A P T E R 7

Manpage for lbmrdThis chapter includes the following topic:

¨ lbmrd, 98

lbmrd{ lbmrd | { -a } | { --activity } | { -d } | { --dump-dtd } | { -h } | { --help } | { -i } | { --interface } | { -L } | {--logfile } | { -p } | { --port } | { -t } | { --ttl } | { -v } | { --validate } | { config-file } }

Description

Resolver services for UM messaging products are provided by lbmrd.

The -i and -p (or --interface and --port) options identify the network interface IP address and port that lbmrd opens tolisten for unicast topic resolution traffic. The defaults are INADDR_ANY and 15380, respectively.

The -a and -t (or --activity and --ttl) options interact to detect and remove "dead" clients, i.e., UMS/UME clientapplications that are in the lbmrd active client list, but have stopped sending topic resolution queries, advertisements,or keepalives, usually due to early termination or looping. These are described in detail below.

Option -t describes the length of time (in seconds), during which no messages have been received from a given client,that will cause that client to be marked "dead" and removed from the active client list. Ultra Messaging recommends avalue at least 5 seconds longer than the longest network outage you wish to tolerate.

Option -a describes a repeating time interval (in milliseconds) after which lbmrd checks for these "dead" clients. UltraMessaging recommends a value not larger than -t * 1000.

NOTE: Even clients that send no topic resolution advertisements or queries will still send keepalive messages tolbmrd every 5 seconds. This value is hard-coded and not configurable.

The output will be written to a log file if either -L or --logfile is supplied.

The DTD used to validate a configuration file will be dumped to standard output with the -d or --dump-dtd option. Afterdumping the DTD, lbmrd exits immediately.

The configuration file will be validated against the DTD if either the -v or --validate options are given. After attemptingvalidation, lbmrd exits immediately. The exit status will be 0 for a configuration file validated by the DTD and non-zerootherwise.

Command line help is available with -h or --help.

Exit Status

The exit status from lbmrd is 0 for success and some non-zero value for failure.

98

C H A P T E R 8

UM Log MessagesThis chapter includes the following topics:

¨ UM Core Log Messages, 99

¨ UM Core API Log Messages, 167

¨ UM Lbmrd Log Messages, 192

¨ UM Dynamic Routing Log Messages, 193

UM Core Log MessagesThe following table lists log messages from Ultra Messaging Streaming Edition core functionality.

You may find searching on the Log Message ID the most effective method to find the message's description.

Table 1. UM Core Log Messages

Message Description Resolution

Core-5402-1: Hot-failover receiverignoring mismatched sequence numbersize

A hot failover receiver dropped amessage that had a sequence numbersize different than what it was expecting.

Ensure that all hot failover sources on thesame topic are sending using the samesequence number size

Core-5455-1: epoll_ctl:EPOLL_CTL_DEL returned: errno:%d:%s

If errno is EBADF or ENOENT, Filedescriptor is closed beforelbm_cancel_fd call

Core-5455-2: lbm_fd_cancel epoll_ctl:epoll_op: %d returned errno:%d:%s

If errno is EBADF or ENOENT, file desc isclosed before lbm_cancel_fd_call

Core-5480-1: OTR Initiated for [%s][%s] OTR has been initiated either for the firsttime on this source, or it has been at leasta log_alert_cooldown's length of timesince the last log alert.

Core-5480-2: OTR Repeated for [%s][%s] (%u times)

OTR has been ongoing for this source.

Core-5480-3: no response received tolate join initiation request - skipping latejoin

The receiver was unable to get aresponse from a source claiming toprovide late join.

Contact Informatica support.

99

Message Description Resolution

Core-5480-45: message delivery failed:persrc ctlr %p perrcv ctlr %p sqn %x

Internal error attempting to processrecovered data.

Contact Informatica support

Core-5480-46: rxr ctlr %p request failedrecovering sqns %x - %x from perrcv ctlr%p

Internal error attempting to initiaterecovery of data.

Contact Informatica support.

Core-5480-47: mtt register failed: (%u)[%s]

Internal error while attempting to processa command on an mtt transport thread.

Contact Informatica support.

Core-5688-1279: WARNING: TCPsession exists and uses a differenttransport_session_maximum_buffer[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_session_maximum_buffersetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1280: WARNING: TCPsession exists and uses a differenttransport_tcp_multiple_receiver_behavior [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_tcp_multiple_behavior setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-1281: WARNING: TCPsession exists and uses a differenttransport_source_side_filtering_behavior [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_source_side_filtering_behavior setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1284: WARNING: LBT-RMsession for multicast address %s existsand uses a different transport_lbtrm_tgsz[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea different transport_lbtrm_tgsz setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-1285: WARNING: LBT-RMsession for multicast address %s existsand uses a differenttransport_lbtrm_ignore_interval [%d]than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtrm_ignore_interval setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-1286: WARNING: LBT-RMsession for multicast address %s existsand uses a different

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea different

100 Chapter 8: UM Log Messages

Message Description Resolution

transport_lbtrm_sm_minimum_interval[%d] than requested [%d].

transport_lbtrm_sm_minimum_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1287: WARNING: LBT-RMsession for multicast address %s existsand uses a differenttransport_lbtrm_sm_maximum_interval[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtrm_maximum_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1288: WARNING: LBT-RMsession for multicast address %s existsand uses a differenttransport_lbtrm_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtrm_transmission_window_size setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1289: WARNING: LBT-RMsession for multicast address %s existsand uses a differenttransport_lbtrm_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtrm_transmission_window_size setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1290: WARNING: LBT-RMsession for multicast address %s existsand uses a differenttransport_lbtrm_coalesce_threshold[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtrm_coalesce_thresholdsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1291: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_client_map_size [%d]than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_client_map_size setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-1292: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_transmission_window_size setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

UM Core Log Messages 101

Message Description Resolution

Core-5688-1293: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_transmission_window_size setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1294: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_ignore_interval [%d]than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_ignore_interval setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-1295: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_sm_minimum_interval[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_sm_minimum_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1296: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_sm_maximum_interval[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_sm_maximum_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1297: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_client_activity_timeout[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_client_activity_timeoutsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1298: WARNING: LBT-RUsession exists and uses a differenttransport_lbtru_coalesce_threshold [%d]than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtru_coalesce_thresholdsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1299: WARNING: LBT-RUsession exists and uses a differenttransport_source_side_filtering_behavior [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea different

102 Chapter 8: UM Log Messages

Message Description Resolution

transport_lbtru_source_side_filtering_behavior setting. Please refer to UMSObjects section of the Design Conceptsin the documentation.

Core-5688-1302: WARNING: LBT-IPCsession exists and uses a differenttransport_lbtipc_sm_interval [%d] thanrequested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea different transport_lbtipc_sm_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1303: WARNING: LBT-IPCsession exists and uses a differenttransport_lbtipc_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtipc_transmission_window_size setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-1305: WARNING: Host hasmultiple RDMA-capable interfaces; goingto use [%s][%s].

As UMS initializes, it scans for RMDAcapable interfaces in the system. If morethan one is found and a specific interfacehas not be configured, the first one foundwill be used. Use"transport_lbtrdma_interface" to specifythe desired RDMA interface.

Core-5688-1793: WARNING: Requestedreceiver attributes will be ignored,previous receiver for topic [%s] hasalready defined the attributes.

Indicates a programming error where areceiver topic lookup was performedusing different receiver attributes. In thiscase the original attributes are used.

Core-5688-1795: WARNING:transport_lbtru_activity_timeout [%d] isless thantransport_lbtru_nak_generation_interval[%d], this can result in silent data loss ifloss occurs within the activity timeoutinterval prior to the end of the transportsession.

If the transport_lbtru_activity_timeout isless than thetransport_lbtru_nak_generation_intervalit is possible that a receiver can tear downthe transport session before it was able tosend a NAK for a lost message. Whenthis happens the message isunrecoverable.

Core-5688-1797: LBT-RU client %s.%usent unknown CREQ request %x

UMS received a unicast message with aninvalid message type. The message isdropped. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

Core-5688-1798: LBMD EV versionincorrect (%u). Dropping.

UMS daemon received a message withan invalid version number. The messageis dropped. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

UM Core Log Messages 103

Message Description Resolution

Core-5688-1799: LBMD EV type notsupport (%u). Dropping.

UMS daemon received a message withan invalid message type. The message isdropped. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

Core-5688-1800: LBMD EV source typesupport (%u). Dropping.

UMS daemon received a message froman unknown type of source. Themessage is dropped. Contact Informaticasupport if this message occurs frequentlyor when only one version of Informaticasoftware is being used.

Core-5688-1801: LBMD EV unknownnext header %x, ignoring header.

UMS daemon received a message with aheader that was not recognized. Thisheader will be ignored, but the rest of themessage will be processed. This ispotentially due to a newer version ofsoftware sending messages and is notharmful. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

Core-5688-1802: LBMD EV unknownnext header %x, dropping message.

UMS daemon received a message withan invalid message type. The message isdropped. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

Core-5688-1804: HF message receiverfunction returned -1

An error occurred processing a messagereceived by a hot failover receiver. Themessage was discarded. Please contactInformatica if this message occursfrequently.

Core-5688-1811: FATAL: WSA startuperror - %d

FATAL: Error in starting WindowsSocket. The specific Windows SocketsError Code is returned in the errormessage.

Core-5688-1833: WARNING: Host hasmultiple multicast-capable interfaces;going to use [%s][%s].

This warning occurs if the host machinehas multiple multicast-capable interfacesdetected, and the context attributes donot specify an interface (via theresolver_multicast_interface option). Inthis situation the first interface found isused.

Core-5688-1836: CRITICAL: DBLsupport requested, but %s not found.Ensure %s is in the search path to enableDBL support.

This error results when dbl accelerationis specified through contextconfiguration, but we are unable to locatethe dbl shared library. Usually this justmeans adding /opt/dbl/lib/ to yourLD_LIBRARY_PATH or the dbl.dlllocation to your PATH on Windows.

104 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-1841: default thread stacksize is perhaps too small, %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small. The size of the defaultstack size is dumped and will then be setto a larger size automatically.

Core-5688-1842: reset thread stack sizeto %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small and is reallocated. Thismessage reports the new size of thestack.

Core-5688-1847: default thread stacksize is perhaps too small, %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small. The size of the defaultstack size is dumped and will then be setto a larger size automatically.

Core-5688-1848: reset thread stack sizeto %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small and is reallocated. Thismessage reports the new size of thestack.

Core-5688-1864: dbl thread join: WFSOres=%d, GLE=%d

An error occurred while waiting for theDBL thread to terminate. Should nothappen. Please contact Informaticasupport for more details.

Core-5688-1865: lbm_context_delete:WFSO res=%d, GLE=%d

Error waiting for context thread to cleanlyexit. Should not happen. Please contactInformatica support for more details.

Core-5688-1866: lbm_context_delete:ISmall memory leak happened due toprobable race condition in Windows. Canbe ignored unless it happens many timesper hour.

Core-5688-1879: timer returned error %u[%s]

UMS encountered an error expiringtimers while processing events. Pleasecontact Informatica support for moredetails.

Core-5688-1880: wait returned error %u[%s]

UMS encountered an error processing anevent on a file descriptor. The event isdropped. Please contact Informaticasupport for more details.

Core-5688-1881: handle events returnederror %u [%s]

Socket returned error while waiting forcontext deletion. Can ignore unlesshappens many times per hour.

Core-5688-1883: timer returned error %u[%s]

UMS encountered an error expiringtimers while processing events. Pleasecontact Informatica support for moredetails.

UM Core Log Messages 105

Message Description Resolution

Core-5688-1888: timer returned error %u[%s]

UMS encountered an error expiringtimers while processing events. Pleasecontact Informatica support for moredetails.

Core-5688-1889: wait returned error %u[%s]

UMS encountered an error processing anevent on a file descriptor. The event isdropped. Please contact Informaticasupport for more details.

Core-5688-1890: handle events returnederror %u [%s]

Socket returned error while waiting forcontext deletion. Can ignore unlesshappens many times per hour.

Core-5688-1892: timer returned error %u[%s]

UMS encountered an error expiringtimers while processing events. Pleasecontact Informatica support for moredetails.

Core-5688-261: LBT-RDMA: ClientConnection: failed to register client

A client has joined the LBT-RDMAtransport but an error occurred trying toadd the client to the client map.

Core-5688-262: LBT-RDMA: ClientDisconnect: failed to remove client

A client has left the LBT-RDMA transportbut an error occurred trying to remove theclient to the client map.

Core-5688-263: LBT-RDMA: VMSconnection failed event (%s)

A connection failed event has beenreceived from the VRT library (formerlyVMS library). Please refer to thedescription given.

Core-5688-264: LBT-RDMA: unknownVMS connection event ID: %d (%s)

A connection event has been receivedfrom the VRT library (formerly VMSlibrary) but the event is not understood.Please refer to the event ID anddescription given.

Core-5688-265: LBT-RDMA: VMSMemory error event: (%s)

A memory error event has been receivedfrom the VRT library (formerly VMSlibrary). Please refer to the descriptiongiven.

Core-5688-266: LBT-RDMA: VMSGeneric library event: (%s)

A generic event has been received fromthe VRT library (formerly VMS library).Please refer to the description given.

Core-5688-267: LBT-RDMA: VMSunknown library event: %d (%s)

An event was received from the VRTlibrary (formerly VMS library) that is notunderstood. Please refer to the event IDand description given.

Core-5688-27: WARNING: %s configvariable %s is deprecated. Use %sinstead.

Configuration option is deprecated andhas been replaced, Informatica suggeststhe config option that can be usedinstead.

106 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-270: LBT-RDMA: unknownVMS log level: %d (%s)

A log event was received from the VRTlibrary (formerly VMS library) that is notunderstood. Please refer to the event IDand description given.

Core-5688-271: LBT-RDMA: VMStransport event received but notexpected: %d (%s)

A transport event was received from theVRT library (formerly VMS library) that isnot expected. Please refer to the event IDand description given.

Core-5688-272: LBT-RDMA: VMS fabricevent received but not expected: %d(%s)

A fabric event was received from the VRTlibrary (formerly VMS library) that is notexpected. Please refer to the event IDand description given.

Core-5688-273: LBT-RDMA: VMSunknown event class received: %d (%s)

An event was received from the VRTlibrary (formerly VMS library) that is notunderstood. Please refer to the event IDand description given.

Core-5688-276: lbtrdma_txw_open:failed to subscribe to VMS store (0x%x:%s:%u)

An error occurred when trying to join theLBT-RDMA transport given. This couldoccur if the Topic Advertisement is staleand the transport has already beendeleted.

Core-5688-277: lbtrdma_init: Problemloading VMS library

The VRT library (formerly VMS library)required for LBT-RDMA can not beloaded. Please check the installation.

Core-5688-278: lbtrdma_init: Can notinitialize the VMS library (%d)

The VRT library (formerly VMS library)required for LBT-RDMA reported aninitialization error (given). Please checkthe installation.

Core-5688-279: lbtrdma_init: Can notinitialize VMS client (%d)

The VRT library (formerly VMS library)required for LBT-RDMA reported a clientinitialization error (given). Please checkthe installation.

Core-5688-28: WARNING: %s configvariable %s is deprecated. Has noeffect.

Configuration option is deprecated andhas no effect, UMS will ignore the configoptions and continue operation.

Core-5688-280: lbtrdma_init: Can notinitialize VMS server (%d)

The VRT library (formerly VMS library)required for LBT-RDMA reported a serverinitialization error (given). Please checkthe installation.

Core-5688-281: lbtrdma_init: Can notregister VMS event handler (%d)

The VRT library (formerly VMS library)required for LBT-RDMA reported thegiven error when registering an eventcallback function. Please check theinstallation.

UM Core Log Messages 107

Message Description Resolution

Core-5688-282:lbm_transport_lbtrdma_ctlr_delete:WFSO res=%d, GLE=%d

The LBT-RDMA receiver thread failed toshutdown during context delete. Refer tothe return status and OS error codegiven.

Core-5688-283: default thread stack sizeis perhaps too small, %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small. The size of the defaultstack size is dumped and will then be setto a larger size automatically.

Core-5688-284: reset thread stack sizeto %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small and is reallocated. Thismessage reports the new size of thestack.

Core-5688-285: LBT-RDMA Error:Creating Receiver Thread (%d)

An error was returned when trying tocreate the LBT-RDMA receiver thread.Please refer to the OS error numbergiven.

Core-5688-286: CRITICAL: LBM licenseinvalid [%s]

Critical: The UMS license could not bevalidated. Contact Informatica support toverify the license.

Core-5688-287: WARNING: LBM licensewarning [%s]

Warning: The UMS license could not bevalidated. Contact Informatica support toverify the license.

Core-5688-288: CRITICAL: LBM notlicensed

Critical: The UMS license could not bevalidated. Check the correct license isbeing specified. Contact Informaticasupport to verify the license.

Core-5688-2947: default thread stacksize is perhaps too small, %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small. The size of the defaultstack size is dumped and will then be setto a larger size automatically.

Core-5688-2948: reset thread stack sizeto %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small and is reallocated. Thismessage reports the new size of thestack.

Core-5688-2950: NOTICE: could notdrain dbl socket on exit. (Read %ddatagrams) Proceeding with cleanup.

During shutdown, the DBL thread closesall open sockets and then drains all user-space buffers. This warning can be safelyignored.

Core-5688-2951: WARNING: DBLenabled, but transport LBT-RM datagrammax size %d > %d. Packet larger thanMTU will be dropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. This

108 Chapter 8: UM Log Messages

Message Description Resolution

warning is printed if thedatagram_max_size is greater than 9000bytes, the maximum frame size currentlysupported by DBL.

Core-5688-2952: NOTICE: DBL enabled,but transport LBT-RM datagram max size%d > %d. Packets larger than MTU will bedropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. Thiswarning is printed if thedatagram_max_size is greater than 1500bytes, the standard frame size supportedby DBL.

Core-5688-2953: WARNING: DBLenabled, but transport LBT-RU datagrammax size %d > %d. Packet larger thanMTU will be dropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. Thiswarning is printed if thedatagram_max_size is greater than 9000bytes, the maximum frame size currentlysupported by DBL.

Core-5688-2954: NOTICE: DBL enabled,but transport LBT-RU datagram max size%d > %d. Packets larger than MTU will bedropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. Thiswarning is printed if thedatagram_max_size is greater than 1500bytes, the standard frame size supportedby DBL.

Core-5688-2955: WARNING: DBLenabled, but resolver datagram max size%d > %d. Packet larger than MTU will bedropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. Thiswarning is printed if thedatagram_max_size is greater than 9000bytes, the maximum frame size currentlysupported by DBL.

Core-5688-2956: NOTICE: DBL enabled,but resolver datagram max size %d > %d.Packets larger than MTU will bedropped.

DBL does not support fragmentation. Inorder to guarantee that no datagrams aredropped for being too large, UMS must beinstructed to fragment messages itselfusing the specified attribute. Thiswarning is printed if thedatagram_max_size is greater than 1500bytes, the standard frame size supportedby DBL.

Core-5688-2959: WARNING: deletingdbl device returned %d

The DBL device could not be closedcleanly. DBL currently does not returnfailure from the specified function, but the

UM Core Log Messages 109

Message Description Resolution

log message is included in case futureversions return failure.

Core-5688-2972: LBT-RDMA: SourcePaced, wakeup not expected

The LBT-RDMA transport is sourcepaced and no rate limiter is implemented.Therefore, a wake-up event should neveroccur. Please contact Informaticasupport.

Core-5688-3096: Unable to create dctlrentry: %s

This generally means memory couldn'tbe allocated. The error messageincluded should specify the exact errorcondition.

Core-5688-3101: NOTICE: UME receiverhas ordered_delivery set to 0 andume_explicit_ack_only set to 1.

This notice is issued when a UMPreceiver controller is created and isintended to warn of a potentiallyundesirable configuration setting. TheUMP store considers an explicit ACK forany sequence number as an implicit ACKfor all prior sequence numbers. Turningoff ordered_delivery in combination withexplicit ACKs has the potential toacknowledge messages which have notyet been received by the application.

Core-5688-3102: NOTICE: UME groupindex %uUMP has received an updatedtopic advertisement with an inconsistentUMP store group index. UMP recoversby ?flattening? the stores into a singlegroup.

Core-5688-3103: NOTICE: UME storehas out-of-range group index %u, settingto 0.

UMP has received an updated topicadvertisement specifying a store with agroup index which is greater than thenumber of advertised store groups. UMPrecovers by setting the group index forthe store in question to zero.

Core-5688-3104: NOTICE: settingcompatibility (UME <= 1.2) mode for UMEreceiver. Extended events will not bedelivered.

The UMP receiver controller creationlogic has detected a receiver utilizing anolder style (UMP version <= 1.2)registration callback function and turnsoff delivery of any extended UMPregistration events.

Core-5688-3105: Receiver Session IDspecified. Specified RegID will beignored

The system has detected that both areceiver Session ID and a receiver RegID have been specified either in theconfiguration file, via the configurationAPI or the RegID specification callback.

Specify only one of the Session ID or RegID.

Core-5688-3106: NOTICE: UME groupindex %uUMP has received an updatedtopic advertisement with an inconsistentUMP store group index. UMP recovers

110 Chapter 8: UM Log Messages

Message Description Resolution

by ?flattening? the stores into a singlegroup.

Core-5688-3107: NOTICE: UME storehas out-of-range group index %u, settingto 0.

UMP has received an updated topicadvertisement specifying a store with agroup index which is greater than thenumber of advertised store groups. UMPrecovers by setting the group index forthe store in question to zero.

Core-5688-3108: Receiver Session IDspecified. Specified RegID will beignored

The system has detected that both areceiver Session ID and a receiver RegID have been specified either in theconfiguration file, via the configurationAPI or the RegID specification callback.

Specify only one of the Session ID or RegID.

Core-5688-3117: WARNING: receivedPREG RESP with out-of-bounds StoreID

A registration response message wasreceived from a store but the store ID inthe message was invalid. The responseis discarded.

Core-5688-3118: WARNING: receivedPREG RESP with unused StoreID

A registration response message wasreceived from a store, but the source isnot registered to that store.

Check the source log for moreinformation. Source may have restarted

Core-5688-3122: NOTICE: 1.2 UMEstore in use, turning off ACK to source

For compatibility, UMP will automaticallyturn off sending ACKs to sources when aV1.x UMP store is used.

Core-5688-3156: NOTICE: settingcompatibility (UME <= 1.2) mode for UMEsource. Extended events will not bedelivered.

UMP will tell you when it is settingcompatibility to UMP <= 1.2 mode forUMP sources. When this setting is ineffect, no extended events will not bedelivered.

Core-5688-3157: NOTICE:ume_message_stability_notification notset. Setting for compatibility.

UMP will automatically set theume_message_stability_notificationconfiguration option if it is not specified.Check the configuration guide for moreinformation.

Core-5688-3160: WARNING: UMEsource for topic "%s" store state ignored(not in initial state)

UME source is not in the expected state(initial state) when registration is inprogress. No sequence numberadjustment will be performed in thiscase.

Core-5688-3165: WARNING: receivedkeepalive without StoreID set

A UMP Source received a keep alivepacket from a store without a Store ID inthe packet.

Core-5688-3166: WARNING: receivedkeepalive with out-of-bounds StoreID%uA UMP Source received a keep alivepacket from a store that has an out ofrange Store ID.

UM Core Log Messages 111

Message Description Resolution

Core-5688-3167: WARNING: receivedkeepalive from non-active store %u

A UMP Source received a keep alivepacket from a non registered store. Thismay happen if a source did notsuccessfully register with the particularstore in question.

Core-5688-3168: WARNING: receivedkeepalive from store %u with incorrectRegID %u

A UMP Source received a keep alivepacket from a store that has an invalidregister ID.

Core-5688-3169: NOTICE: store %u:%s:%u reports it has not received TIR.Possible misconfiguration?

The UMP store reported it has not yetreceived a TIR (topic advertisement) for atopic which already has one or moreregistered sources. UMP registrationhappens via a different mechanism thantopic resolution, and is sometimes a bitfaster. Registration allows the source tobegin sending, but the store does notactually begin listening for messagesuntil it receives a topic advertisementfrom the source and sets up receivers forthe appropriate topics. In that briefinterval, the store will send these noticesto the source, just in case you actually didforget to configure the store to listen tothe correct topic resolution channel.Once the store receives a topic resolutionadvertisement and begins listening to thetopic, the store will perform a Late Joinrecovery if the source has already startedsending, and should be able to catch upunless you have changed your source'stransmission window to a small value (bydefault, a source keeps 24 MB of data forretransmission).Our recommendeddelay before sending should prevent youfrom seeing this notice most of the time,but you may occasionally see it duringstore failover.

Core-5688-3170: WARNING: receivedACK with out-of-bounds StoreID %uAUMP Source received anacknowledgment packet with a store thatis not within the range of Store IDs. Thisshould not happen and is not a seriouscondition.

Core-5688-3171: WARNING: receivedACK from non-active store %u

UMP received ACK from non-activestore, this is not a serious conditionunless it happens frequently andmessaging is affected.

Core-5688-3172: WARNING: receivedstability %s ACK without StoreID set

UMP received stability ACK or NACKwithout StoreID set, this is not a seriouscondition unless it happens frequentlyand messaging is affected.

112 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-3173: source "%s" receivedCDELV without ACK ID set

Source received a delivery confirmationwithout the required identifier for thereceiver.

This may indicate corrupted packets,check the system for network errors.

Core-5688-3178: WARNING: too manyUME stores specified for topic resolution(max %u)

Too many stores were specified whencreating a source. Reduce the number ofstores when setting the ume_storeconfiguration option. Check theconfiguration guide for more information.

Core-5688-3185: WARNING: too manyUME store groups specified for topicresolution (max %u)

Too many store groups were specifiedwhen creating a source. Reduce thenumber of store groups when setting theume_store_group configuration option.Check the configuration guide for moreinformation.

Core-5688-3193: WARNING: too manyUME stores specified for topic resolution(max %u)

Too many stores were specified whencreating a source. Reduce the number ofstores when setting the ume_storeconfiguration option. Check theconfiguration guide for more information.

Core-5688-3228: WARNING: socketreuseaddr and socket exclusiveaddr setat the same time

The configuration options*_tcp_reuseaddr and*_tcp_exclusiveaddr (Windows only) cannot be used at the same time. Pleasecheck your configuration settings.

Core-5688-3234: WARNING: could notcreate TCP connection socket: %s

An error was returned from the OS whiletrying to create a socket (TCP). Pleaserefer to the OS error number andmessage given after the UMS message"could not create TCP connectionsocket".

Core-5688-3236: WARNING: could notset nonblock on TCP connection socket:%s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on TCPconnection socket".

Core-5688-3238: WARNING: could notset nonblock on TCP connection socket:%s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on TCPconnection socket".

Core-5688-3240: WARNING: could notbind, port %d, on TCP connection socket:%s

An error was returned from the OS whiletrying to bind the socket to the given port.Please refer to the OS error number andmessage given after the UMS message"could not bind, port xxxxx, on TCPconnection socket".

UM Core Log Messages 113

Message Description Resolution

Core-5688-3244: WARNING: could notset SO_KEEPALIVE on TCP connectionsocket: %s

SO_KEEPALIVE was requested on thereceiver end of TCP connection, but wasnot able to be set on the socket. Thiscould be because the OS is not Windowsor Linux, or because there was an error inthe OS system call to set the socketoptions.

Core-5688-3245: WARNING: could notconnect on TCP connection socket: %s

An error was returned from the OS whiletrying to connect to the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not connect on TCP connectionsocket".

Core-5688-3247: WARNING: could notconnect on TCP connection socket: %s

An error was returned from the OS whiletrying to connect to the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not connect on TCP connectionsocket".

Core-5688-3263: WARNING: could notset SO_REUSEADDR on multicastreceive socket: %s

An error was returned from the OS whiletrying to set the socket optionSO_REUSEADDR per the*_tcp_reuseaddr configurationparameter. Please refer to the OS errornumber and message given after theUMS message "could not setSO_REUSEADDR on multicast receivesocket".

Core-5688-3265: WARNING: could notset SO_REUSEPORT on multicastreceive socket: %s

An error was returned from the OS whiletrying to set the socket optionSO_REUSEPORT per the*_tcp_reuseaddr configurationparameter. Please refer to the OS errornumber and message given after theUMS message "could not setSO_REUSEPORT on multicast receivesocket".

Core-5688-3269: WARNING: could notIP_ADD_MEMBERSHIP on multicastreceive socket: %s

An error was returned from the OS whiletrying to set the socket optionIP_ADD_MEMBERSHIP. Please refer tothe OS error number and message givenafter the UMS message "could notIP_ADD_MEMBERSHIP on multicastreceive socket".

Core-5688-3271: WARNING: could notset nonblock on multicast receive socket:%s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on multicastreceive socket".

114 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-3272: WARNING: could notset nonblock on multicast receive socket:%s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on multicastreceive socket".

Core-5688-3273: WARNING: could notset multicast SO_RCVBUF to requestedvalue %u

An error was returned from the OS whiletrying to set the socket optionSO_RCVBUF per the*_receiver_socket_buffer configurationparameter. The requested buffer size hasnot been set. Please refer to theconfiguration guide for instructions aboutchanging the OS limits.

Core-5688-3274: INFO: mcast rcv couldonly get SO_RCVBUF %u (desired %u)

The OS has set the socket optionSO_RCVBUF but not to the valuespecified per the*_receiver_socket_buffer configurationparameter. The actual and desiredvalues are given in the message. Pleaserefer to the configuration guide forinstructions about changing the OSlimits.

Core-5688-3284: WARNING: could notget address on dbl unicast rcv socket:%s

An error occurred while creating a DBLsocket. This may prevent the receiverfrom proceeding. Contact Informaticasupport for more details.

Core-5688-3289: WARNING: could notset multicast SO_RCVBUF to requestedvalue %u

An error was returned from the OS whiletrying to set the socket optionSO_RCVBUF per the*_receiver_socket_buffer configurationparameter. The requested buffer size hasnot been set. Please refer to theconfiguration guide for instructions aboutchanging the OS limits.

Core-5688-3292: WARNING: could notfind open unicast port in range [%d-%d]on dbl unicast bidir socket: %s

Could not bind a port in the specifiedrange. The range may need to beexpanded or moved to a range whereless ports are in use.

Core-5688-3294: WARNING: could notbind, port %d, on dbl unicast bidir socket:%s

An error occurred while creating a DBLsocket. This may prevent the receiverfrom proceeding. Contact Informaticasupport for more details.

Core-5688-3296: WARNING: could notget address on dbl unicast bidir socket:%s

An error occurred while creating a DBLsocket. This may prevent the receiverfrom proceeding. Contact Informaticasupport for more details.

UM Core Log Messages 115

Message Description Resolution

Core-5688-3298: WARNING: could notcreate unicast bidir socket: %s

An error was returned from the OS whiletrying to create a socket (UDP). Pleaserefer to the OS error number andmessage given after the UMS message"could not create unicast bidir socket".

Core-5688-3300: WARNING: could notfind open unicast port in range [%d-%d]on unicast bidir socket: %s

There are no ports available in the givenrange. Use *_port_low and/or*_port_high configuration parameters tospecify a different range of ports to use.

Core-5688-3302: WARNING: could notbind, port %d, on unicast bidir socket:%s

An error was returned from the OS whiletrying to bind the socket to the given port.Please refer to the OS error number andmessage given after the UMS message"could not bind, port xxxxx, on unicastbidir socket".

Core-5688-3304: WARNING: could notgetsockname on unicast bidir socket: %s

An error was returned from the OS whiletrying to get the socket name. Pleaserefer to the OS error number andmessage given after the UMS message"could not getsockname on unicast bidirsocket".

Core-5688-3306: WARNING: could notset nonblock on unicast bidir socket: %s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on unicast bidirsocket".

Core-5688-3307: WARNING: could notset nonblock on unicast bidir socket: %s

An error was returned from the OS whiletrying to set the O_NONBLOCK andO_NDELAY flags on the socket. Pleaserefer to the OS error number andmessage given after the UMS message"could not set nonblock on unicast bidirsocket".

Core-5688-3308: WARNING: could notset bidir SO_RCVBUF to requested value%u

An error was returned from the OS whiletrying to set the socket optionSO_RCVBUF per the*_receiver_socket_buffer configurationparameter. The requested buffer size hasnot been set. Please refer to theconfiguration guide for instructions aboutchanging the OS limits.

Core-5688-3309: INFO: ucast bidir couldonly get SO_RCVBUF %u (desired %u)

The OS has set the socket optionSO_RCVBUF but not to the valuespecified per the*_receiver_socket_buffer configurationparameter. The actual and desiredvalues are given in the message. Pleaserefer to the configuration guide for

116 Chapter 8: UM Log Messages

Message Description Resolution

instructions about changing the OSlimits.

Core-5688-3330: lbm_socket_send: msgdropped (EWOULDBLOCK): adjust ratelimit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3331: lbm_socket_send: msgdropped (EWOULDBLOCK): adjust ratelimit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3335: lbm_socket_sendb:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3336: lbm_socket_sendb:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

UM Core Log Messages 117

Message Description Resolution

Core-5688-3340: lbm_socket_sendtob:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3341: lbm_socket_sendtob:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3345: lbm_socket_sendbv:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3346: lbm_socket_sendbv:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3351: lbm_socket_sendtobv:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configuration

118 Chapter 8: UM Log Messages

Message Description Resolution

parameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3352: lbm_socket_sendtobv:msg dropped (EWOULDBLOCK): adjustrate limit or buffers

The combination of the *_data_rate_limitand *_rate_interval configurationparameters are used to determine theamount of data that will be sent at eachinterval. If that amount exceeds theconfigured *_socket_buffer setting, eachinterval may experience anEWOULDBLOCK status from the OS dueto the fact that the data does not fit intothe OS buffer allocated. Theconfiguration settings should bereviewed should this message be seenoften.

Core-5688-3365: NOTICE: wincportcomp routine, invalid op

I/O operation completed on deletedconnection. Can ignore unless happensmany times per hour.

Core-5688-3368: NOTICE: WSASendToerror [send_pending %d]: %s

I/O operation could not be started due tosocket error. Can ignore unless happensmany times per hour.

Core-5688-3370: WARNING:lbm_sock_delete acc_conn has unknownoptype %d

An unexpected I/O operation wasreceived while deleting a connection.Only occurs when using Windowscompletion ports. Contact Informaticasupport if this message occursfrequently.

Core-5688-3377: LBMR Version 0x%xincorrect (%s:%d len %d). [%s].Dropping.

An LBMR packet was dropped becauseits version was invalid.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3378: LBMR packetmalformed. Dropping. Origin: %s:%d

An LBMR packet was dropped becauseits length did not match the length of thedata received.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3379: LBMR optlenmalformed. Dropping packet. Origin: %s:%d

An LBMR packet was dropped becauseits length did not match the length of thedata received.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3380: LBMR optlen total_lenmalformed. Dropping packet. Origin: %s:%d

An LBMR packet was dropped becauseits length did not match the length of thedata received.

Investigate the listed IP and port for anapplication generating spurious traffic.

UM Core Log Messages 119

Message Description Resolution

Core-5688-3383: LBMR option invalidtype [%u]. Dropping packet. Origin: %s:%d

An LBMR packet was dropped becauseof an invalid option type.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3384: LBMR Type 0x%xincorrect (%s:%d len %d). [%s].Dropping.

An LBMR packet was dropped due to aninvalid type.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3385: LBMR Topic QueryRecord malformed. Dropping remainder.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3386: LBMR Topic InfoRecord malformed. Dropping remainder.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5688-3387: LBMR Extended Type0x%x incorrect (%s:%d len %d). [%s].Dropping.

LBM resolver has encountered anunknown extended type and dropped thepacket. Each type is reported only onceper resolver.

Can be caused by mixed versionssharing a topic resolution address ormalformed/forged packets.

Core-5688-3388: LBMR Topic InfoRecord Option not Length. Droppingremainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3389: LBMR Topic InfoRecord Length Option not correct size.Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3390: LBMR Topic InfoRecord Total Length not large enough.Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3391: LBMR Topic InfoRecord UME Option not correct size.Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3392: LBMR Topic InfoRecord Late Join Option not correct size.Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder of

120 Chapter 8: UM Log Messages

Message Description Resolution

the message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3393: LBMR Topic InfoRecord UME Store Option not correctsize. Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3394: LBMR Topic InfoRecord UME Store Group Option notcorrect size. Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3397: LBMR Topic InfoRecord Option not understood and doesnot have ignore. Dropping remainder.

UMS received a message with a headerthat was not recognized. This header andthe rest of the message will be ignored.This is potentially due to a newer versionof software sending messages and is notharmful. Contact Informatica support ifthis message occurs frequently or whenonly one version of Informatica softwareis being used.

Core-5688-3398: LBMR Topic InfoRecord Option length incongruent.Dropping remainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3400: LBMR Topic MgmtRecord Length not correct size. Droppingremainder.

UMS encountered a mismatch in thelength of a received message and itsheaders, determining the rest of themessage to be invalid. The remainder ofthe message is dropped. ContactInformatica support if this messageoccurs frequently.

Core-5688-3401: WARNING: could notundefine topic from topic map whendeleting

Warning: UMS could not remove a topicfrom topic map. Contact Informaticasupport if this message occursfrequently.

Core-5688-3402: LBMR WC TQRpcre_compile [%s] malformed [%d][%s].Dropping.

UMS detected a malformed PCREpattern for a wild card receiver, it will dropthe Topic Query Response. ContactInformatica support if this messageoccurs frequently or if topic resolutionappears to be failing.

UM Core Log Messages 121

Message Description Resolution

Core-5688-3403: LBMR WC TQRregcomp [%s] malformed [%s].Dropping.

In topic resolution process, UMSdetected a malformed registrationcomplete signal for a wild card receiver, itwill drop the Topic Query Response.Contact Informatica support if thismessage occurs frequently or if topicresolution appears to be failing.

Core-5688-3404: LBMR WC TQR Type0x%x [%s] not understood. Dropping.

In topic resolution process, UMSdetected a malformed type for a wild cardreceiver, it will drop the Topic QueryResponse. Contact Informatica support ifthis message occurs frequently or if topicresolution appears to be failing.

Core-5688-3405: LBMR WC TQRpcre_exec [%s][%s][%d] error %d

UMS detected a malformed PCREpattern for a wild card receiver duringtopic resolution. It will drop the TopicQuery Response. This is not a seriouscondition unless it happens frequentlyand the resolution process is affected.

Core-5688-3415: message receiverfunction returned -1

An error occurred processing a messagereceived by a receiver. The receiver'sdelivery controller was unable to pass themessage to the application. Themessage was discarded. Please contactInformatica if this message occursfrequently.

Core-5688-3426: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtrm_nak_backoff_interval[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtrm_nak_backoff_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3427: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtrm_nak_suppress_interval[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtrm_nak_suppress_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3428: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtrm_nak_generation_interval [%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtrm_nak_generation_interval setting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

122 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-3429: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtrm_preactivity_timeout[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtrm_preactivity_timeoutsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3430: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtrm_activity_timeout [%d]than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtrm_activity_timeout setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-3431: WARNING: Joiningsession [%s] which exists and uses adifferent transport_lbtrm_send_naks[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea different transport_lbtrm_send_nakssetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3433: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtru_nak_suppress_interval[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtru_nak_suppress_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3434: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtru_nak_generation_interval[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtru_nak_generation_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-5688-3435: WARNING: Joiningsession [%s] which exists and uses adifferent transport_lbtru_activity_timeout[%d] than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtru_activity_timeout setting.Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-3439: WARNING: Joiningsession [%s] which exists and uses adifferenttransport_lbtipc_activity_timeout [%d]than requested [%d].

Once a receiver has created a transportsession a subsequent receiver joining thesame transport session cannot configurea differenttransport_lbtipc_activity_timeout setting.

UM Core Log Messages 123

Message Description Resolution

Please refer to UMS Objects section ofthe Design Concepts in thedocumentation.

Core-5688-3541: PCRE exec [%s][%s][%d] error %d

An error occurred while trying to matchthe pattern listed in the first bracketedexpression. The topic string attempting tobe matched is supplied as the secondbracketed expression, and its length issupplied as the third bracketedexpression. The error that occurred wasinternal to PCRE, and the error code islisted in the PCRE documentation forreturn values of pcre_exec.

Core-5688-3546: LBMR WC TQRpcre_compile [%s] malformed [%d][%s].Dropping.

UMS detected a malformed PCREpattern for a wild card receiver, it will dropthe Topic Query Response. ContactInformatica support if this messageoccurs frequently or if topic resolutionappears to be failing.

Core-5688-3547: LBMR WC TQRregcomp [%s] malformed [%s].Dropping.

In topic resolution process, UMSdetected a malformed registrationcomplete signal for a wild card receiver, itwill drop the Topic Query Response.Contact Informatica support if thismessage occurs frequently or if topicresolution appears to be failing.

Core-5688-3548: LBMR WC TQR Type0x%x [%s] not understood. Dropping.

In topic resolution process, UMSdetected a malformed type for a wild cardreceiver, it will drop the Topic QueryResponse. Contact Informatica support ifthis message occurs frequently or if topicresolution appears to be failing.

Core-5688-3549: LBMR WC Cachepcre_exec [%s][%s][%d] error %d

An error occurred while trying to matchthe pattern listed in the first bracketedexpression. The topic string attempting tobe matched is supplied as the secondbracketed expression, and its length issupplied as the third bracketedexpression. The error that occurred wasinternal to PCRE, and the error code islisted in the PCRE documentation forreturn values of pcre_exec.

Core-5688-3555: wildcard messagereceiver function returned -1

The callback configured for wildcardreceiver messages returned -1 whileprocessing an immediate message.

Core-5688-3691: Sending request withrequest port binding disabled.

An lbm request is being sent, but therequest port used to receive responses isdisabled via therequest_tcp_bind_request_port(context) configuration option. See the

124 Chapter 8: UM Log Messages

Message Description Resolution

documentation for this configurationoption for more information.

Core-5688-3698: Response for requestquery index %u received. No requestknown.

A response was received that does notcorrespond to an existing request. Thisusually indicates that the responder tooktoo long to respond, and the requestorhad already deleted the request objectwhen the response was received.

Core-5688-3701: Response for requestquery index %u received. No requestknown.

A response was received that does notcorrespond to an existing request. Thisusually indicates that the responder tooktoo long to respond, and the requestorhad already deleted the request objectwhen the response was received.

Core-5688-3702: WARNING: deletiontimeout from %s:%u while sendingresponse or UIM

A response or a unicast immediatemessage was still being sent when thecorresponding TCP connection closed.Please contact Informatica support if thisoccurs.

Core-5688-3723: Sending unicastimmediate request with request portbinding disabled.

An lbm request is being sent via unicastimmediate messaging, but the requestport used to receive responses isdisabled via therequest_tcp_bind_request_port(context) configuration option. See thedocumentation for this configurationoption for more information.

Core-5688-3762: unknown fd_to_beaction %d

Internal error while handling socket;probable memory corruption. Shouldnever happen. Contact Informaticasupport.

Core-5688-3773: epoll_ctl: Tried toregister a bad file descriptor

The fd_management_type is set to epolland either the user tried to register a non-socket file descriptor or a socket that wasregistered unexpectedly became invalidbetween creating the file descriptor andregistering it. Linux's epoll currently onlysupports socket file descriptors, and notnormal files or other file descriptor types.This warning should be very rare; if it ishappening frequently, please contactInformatica.

Core-5688-3774: epoll_ctl: Tried toperform an operation on a socket that isalready closed

The fd_management_type is set to epolland file descriptor registration wasattempted for a socket that was alreadyclosed. This can sometimes happen if asocket is closed immediately after it iscreated, but before it is registered. Thiswarning should be very rare; if it ishappening frequently, please contactInformatica.

UM Core Log Messages 125

Message Description Resolution

Core-5688-3777: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3781: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3782: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3786: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3793: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3794: %s:%d: sock=%p,sock->sock=%p, handle=%p,io_pending=%d, op_recv=%p,op_acc_conn=%p

Pre-assert data: a message whichcontains selected internal stateinformation useful for diagnosing thecause of certain failed assertions. Shouldnot happen during normal operation.

Core-5688-3804: kevent fatal error: (%d)%s

When using the kqueue file descriptormanagement type on Mac OS X, anunexpected error was returned from thekevent system call. This could be causedby a variety of reasons, including beingout of memory, or trying to register aninvalid file descriptor, or accessingmemory incorrectly.

Core-5688-3805: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

Core-5688-3806: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

126 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-3807: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

Core-5688-3808: Dropping cancelledread, accept, or close event on handle%d

A read, accept, or close event occurredon the indicated file descriptor (handle),but the user's registered read, accept, orclose event callback was cancelledimmediately before the event happened.

Core-5688-3809: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

Core-5688-3810: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3811: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

Core-5688-3812: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3813: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

UM Core Log Messages 127

Message Description Resolution

Core-5688-3815: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

Core-5688-3816: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3817: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

Core-5688-3818: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3819: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

Core-5688-3820: Dropping cancelledread, accept, or close event on handle%d

A read, accept, or close event occurredon the indicated file descriptor (handle),but the user's registered read, accept, orclose event callback was cancelledimmediately before the event happened.

Core-5688-3821: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

128 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-3822: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3823: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

Core-5688-3824: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3825: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

Core-5688-3826: Dropping cancelledread, accept, or close event on handle%d

A read, accept, or close event occurredon the indicated file descriptor (handle),but the user's registered read, accept, orclose event callback was cancelledimmediately before the event happened.

Core-5688-3827: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

Core-5688-3828: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3831: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

UM Core Log Messages 129

Message Description Resolution

Core-5688-3832: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3833: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

Core-5688-3835: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

Core-5688-3836: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3838: NOTICE: wincport %presults [%d] (%d,%d,%p,%p) op %x

Internal error handling descriptors;probable timing race condition. Shouldnever happen. Please contactInformatica support.

Core-5688-3847: NOTICE: wincport %pline %d WSA err %d, %s (peer %s) (op%x)

A Windows Completion port operationended with a failure.

Examine the reported WSA Error codeand take the appropriate action.

Core-5688-3849: lbm_fd_handle_eventsline %d: wincport recv WSA err %d (%s)from peer %s

The Windows completion port call to recvreturned an error.

Look up the WSA error and takeappropriate action.

Core-5688-3864: NOTICE: wincport %presults [%d] (%d,%d,%p,%p) op %x

Internal error handling descriptors;probable timing race condition. Shouldnever happen. Please contactInformatica support.

Core-5688-3883: mapentry->exceptcbwas NULL

A registered file descriptor had anexception event, but the registeredexception callback was NULL. This canhappen if the file descriptor had a write,

130 Chapter 8: UM Log Messages

Message Description Resolution

connect, read, accept, or close event atabout the same time, and the filedescriptor's exception callback wascancelled within any of its othercallbacks. This warning is usuallyharmless, but may indicate improperapplication design.

Core-5688-3884: Dropping cancelledexcept event on handle %d

An exception event occurred on theindicated file descriptor (handle), but theuser's registered exception eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3885: mapentry->writecbwas NULL

A registered file descriptor had a write orconnect event, but the registeredcallback was NULL. This should neverhappen, and indicates possibleapplication memory corruption.

Core-5688-3886: Dropping cancelledwrite or connect event on handle %d

A write or connect event occurred on theindicated file descriptor (handle), but theuser's registered write or connect eventcallback was cancelled immediatelybefore the event happened.

Core-5688-3887: mapentry->readcb wasNULL

A registered file descriptor had a read,accept, or close event, but the registeredcallback was NULL. This can happen ifthe file descriptor had a write or connectevent at about the same time, and theread, accept, or close event callback wascancelled for that file descriptor within itswrite or connect event callback. Thiswarning is usually harmless, but mayindicate improper application design.

Core-5688-3888: Dropping cancelledread, accept, or close event on handle%d

A read, accept, or close event occurredon the indicated file descriptor (handle),but the user's registered read, accept, orclose event callback was cancelledimmediately before the event happened.

Core-5688-3889: kevent returned eventwith unknown or unsupported filter type

kevent returned a file descriptor with afilter type that was not EVFILT_READ orEVFILT_WRITE (such asEVFILT_SIGNAL, EVFILT_PROC, etc.).UMS does not register any filedescriptors for any filters other thanEVFILT_READ or EVFILT_WRITE, sothis is very unusual and might indicatememory corruption.

Core-5688-3890: handle events returnederror %u [%s]

Socket returned error while waiting forcontext deletion. Can ignore unlesshappens many times per hour.

UM Core Log Messages 131

Message Description Resolution

Core-5688-3896: wildcard messagereceiver function returned -1

The callback configured for wildcardreceiver messages returned -1 whileprocessing an immediate message.

Core-5688-3897: wildcard messagereceiver function returned -1

The callback configured for wildcardreceiver messages returned -1 whileprocessing an immediate message.

Core-5688-390: event dispatch -unknown event type (%d)

The event dispatch loop encountered anunexpected event type. This is probablydue to an unexpected network eventoccurring. Check the network is stable.Contact Informatica support if youencounter this message frequently.

Core-5688-3919: Sending multicastimmediate request with request portbinding disabled.

An lbm request is being sent via multicastimmediate messaging, but the requestport used to receive responses isdisabled via therequest_tcp_bind_request_port(context) configuration option. See thedocumentation for this configurationoption for more information.

Core-5688-3927: New unfraggedmessage in TCP buffer before firstmessage is complete.

Withtransport_tcp_multiple_receiver_behavior set to bounded_latency orsource_paced and old messages arebeing removed to make room for newmessages, the first (oldest) message isfragmented but is incomplete.Processing will continue anyway.

Core-5688-3928: New message in TCPbuffer before first message is complete.

Withtransport_tcp_multiple_receiver_behavior set to bounded_latency orsource_paced and old messages arebeing removed to make room for newmessages, the first (oldest) message isfragmented but is incomplete.Processing will continue anyway.

Core-5688-3929: No more messages inTCP buffer before old message iscomplete.

Withtransport_tcp_multiple_receiver_behavior set to bounded_latency orsource_paced and old messages arebeing removed to make room for newmessages, the message being removedis fragmented and only a portion of itcould be found and removed. Processingwill continue anyway.

Core-5688-3930: New unfraggedmessage in TCP buffer before oldfragged message is complete.

Withtransport_tcp_multiple_receiver_behavior set to bounded_latency orsource_paced and old messages arebeing removed to make room for newmessages, the message being removed

132 Chapter 8: UM Log Messages

Message Description Resolution

is fragmented and only a portion of itcould be found and removed. Processingwill continue anyway.

Core-5688-3931: New message in TCPbuffer before old message is complete.

Withtransport_tcp_multiple_receiver_behavior set to bounded_latency orsource_paced and old messages arebeing removed to make room for newmessages, the message being removedis fragmented and only a portion of itcould be found and removed. Processingwill continue anyway.

Core-5688-3986: PCRE exec [%s][%s][%d] error %d

An error occurred while trying to matchthe pattern listed in the first bracketedexpression. The topic string attempting tobe matched is supplied as the secondbracketed expression, and its length issupplied as the third bracketedexpression. The error that occurred wasinternal to PCRE, and the error code islisted in the PCRE documentation forreturn values of pcre_exec.

Core-5688-4082: error parsing XML (setvia UMM)

The XML configuration received fromUMM could not be parsed.

Previous error messages should containthe reason for the error. Correct theconfiguration in UMM and retry theapplication.

Core-5688-4083: error parsingapplication name '%s' (set via UMM)

The XML configuration for the applicationreceived from UMM could not be parsed.

Previous error messages should containthe reason for the error. Correct theconfiguration in UMM and retry theapplication.

Core-5688-4099: multiple interfacesmatch criteria - will use [%s][%s]

This warning occurs if an interface isspecified by name for any of the*_interface options, and multipleinterfaces on the host match the suppliedname. In this case the first matchinginterface will be used, however it isrecommended to specify interfaces suchthat only a single interface is matched.

Core-5688-410: failed to allocatehypertopic callback vector of %u bytes[%s:%d]

There was a memory allocation failurewhile creating the vector of callbacksassociated with a received messagedestined for a HyperTopic receiver. Thismeans that a message will not bedelivered to some subset of registeredHyperTopic receivers.

Core-5688-4100: multiple interfacesmatch criteria - will use [%s][%s]

This warning occurs if an interface isspecified by name for any of the*_interface options, and multipleinterfaces on the host match the suppliedname. In this case the first matchinginterface will be used, however it is

UM Core Log Messages 133

Message Description Resolution

recommended to specify interfaces suchthat only a single interface is matched.

Core-5688-4103: multiple interfacesmatch criteria - will use [%s][%s]

This warning occurs if an interface isspecified by name for any of the*_interface options, and multipleinterfaces on the host match the suppliedname. In this case the first matchinginterface will be used, however it isrecommended to specify interfaces suchthat only a single interface is matched.

Core-5688-4104: multiple interfacesmatch criteria - will use [%s][%s]

This warning occurs if an interface isspecified by name for any of the*_interface options, and multipleinterfaces on the host match the suppliedname. In this case the first matchinginterface will be used, however it isrecommended to specify interfaces suchthat only a single interface is matched.

Core-5688-4106: WARNING: could notscan IPv4 interfaces.

As UMS initializes, it scans all thenetwork cards in the system. This scaneither failed due to a lack of availableresources. For example, this might bebecause there are no network cards thatare active or the system has run out ofsockets. Check the system availability ofnetwork resources. Contact Informaticasupport if all resources appear to beavailable.

Core-5688-4107: WARNING: could notfind a multicast capable, non-loopbackinterface.

As UMS initializes, it scans all thenetwork cards in the system. If nonetwork card is listed as supportingmulticast capabilities, this warning isproduced. Check your network cardcapabilities and configuration.

Core-5688-4108: WARNING: using firstbroadcast capable interface instead.

As UMS initializes, it scans all thenetwork cards in the system. No multicastcapable card was found, but a broadcastcapable card was found. The firstbroadcast capable card will be used.Check your network card configuration ifyou expect one of the network cards to bemulticast capable.

Core-5688-434: received read indicationon daemon connection - unknownsocket

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

Core-5688-436: daemon control datareceived in unknown state %d

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

134 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-438: daemon control datareceived in unknown state %d

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

Core-5688-439: invalid action responseon control channel [%s]

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

Core-5688-440: invalid topicname oncontrol channel [%s]

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

Core-5688-441: invalid action responseon control channel [%s]

This message is used for internalpurpose. Please contact Informaticasupport team if you encounter thismessage.

Core-5688-448: LBMC datagrammalformed, msglen 0. Dropping.

UMS received a message with the lengthfield set to 0. The message will bedropped. Contact Informatica support ifthis message occurs frequently.

Core-5688-450: LBMC version incorrect(%u). Dropping. Origin: %s:%d.

The LBMC version value in the receivedmessage is either corrupted or notsupported by the UM product receivingmessages.

Find the LBMC version value of thereceived message in the log line startingwith Core-5688-450 and check if it issupported in the product you are using.

Core-5688-542: received ACK forunknown source

UMS received ACK for unknown source.This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-5688-58: loading default config filefailed: %s

Loading the config file specified with theLBM_DEFAULT_CONFIG_FILEenvironment variable failed, due to eithera missing file, inappropriate accessprivileges, or an error in the config fileitself.

Core-5688-587: WARNING:transport_lbtrm_activity_timeout [%d] isless thantransport_lbtrm_nak_generation_interval [%d], this can result in silent data loss ifloss occurs within the activity timeoutinterval prior to the end of the transportsession.

If the transport_lbtrm_activity_timeout isless than thetransport_lbtrm_nak_generation_interval it is possible that a receiver can teardown the transport session before it wasable to send a NAK for a lost message.When this happens the message isunrecoverable.

Core-5688-593: IPC Error: CreatingReceiver Signal Semaphore

An error occurred when an IPC receiverattempted to allocate a shared signalingsemaphore. This could be caused by apermission error or no more resources.

UM Core Log Messages 135

Message Description Resolution

Please refer to the documentation forlbtipc_resource_manager.

Core-5688-594: IPC Error: InitializingReceiver Signal Semaphore (%d)

An error occurred when an IPC receiverattempted to initialize a shared signalingsemaphore. Please refer to the OS errornumber given.

Core-5688-595: IPC Error: CreatingReceiver Monitor Semaphore

An error occurred when an IPC receiverattempted to allocate a sharedmonitoring semaphore. This could becaused by a permission error or no moreresources. Please refer to thedocumentation forlbtipc_resource_manager.

Core-5688-596: IPC Error: InitializingReceiver Monitor Semaphore (%d)

An error occurred when an IPC receiverattempted to initialize a sharedmonitoring semaphore. Please refer tothe OS error number given.

Core-5688-597: IPC Error: InitializingReceiver Monitor Semaphore (%d)

An error occurred when an IPC receiverattempted to initialize a sharedmonitoring semaphore. Please refer tothe OS error number given.

Core-5688-598: IPC Error: CreatingShared Event (%d) (%s)

An IPC receiver could not create a sharedEvent. This could be caused by apermission error or the resource alreadyexists. Please refer to the OS errornumber and resource name given.

Core-5688-599: IPC Error: CreatingReceiver Monitor Mutex (%d) (%s)

An IPC receiver could not create a sharedmonitoring Mutex. This could be causedby a permission error or the resourcealready exists. Please refer to the OSerror number and resource name given.

Core-5688-600: IPC Error: GettingReceiver Monitor Mutex (%d) (%s)

An IPC receiver could not acquire theshared monitoring Mutex. This could becaused by a permission error. Pleaserefer to the OS error number andresource name given.

Core-5688-601: lbtipc_rcv_create: cannot obtain transport information

An IPC receiver is attempting to join anIPC transport but can not obtain thetransport information from the IPCshared memory buffer. This couldhappen if the IPC transport has beendeleted before the receiver has joined.

Core-5688-602: IPC Error: Joiningtransport; no more free receiver slots

An IPC receiver is attempting to join anIPC transport that has no more free slotsfor receivers. Please adjust the"transport_lbtipc_maximum_receivers_per_transport" configuration attribute.

136 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-603: default thread stack sizeis perhaps too small, %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small. The size of the defaultstack size is dumped and will then be setto a larger size automatically.

Core-5688-604: reset thread stack sizeto %u bytes.

The IPC receiver has created a thread forinternal processing and the default stacksize is too small and is reallocated. Thismessage reports the new size of thestack.

Core-5688-605: IPC Error: CreatingReceiver Thread (%d)

An error occurred when the IPC receiverattempted to create a thread for internalprocessing. Please refer to the OS errornumber given.

Core-5688-614: LBT-IPC: failed to openshared memory (%d)

The IPC shared memory region could notbe opened for reading. This could occur ifa receiver attempts to join an IPCtransport after the source has beendeleted. Please reference the OS errornumber given.

Core-5688-615: LBT-IPC: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

Core-5688-617: LBT-IPC: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

Core-5688-618: LBT-IPC: can not openshared semaphore (%d)

The shared semaphore used to ensuremutual exclusion while accessing IPCshared resources could not be opened.This could occur if a receiver attempts tojoin an IPC transport after the source hasbeen deleted. Please refer to the OSerror number given.

Core-5688-619: LBT-IPC: failed to openshared memory (%d)

The IPC shared memory region could notbe opened for reading. This could occur ifa receiver attempts to join an IPCtransport after the source has beendeleted. Please reference the OS errornumber given.

Core-5688-620: LBT-IPC: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

Core-5688-622: LBT-IPC: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

UM Core Log Messages 137

Message Description Resolution

Core-5688-624: LBT-IPC: lockingproblem detected inlbtipc_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing IPC shared resources. Pleaserefer to the OS error number given.

Core-5688-625: LBT-IPC: lockingproblem detected inlbtipc_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing IPC shared resources. Pleaserefer to the OS error number given.

Core-5688-626: LBT-IPC: lockingproblem detected inlbtipc_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing IPC shared resources. Pleaserefer to the OS error number given.

Core-5688-627: LBT-IPC: lockingproblem detected inlbtipc_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing IPC shared resources. Pleaserefer to the OS error number given.

Core-5688-628:lbm_transport_lbtipc_ctlr_delete: WFSOres=%d, GLE=%d

The WaitForSingleObject() Windows callreturn an error while waiting for the IPCReceiver thread to exit. Please refer tothe response and OS error numbergiven.

Core-5688-630: LBTIPC: error mapping(initial) resource registry (%d)

An error occurred when attempting tomap memory to the registry file. Theregistry is used to store IPC sharedobjects that are in use. The OS errornumber is given.

Core-5688-632: LBTIPC: error initializingregistry semaphore (%d)

The semaphore used to ensure mutualexclusion while accessing the registrycould not be initialized. The registry isused to store IPC shared objects that arein use. Please refer to the documentationfor lbtipc_resource_manager.

Core-5688-633: LBTIPC: error openingresource registry (%d)

An error occurred when attempting toopen or map memory to the registry file.The OS error number is given.

Core-5688-635: LBTIPC: resourceregistry version mismatch: uselbtipc_resource_manager to clean-upand delete registry.

An IPC registry file existed, andcontained the wrong version.

For this to happen, a registry file withincorrect version information would haveto be deliberately put in place. 3.5 andpost3.5 use different naming schemes forregistries, so this can't happen due toversion mismatch.

Core-5688-636: LBTIPC: error re-mapping resource registry (entries: %d)(%d)

An error occurred when attempting to re-map memory to the registry file. Theregistry is used to store IPC sharedobjects that are in use. The size in entriesand OS error number is given.

138 Chapter 8: UM Log Messages

Message Description Resolution

Core-5688-637: LBTIPC: error opening.The semaphore used to ensure mutualexclusion while accessing the registrycould not be created. The registry is usedto store IPC shared objects that are inuse. The OS error number is given.

Core-5688-638: LBTIPC: errorreinitializing registry semaphore (%d)

The semaphore used to ensure mutualexclusion while accessing the registrycould not be initialized. The registry isused to store IPC shared objects that arein use. The OS error number is given.

Core-5688-639: LBTIPC: error re-creating resource registry (%d)

The registry used to store IPC sharedobjects that are in use could not becreated. The OS error number is given.

Core-5688-640: LBTIPC: error in re-sizing resource registry (%d)

The registry used to store IPC sharedobjects that are in use could not be re-sized (expanded). The OS error numberis given.

Core-5688-641: LBTIPC: error re-mapping resource registry (%d)

An error occurred when attempting to re-map memory to the registry file (fileexpansion). The registry is used to storeIPC shared objects that are in use. TheOS error number is given.

Core-5688-642: LBTIPC: No freesemaphores could be found

A free semaphore required for the LBT-IPC transport could not be found. Pleaserefer to the documentation forlbtipc_resource_manager.

Core-5688-644: LBTIPC: error openingsemaphore (%d)

A free semaphore allocated for the LBT-IPC transport could not be opened. TheOS error number is given.

Core-5688-645: LBTIPC: error freeingsemaphore; key 0x%x not found

A semaphore allocated for the LBT-IPCtransport could not be freed due to aninvalid internal key. Please contactInformatica support.

Core-5688-646: LBT-IPC unexpectedsend error

An attempt was made to transfer amessage or message fragment to the IPCshared memory buffer but that operationfailed. This is cause by a failure withtrying to obtain the lock for the sharedmemory buffer.

Core-5688-647: LBT-IPC failed to startstalled timer

The IPC source is blocked waiting for areceiver but received an error trying tostart the block check timer.

Core-5688-648: LBT-IPC failed to startstalled timer

The IPC source is blocked waiting for areceiver but received an error trying tostart the block check timer.

UM Core Log Messages 139

Message Description Resolution

Core-5688-649: LBT-IPC unexpectedsend error

An attempt was made to transfer amessage or message fragment to the IPCshared memory buffer but that operationfailed. This is cause by a failure withtrying to obtain the lock for the sharedmemory buffer.

Core-5688-650: LBT-IPC unexpectedsend error

An attempt was made to transfer amessage or message fragment to the IPCshared memory buffer but that operationfailed. This is cause by a failure withtrying to obtain the lock for the sharedmemory buffer.

Core-5688-651: LBT-IPC ProblemOpening Signal Semaphore (%d)

The IPC source has received aconnection request from an IPC receiverand has failed to open the sharedsignaling semaphore. This could happenif the connection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber given.

Core-5688-652: LBT-IPC ProblemOpening Event (%d)

The IPC source has received aconnection request from an IPC receiverand has failed to open the shared Event.This could happen if the connectionrequest is old and the receiver wasalready deleted or the source does nothave permission to open the object.Please reference the OS error numbergiven.

Core-5688-653: LBT-IPC ProblemOpening Monitor Semaphore (%d)

The IPC source has received aconnection request from an IPC receiverbut has failed to open the MonitoringSemaphore. This could happen if theconnection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber given.

Core-5688-654: LBT-IPC ProblemOpening Monitor Mutex (%d) (%s)

The IPC source has received aconnection request from an IPC receiverbut has failed to open the MonitoringMutex. This could happen if theconnection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber and object name given.

Core-5688-692: topic levelretransmission request index, %u, notfound

A unicast immediate message wasrequested for retransmission, but themessage was no longer stored. This may

140 Chapter 8: UM Log Messages

Message Description Resolution

result in unrecoverable loss beingreported at the receiving side.

Core-5688-694: received retransmitrequest for unknown source.

UMS received ACK for unknown source.This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-5688-696: received retransmitrequest for unknown source ip:port[%s:%d]

UMS received ACK for unknown source.This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(Source applications restarting etc)

Core-5688-697: received lji request forunknown source.

UMS received Late Join Requestmessage for unknown source. This is nota serious problem but indicates that thereis a mismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-5688-699: received lji request forunknown source.

UMS received Late Join Requestmessage for unknown source. This is nota serious problem but indicates that thereis a mismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-5688-701: received PREGresponse for unknown source.

Each topic created and registered by aUMP context has a unique topic index.The UMP registration response handlerfor this context has received a responsefor a topic index not contained in thecollection of sources currently beingprocessed by the context. This is not aserious condition unless it continues tooccur frequently and sources beinghandled by the context are not beingsuccessfully registered.

Core-5688-702: received PREGresponse for unknown source.

Each topic created and registered by aUMP context has a unique topic index.The UMP registration response handlerfor this context has received a responsefor a topic index not contained in thecollection of sources currently beingprocessed by the context. This is not aserious condition unless it continues tooccur frequently and sources beinghandled by the context are not beingsuccessfully registered.

UM Core Log Messages 141

Message Description Resolution

Core-5688-703: received PREGresponse for unknown receiver.

Each topic created and registered by aUMP context has a unique topic index.The UMP registration response handlerfor this context has received a responsefor a topic index not contained in thecollection of receivers currently beingprocessed by the context. This is not aserious condition unless it continues tooccur frequently and receivers beinghandled by the context are not beingsuccessfully registered.

Core-5688-705: received UMEKeepalive with unknown type %x

UMP received keepalive signal which thetype cannot be determined. This is not aserious problem unless it happensfrequently.

Core-5867-19: Message selector parsererror [%s]

An error was encountered parsing themessage selector set for a receiver

Ensure the receiver has a valid messageselector

Core-5867-20: Message selector parsererror [Unterminated string %s]

An error was encountered parsing themessage selector set for a receiver

Ensure the receiver has a valid messageselector

Core-5867-21: Message selector parsererror [Invalid character '%c']

An error was encountered parsing themessage selector set for a receiver

Ensure the receiver has a valid messageselector

Core-5867-22: Message selector parsererror [Error compiling pattern %s at offset%d: err %s]

An error was encountered parsing themessage selector set for a receiver

Ensure the receiver has a valid messageselector

Core-5867-23: Message selector parsererror [Error compiling pattern %s at offset%d: err %s]

An error was encountered parsing themessage selector set for a receiver

Ensure the receiver has a valid messageselector

Core-5872-1: LBMR Topic Info RecordTotal Length too large. Droppingremainder.

This error is logged if the options portionof the received TIR packet wouldoverflow the stack-allocated buffer.

This error indicates that packets witherroneous length fields are beingreceived by UM. This could be due toapplications sending to the incorrect IPand port, or by a malicious attack.

Core-5872-2: LBMR Queue Info RecordTotal Length too large. Droppingremainder.

This error is logged if the options portionof the received QIR packet wouldoverflow the stack-allocated buffer.

This error indicates that packets witherroneous length fields are beingreceived by UM. This could be due toapplications sending to the incorrect IPand port, or by a malicious attack.

Core-5894-1: lbm_timer_expire:Exceeded %d timer expirations in oneiteration

UM encountered a condition where thespecified number of timers were expiringat the same time. This is undesirable andindicates a CPU burst usage. To preventstarvation of network processing, sometimers are deferred for processing andnetwork processing is resumed. Alltimers are eventually processed with aminor delay - this is acceptablebehaviour. If this message occurs

Examine the configuration of this processto determine if there are timers likely tocoincide in their expirations or if there aremany sources created very quickly. Ifthere are, it is suggested that the timersor source creation are staggered.

142 Chapter 8: UM Log Messages

Message Description Resolution

frequently, contact Informatica supportfor further guidance.

Core-5894-2: lbm_timer_expire:Exceeded %d timer expirations in oneiteration

UM encountered a condition where thespecified number of timers were expiringat the same time. This is undesirable andindicates a CPU burst usage. To preventstarvation of network processing, sometimers are deferred for processing andnetwork processing is resumed. Alltimers are eventually processed with aminor delay - this is acceptablebehaviour. If this message occursfrequently, contact Informatica supportfor further guidance.

Examine the configuration of this processto determine if there are timers likely tocoincide in their expirations or if there aremany sources created very quickly. Ifthere are, it is suggested that the timersor source creation are staggered.

Core-5927-1: Couldn't establishimmediate message channel fordestination %s:%d

A connection could not be established tosend a unicast message.

Check the logs for previous messagesindicating the actual cause, usually asocket error of some kind.

Core-5935-1: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5935-2: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5935-3: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5935-4: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5935-5: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5935-6: LBMC header withmalformed length field. Dropping. Origin:%s:%d

An LBMC header was received with amalformed length field.

Check the originating IP and port forapplications sending malformed data.

Core-5936-1: LBMR optlen total_lenmalformed. Dropping packet. Origin: %s:%d

A topic resolution message was receivedwith a length field that did not match thedata received.

Inspect the originating IP and Port forapplications sending malformed topicresolution messages.

Core-5937-1: Invalid 0-length LBMRoption. Dropping packet. Origin: %s:%d

An LBMR packet was dropped becauseof a 0-length option field.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5937-2: LBMR Topic Query Recordmalformed. Dropping remainder. Origin:%s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

UM Core Log Messages 143

Message Description Resolution

Core-5937-3: LBMR Topic Info Recordmalformed. Dropping remainder. Origin:%s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5937-4: LBMR Topic ManagementRecord malformed. Dropping remainder.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5937-5: LBMR Topic ManagementRecord malformed. Dropping remainder.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-5937-6: LBMR Topic Info Recordoption length invalid. DroppingRemainder.

UMS encountered a malformed LBMRpacket and discarded it.

Core-5937-7: LBMR Queue Info Recordoption length invalid. Droppingremainder.

A QIR packet was received thatcontained a 0-length option record.

Core-5938-1: Header size is incorrect forheader type. Dropping. Origin: %s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-5938-2: Header size is incorrect forheader type. Dropping. Origin: %s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-5938-3: Received lbmc messagewith incorrect header length. Dropping.Origin: %s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-5975-50: LBMC Route InfoNeighbor header size incorrect.Dropping. Origin: %s:%d.

Route Info message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-5988-1: Attempting to Respond to aRequest from %s with port set to zero.

A response is being generated but theresponse port is zero so the data will notbe delivered to the requester.

This occurs when the requester disablesbinding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5988-2: Source Side Filteringrequest from [%s] but response port setto zero. No messages will be receivedfrom this source.

The receiver is registering Source SideFiltering interest but the source responseport is zero. The interest will not arrive atthe source and therefore will not send thisreceiver any messages.

This occurs when the source disablesbinding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5988-3: Topic Advertisement [%s]contains UME Store info from %s but portis set to zero. Ignoring invalid UME StoreInfo.

A Topic Advertisement was received withUME Information but the store port waszero. The UME Information is beingignored.

This occurs when the Source or Storedisables binding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5988-4: Topic Advertisement [%s]contains UME Source Info from %s butport is set to zero. Ignoring invalid UMESource Info.

A Topic Advertisement was received withUME Information but the source port waszero. The UME Information is beingignored.

This occurs when the Source or Storedisables binding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

144 Chapter 8: UM Log Messages

Message Description Resolution

Core-5988-5: Topic Advertisement [%s]contains Late Join from %s but port is setto zero. Ignoring invalid Late Join setup.

A Topic Advertisement was received withLate Join Information but the source portwas zero. The Late Join Information isbeing ignored.

This occurs when the Source disablesbinding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5988-6: Topic Advertisement [%s]contains UME Store Info from %s but portis set to zero. Ignoring invalid UME StoreInfo.

A Topic Advertisement was received withUME Information but the store port waszero. The UME Information is beingignored.

This occurs when the Source or Storedisables binding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5988-7: Topic Advertisement [%s]contains ULB Info from %s but port is setto zero. Ignoring invalid ULB Info.

A Topic Advertisement was received withULB Information but the source port waszero. The UME Information is beingignored.

This occurs when the Source disablesbinding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-5990-1: UMQ command failedbecause the REQUIRED queueauthentication failed.. cmd_type=0x%x

warning the user credential is not correctfor authentication purpose

Core-6020-6: inflight bytes would benegative, resetting to 0

A call to decrement the number of inflightbytes would set it to be negative.

Nothing, it is forcibly set to 0 in thiscase.

Core-6020-7: inflight bytes would benegative, resetting to 0

Amount of bytes being decrementedwould cause inflight bytes to be negative

Current flight size could be incorrect dueto unknown reasons, use the set flightsize API to reset values

Core-6033-998: Requestedretransmission queue is too big [%lu]

The requested retransmission queuesize is too big

Consider reducing retransmission-request-processing-rate

Core-6033-999: malloc failure Malloc failure Box may be out of memory, considerreducing retransmission-request-processing-rate

Core-6036-1: LBMC stream corruptiondetected. Tearing down stream. Origin:%s:%d

Data was received in an inconsistentstate from an LBMC TCP stream.

Investigate the listed IP and port forapplications or network hardware thatmay be causing message corruption.

Core-6036-2: LBMC stream corruptiondetected. Tearing down stream. Origin:%s:%d

Data was received in an inconsistentstate from an LBMC TCP stream.

Investigate the listed IP and port forapplications or network hardware thatmay be causing message corruption.

Core-6056-1: Malformed fragmentheader detected, discarding.

A fragment header was detected with amalformed length field.

If this message is seen frequently, it mayindicate that network hardware iscorrupting packets, or that a program isgenerating spurious traffic directed at aport used by LBM.

Core-6190-1: LBMR TIR containedinconsistent transport information.

UM encountered an advertisementindicating a transport that was alreadyknown, but the OTID did not match theknown OTID.

The advertisement's originating IP andport will be logged in a subsequentmessage. Investigate that IP and port foran application generating spurioustraffic.

Core-6190-2: LBMR Topic Info Recordmalformed. Dropping remainder. Origin:%s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

UM Core Log Messages 145

Message Description Resolution

Core-6238-1: PCRE exec [%s][%s][%d]error %d

A receiver was configured with a invalidLIKE expression message selector

Fix the LIKE expression to be JMScompliant

Core-6238-2: PCRE compile [%s][%s]error %d

A receiver was configured with a invalidLIKE expression message selector

Fix the LIKE expression to be JMScompliant

Core-6259-1: Re-routing Domain ID %u:old: %s:%d new: %s:%d

There was a change in the route to thegiven host. This can happen at startup,when a Gateway goes down, or whenthere is connectivity problem.

This is normal on occasion. Persistentmessages could indicate a network orGateway issue.

Core-6259-10: LBMR Topic ResolutionRemote Domain Route packetmalformed (%d:%d). Dropping. Origin:%s:%d

LBMR Data received contain invaliddata.

Check the source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-11: Too many domains forrouting message %u; not sendingmessage.

With the given number of domains, adomain routing message cannot begenerated and traffic will not be routedproperly.

The customer can increase theresolver_datagram_max_size. However,this message indicates a suspiciouslylarge number of domains.

Core-6259-12: Failed sendingResponse: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-13: Failed sending UnicastBuffer: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-14: Failed sending UnicastBuffer: cannot find route to RemoteDomain: %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-15: Failed sending UnicastControl Message: cannot find route toRemote Domain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-16: Failed sending UnicastMessage: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-19: LBMC Topic Indexheader size incorrect. Dropping. Origin:%s:%d.

Topic Index message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-2: Route discovered toDomain ID %u through %s:%d

A new route to the given Domain ID wasdiscovered.

This is normal upon startup ofGateways.

146 Chapter 8: UM Log Messages

Message Description Resolution

Core-6259-20: Domain ID discovered;context resides in Domain ID %u

Log message indicates a Domain IDdiscovery.

This is not an error.

Core-6259-21: Failed sendingResponse: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-22: Failed sendingResponse: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-23: Failed sendingResponse: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-24: Failed sendingResponse: cannot find route to RemoteDomain %u (%s:%d)

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

This will be reported once per domain. A"route discovered to domain" shouldfollow soon after. If not, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-25: Deserialize Response:Context in domain %u received responsewith no domain: %s:%d

A context that knows it's domaindeserialized a response that containedno Domain ID. The response will likelynot get back to the sender. This couldhappen momentarily as an LBM contextslearn their domain routes at startup.

If the warning persists, the Gatewayconfiguration should be examined forinconsistencies.

Core-6259-26: Route discovered toDomain ID %u through %s:%d

A new route to the given Domain ID wasdiscovered.

This is normal upon startup ofGateways.

Core-6259-27: Unicast message arrivedat Gateway from Local Domain via directpath. Source: %s:%u

A Unicast Message arrived at a Gatewaydestined for the local Domain.

A user has likely unicast a messagedirectly to the Gateway. The user needsto Unicast the message to the finalapplication. UMS will take care of therouting.

Core-6259-28: Unicast message arrivedfrom Remote Domain (%u) via directpath. Source: %s:%u

A Unicast Message arrived with thedestination domain different that the localdomain (unicast direct).

A user has likely unicast a messagedirectly to an application in a differentdomain. If this is desired, either specify azero Domain ID or don't supply a DomainID. Using the local Domain ID will notsuffice.

Core-6259-29: Unicast message arrivedat Gateway from Local Domain via directpath. Source: %s:%u

A Unicast Message arrived at a Gatewaydestined for the local Domain.

A user has likely unicast a messagedirectly to the Gateway. The user needsto Unicast the message to the finalapplication. UMS will take care of therouting.

UM Core Log Messages 147

Message Description Resolution

Core-6259-3: LBMC DESTINATIONheader size incorrect. Dropping. Origin:%s:%d.

Destination message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-30: Unicast message arrivedfrom Remote Domain (%u) via directpath. Source: %s:%u

A Unicast Message arrived with thedestination domain different that the localdomain (unicast direct).

A user has likely unicast a messagedirectly to an application in a differentdomain. If this is desired, either specify azero Domain ID or don't supply a DomainID. Using the local Domain ID will notsuffice.

Core-6259-4: LBMC DESTINATIONheader size incorrect. Dropping. Origin:%s:%d.

Destination message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-6: LBMR Domain ID optioninvalid len [%u]. Dropping packet. Origin:%s:%d

LBMR Data received contain invaliddata.

Check the source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-7: Domain ID discovered;context resides in Domain ID %u

Log message indicates a Domain IDdiscovery.

This is not an error.

Core-6259-8: LBMR Domain ID optioncontains a mismatched domain [%u:%u].Dropping packet. Origin: %s:%d

LBMR Data received contain invaliddata.

Check the source (IP:Port) for possibleversion mismatch or service attack.

Core-6259-9: LBMR Topic ResolutionRemote Domain Route packetmalformed (%d:%d). Dropping. Origin:%s:%d

LBMR Data received contain invaliddata.

Check the source (IP:Port) for possibleversion mismatch or service attack.

Core-6322-1: received livenesskeepalive for unknown source.

UMS received a liveness keepalive for anunknown source. This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-10: ULB receiver indexreserve command response for unknownreceiver.

UMS received a ULB receiver indexreserve command response for anunknown receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-11: ULB index commandresponse error for unknown receiver.

UMS received a ULB index commandresponse error for an unknown receiver .This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

148 Chapter 8: UM Log Messages

Message Description Resolution

Core-6322-12: ULB index stopassignment command for unknownsource.

UMS received a ULB index stopassignment command for an unknownsource . This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-13: ULB index startassignment command for unknownsource.

UMS received a ULB index startassignment command for an unknownsource . This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-14: ULB index releasecommand for unknown source.

UMS received a ULB index releasecommand for an unknown source . This isnot a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-15: ULB index reservecommand for unknown source.

UMS received a ULB index reservecommand for an unknown source . This isnot a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-16: received ULB receiverregistration error response for unknownreceiver.

UMS received a ULB receiverregistration error response, but did notregister as a ULB receiver . This is not aserious problem but indicates that thereis a mismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-17: received ULB receiverregistration response for unknownreceiver.

UMS received a ULB receiverregistration response, but did not registeras a ULB receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-18: received ULB receiverde-registration response for unknownreceiver.

UMS received a ULB receiver de-registration response, but did not registeras a ULB receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

UM Core Log Messages 149

Message Description Resolution

Core-6322-19: received ULB RCR forunknown receiver.

UMS received a ULB RCR, but did notregister as a ULB receiver . This is not aserious problem but indicates that thereis a mismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-2: received ULB receiverregistration for unknown source.

UMS received a ULB receiverregistration, but was not configured as aULB source . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-20: received ULB unicastmessage for unknown receiver.

UMS received a ULB unicast message,but did not register as a ULB receiver .This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-21: received UMQ commandresponse for unknown command.

UMS received a UMQ commandresponse for an unknown command. Thisis not a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-22: received UMQ indexcommand response for unknowncommand.

UMS received a UMQ index commandresponse for an unknown command. Thisis not a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-23: received UMQregistration response, but did not registerwith a queue.

UMS received a UMQ registrationresponse, but did not register with aqueue . This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-24: received UMQ stabilityACK for unknown source.

UMS received a UMQ stability ACK for anunknown source . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

150 Chapter 8: UM Log Messages

Message Description Resolution

Core-6322-25: received UMQ RCR forunknown receiver.

UMS received a UMQ RCR for anunknown receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-26: received UMQ keepalivefor unknown client.

UMS received a UMQ keepalive for anunknown client . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-27: received ACK forunknown source.

UMS received ACK for unknown source.This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-3: received ULB receiver de-registration for unknown source.

UMS received a ULB receiver de-registration, but was not configured as aULB source . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-4: received ULB receiverACK for unknown source.

UMS received a ULB receiver ACK, butwas not configured as a ULB source .This is not a serious problem butindicates that there is a mismatchbetween this process and another. Checkthe system for other abnormal behaviour(applications restarting etc)

Core-6322-5: received ULB RXREQ forunknown source.

UMS received a ULB RXREQ, but wasnot configured as a ULB source . This isnot a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-6: received ULB keepalive orkeepalive response, but not using ULB

UMS received a ULB keepalive, but wasnot configured as a ULB source . This isnot a serious problem but indicates thatthere is a mismatch between this processand another. Check the system for otherabnormal behaviour (applicationsrestarting etc)

UM Core Log Messages 151

Message Description Resolution

Core-6322-7: ULB receiver index stopassignment command response forunknown receiver.

UMS received a ULB receiver index stopassignment command response for anunknown receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-8: ULB receiver index startassignment command response forunknown receiver.

UMS received a ULB receiver index startassignment command response for anunknown receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6322-9: ULB receiver index releasecommand response for unknownreceiver.

UMS received a ULB receiver indexrelease command response for anunknown receiver . This is not a seriousproblem but indicates that there is amismatch between this process andanother. Check the system for otherabnormal behaviour (applicationsrestarting etc)

Core-6340-1: Malformed config optoption encountered. Dropping. Origin:%s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-6340-2: Malformed config optoption encountered. Dropping. Origin:%s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-6340-3: Malformed config optoption encountered. Dropping. Origin:%s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-6340-4: Malformed config optoption encountered. Dropping. Origin:%s:%d.

A malformed LBMC header wasreceived.

Check the originating IP and port for anapplication sending incorrectly formedpackets.

Core-6361-125: received sri request forunknown source.

A context without a resolver module hasreceived an SRI REQ.

This could be caused if a transportthread's is reusing a previous context'srequest port

Core-6361-126: received sri request forunknown source.

The context has handled an SRI requestfor an unknown source. This is not aserious problem but indicates that thereis a mismatch between this process andanother. This is typically caused by aUMP receiver attempting to join atransport for a UMP source that has beendeleted.

This can happen under normal situationsand should cease after sri requestconfiguration. If they don't, check thesystem for other abnormal behavior(applications restarting etc)

152 Chapter 8: UM Log Messages

Message Description Resolution

Core-6361-127: LBMC CNTL SRI REQheader size incorrect. Dropping. Origin:%s:%d.

Source Registration Information Requestmessage header contains incorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6361-128: LBMC CNTL SRI headersize incorrect. Dropping. Origin: %s:%d.

Source Registration Informationmessage header contains incorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6361-129: LBMC CNTL UME storedomain header size incorrect. Dropping.Origin: %s:%d.

Store Domain message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6361-130: LBMR Topic Info RecordEXFUNC Option not correct size.Dropping remainder.

UM encountered a mismatch in the lengthof a received message and its headers,determining the rest of the message to beinvalid. The remainder of the message isdropped.

Contact Informatica support if thismessage occurs frequently.

Core-6361-2: Topic Advertisement [%s]contains EXFUNC Info from %s but portis set to zero. Ignoring invalid EXFUNCInfo.

A Topic Advertisement was received withEXFUNC Information but the source portwas zero. The EXFUNC Information isbeing ignored.

This occurs when the Source disablesbinding of the request port. Seerequest_tcp_bind_request_portconfiguration option.

Core-6361-3: late join available, but noOTID present

UM has encountered a source with latejoin enabled, but that has no OTID. Thisis likely caused by a version mismatchwith an old version of UM.

Resolve the version mismatch.

Core-6361-4: OTID version mismatch -unable to provide late join

UM has encountered a source with amismatched OTID version. This is likelycaused by a UM version mismatch.

Resolve the version mismatch.

Core-6420-10: LBMC header data toolong, dropping message. Origin: %s:%d

Parsing data past the end of the validbuffer.

Check the received message for possiblewrong format or service attack.

Core-6420-11: LBMC header data toolong. Dropping. Origin: %s:%d.

Parsing data past the end of the validbuffer

Check the received control message forpossible wrong format or service attack.

Core-6420-12: LBMC basic header tooshort. Dropping. Origin: %s:%d.

Message header is less than theminimum size of LBMC header

Check the data being parsed for possiblewrong formats or service attack.

Core-6420-13: LBMC header data toolong. Dropping. Origin: %s:%d.

Parsing data past the end of the validbuffer.

Check the received message for possiblewrong format or service attack.

Core-6452-0: LBMC tid header sizeincorrect. Dropping. Origin: %s:%d.

The size of the TID header is incorrect. This is an internal error.

Core-6488-1: WARNING: UMQ queue"%s" context reg ID 0x%x, session ID 0x%x queue state ignored

The source application context has ahigher last-sent timestamp than thequeue reports at registration; this usuallymeans the queue missed a fewmessages the source sent either bybeing down or being too busy, etc., and isbehind when the source application re-registers.

Check to see if the queue has failed orbeen restarted during operation, or if it isbeing reported as inactive for periods oftime due to network problems, etc.

UM Core Log Messages 153

Message Description Resolution

Core-6675-1: non-UMQ context receivedunicast UMQ message.

A context received a UMQ message(unicast immediate message or controlmessage), but was not a UMQ context.This is not a serious problem andnormally indicates a non-UMQ contexthas re-used a request port recently heldby a UMQ context.

Check for frequent application restarts orother behavior that could cause ports tobe re-used between different types ofapplications.

Core-6720-1: IPC Error: CreatingReceiver Monitor Mutex (%d) (%s)

An IPC receiver could not create a sharedmonitoring Mutex. This could be causedby a permission error or the resourcealready exists. Please refer to the OSerror number and resource name given.

Core-6758-1: LBMC dropping packetcontaining deprecated PSER header.Origin: %s:%d

A packet containing a UME proxy sourceelection record (PSER) was droppedbecause their use has been deprecated.

This indicates umestored processes ofan older version are attempting to elect aproxy source on this topic resolutiondomain.

Core-6758-2: LBMC proxy election tokenheader size incorrect. Dropping. Origin:%s:%d.

An LBMC proxy source election tokenwas received from the specified Originthat contained the wrong length. Theentire packet was dropped.

This is caused by malformed or forgedpackets. Use the Origin to detect wherethey are coming from to investigatefurther.

Core-6758-3: LBMR dropping packetcontaining deprecated proxy sourceelection header. Origin: %s:%d

LBM resolver has dropped a deprecatedproxy source election packet. Reportedonly once per resolver.

Indicates previous versions of the UMEstore hosting proxy elections on theshared topic resolution address, apossible misconfiguration.

Core-6759-1: LBMR RCTXINFO packetmalformed. Dropping. Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-10: Updated destination forremote context name '%s'. Newdestination: DomainID %u addr %s:%d

An informational message indicating anupdated destination has been detectedfor a context name used by thisapplication.

This message is issued every time anamed context (E.g. a UMP storedaemon) changes the DomainID, IP, andport for which it resolves to. Repeatedoccurrences of this log message for thesame context name may indicate thatmultiple contexts are assigned the samename and active at the same time, whichis a mis-configuration. If this occurs,please ensure that context name usageis unique across all UM topic resolutiondomains.

Core-6759-11: Duplicate context name'%s' detected. Origin: DomainID %u addr%s:%d

A named context has detected anothercontext advertising the same name.

Advertised context names (E.g. storenames) must be unique across topicresolution domains. Check theconfiguration to ensure only one store ornamed context with a given name isoperational at any given time. The UMDomainID, IP address, and port of theadvertised duplicate context name aregiven.

Core-6759-2: LBMR RCTXINFO lenmalformed. Dropping. Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

154 Chapter 8: UM Log Messages

Message Description Resolution

Core-6759-3: LBMR RCTXINFO rec lenmalformed. Dropping. Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-31: Error parsing LBMRRCTXINFO header flags %x. Ignoring.Origin: %s:%d

An LBMR RCTXINFO packet header wasignored because it could not be parsed,or the application failed to allocatememory.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-4: LBMR RCTXINFO addressopt malformed. Dropping. Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-5: LBMR RCTXINFOinstance opt malformed. Dropping.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-6: LBMR RCTXINFOodomain opt malformed. Dropping.Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-7: LBMR RCTXINFO nameopt malformed. Dropping. Origin: %s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-8: LBMR RCTXINFOunknown opt 0x%02x. Dropping. Origin:%s:%d

An LBMR packet was dropped because itcould not be parsed.

Investigate the listed IP and port for anapplication generating spurious traffic.

Core-6759-9: Updated destination forremote context name '%s'. Newdestination: DomainID %u addr %s:%d

An informational message indicating anupdated destination has been detectedfor a context name used by thisapplication.

This message is issued every time anamed context (E.g. a UMP storedaemon) changes the DomainID, IP, andport for which it resolves to. Repeatedoccurrences of this log message for thesame context name may indicate thatmultiple contexts are assigned the samename and active at the same time, whichis a mis-configuration. If this occurs,please ensure that context name usageis unique across all UM topic resolutiondomains.

Core-6837-1: LBMC Route Info headersize incorrect. Dropping. Origin: %s:%d.

Route Info message header containsincorrect size.

Check source (IP:Port) for possibleversion mismatch or service attack.

Core-6856-0001: LBMC CNTL UME EXTstore header size incorrect. Dropping.Origin: %s:%d.

Header length for a data type:lbmc_cntl_ume_store_ext_hdr_t is notright

The packet might have been corrupted.Please contact customer support

Core-6937-10: LBMC CNTL TCP SIDheader size incorrect. Dropping. Origin:%s:%d.

An LBMC Session ID control message fora TCP transport is the wrong size.

The IP address and port indicate thesource of the erroneous traffic.

Core-6937-30: FD Register error whensending of Session ID; validation skipped(%p)(0x%x).

FD Register error when sending TCPSession ID to source for validation(transport_tcp_use_session_idenabled).

There is no immediate action. Validationis not required. If the error persists,however, check the system socketdefaults.

UM Core Log Messages 155

Message Description Resolution

Core-6937-31: Buffer allocation failurewhen sending Session ID (%p)(0x%x).

Buffer allocation error when sending TCPSession ID to source for validation(transport_tcp_use_session_idenabled).

A buffer allocation error usually is asymptom of running out of memory.

Core-6937-32: Topic Receiver sentmessage data on TCP connection.Ignoring. Origin: %s:%d

A TCP source received a data messagefrom a client. This was unexpected.

Refer to the clients IP:Port for the sourceof the message

Core-6937-33: Topic Receiver sentinvalid control message on TCPconnection. Ignoring. Origin: %s:%d

A TCP source received a controlmessage from a client that did not containthe expected information.

Refer to the clients IP:Port for the sourceof the message

Core-6938-1: NOTICE: store %u:%s:%ureports it has not received SRI(it mighthave received TIR ). Possiblemisconfiguration?

The UMP store reported it has not yetreceived SRI (source registrationinformation), it might have receivedTIR(topic advertisement) for a topicwhich already has one or more registeredsources. UMP registration happens via adifferent mechanism than topicresolution, and is sometimes a bit faster.Registration allows the source to beginsending, but the store does not actuallybegin listening for messages until itreceives a topic advertisement from thesource and sets up receivers for theappropriate topics. In that brief interval,the store will send these notices to thesource, just in case you actually didforget to configure the store to listen tothe correct topic resolution channel.Once the store receives a topic resolutionadvertisement and begins listening to thetopic, the store will perform a Late Joinrecovery if the source has already startedsending, and should be able to catch upunless you have changed your source'stransmission window to a small value (bydefault, a source keeps 24 MB of data forretransmission).Our recommendeddelay before sending should prevent youfrom seeing this notice most of the time,but you may occasionally see it duringstore failover.

Core-6974-1: LBMC CTXINSTS headerreceived without correspondingUME_STORE or UME_STORE_EXTheader. Dropping. Origin: %s:%d.

A malformed LBMC packet wasreceived.

Check the originating IP and port forapplications sending malformed data.

Core-6974-2: LBMC STORENAMEheader received without correspondingUME_STORE or UME_STORE_EXTheader. Dropping. Origin: %s:%d.

A malformed LBMC packet wasreceived.

Check the originating IP and port forapplications sending malformed data.

Core-6976-10: NOTICE: LBT-SMXtransport does not support adaptivebatching; option will be ignored.

The LBT-SMX transport does not supportadaptive batching, but the user

Perhaps the user shouldn't configure anLBT-SMX source to use adaptivebatching.

156 Chapter 8: UM Log Messages

Message Description Resolution

configured the source to use adaptivebatching.

Core-6976-103: WARNING: LBT-SMXsession exists and uses a differenttransport_lbtsmx_datagram_max_size[%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtsmx_datagram_max_sizesetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-6976-104: WARNING: LBT-SMXsession exists and uses a differenttransport_lbtsmx_sm_interval [%d] thanrequested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea different transport_lbtipc_sm_intervalsetting. Please refer to UMS Objectssection of the Design Concepts in thedocumentation.

Core-6976-105: WARNING: LBT-SMXsession exists and uses a differenttransport_lbtsmx_transmission_window_size [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtsmx_transmission_window_size setting. Please refer to UMSObjects section of the Design Conceptsin the documentation.

Core-6976-106: WARNING: LBT-SMXsession exists and uses a differenttransport_lbtsmx_maximum_receivers_per_transport [%d] than requested [%d].

Once a source has created a transportsession a subsequent source joining thesame transport session cannot configurea differenttransport_lbtsmx_maximum_receivers_per_transport setting. Please refer toUMS Objects section of the DesignConcepts in the documentation.

Core-6976-11: NOTICE: configuredtransport_lbtsmx_transmission_window_size (%u bytes) is not large enough tosupport at least two datagrams of theconfiguredtransport_lbtsmx_datagram_max_size(%u bytes). Transmission window sizewill be rounded up to %u bytes.

The configured LBT-SMX transmissionwindow size is not large enough toaccommodate the configured the maxdatagram size. We are automaticallybumping up the transmission windowsize from the configured size so that it islarge enough.

The user should simply configure theirdatagram max size and transmissionwindow sizes appropriately; thetransmission window size must be apower of 2, and it must be at least twicethe configured max datagram size.

Core-6976-114: LBT-SMX Error: Joiningtransport; no more free receiver slots

The application tried joining a source'sLBT-SMX transport session, but couldnot because no free receiver slots wereavailable.

Check thetransport_lbtsmx_maximum_receivers_per_transport config option setting on thesource to see if it's large enough for theintended number of receivers. Also checkfor hung receiver clients.

Core-6976-117: LBTSMX receiverthread dropping receiver add with nomatching transport

The LBT-SMX control source enqueuedan add of a new receiver or receivercallback, but the LBT-SMX receiverthread has no knowledge of the transport

UM Core Log Messages 157

Message Description Resolution

the receiver is supposed to be added too;either the transport was never correctlyadded or it was removed.

Core-6976-118: LBTSMX receiverthread dropping receiver remove with nomatching transport

The LBT-SMX control source enqueueda delete of a receiver or receiver callback,but the LBT-SMX receiver thread has noknowledge of the transport the receiver issupposed to be removed from; either thetransport was never correctly added or itwas already removed.

Core-6976-12:lbm_transport_lbtsmx_ctlr_delete:WFSO res=%d, GLE=%d

The WaitForSingleObject() Windows callreturn an error while waiting for the IPCReceiver thread to exit. Please refer tothe response and OS error numbergiven.

Core-6976-120: LBT-SMX receiverthread received unknown message type'%u' from transport LBTSMX_%x_%u.Further unknown message typesreceived from this transport will not bereported.

The LBT-SMX receiver thread received amessage type it does not understand.

This usually shouldn't happen, unlesssomething has gone wrong; check forthread safety issues in the applicationwith LBT-SMX-related API calls.

Core-6976-121: LBT-SMX receiverthread callback returned %d

An internal LBT-SMX control callbackfunction failed.

Something has likely gone terribly wrong;memory corruption, etc.

Core-6976-122: LBT-SMX: lockingproblem detected inlbtsmx_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing SMX shared resources.Please refer to the OS error numbergiven.

Core-6976-123: LBT-SMX: lockingproblem detected inlbtsmx_txw_rcvr_node_alloc (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing SMX shared resources.Please refer to the OS error numbergiven.

Core-6976-124: LBT-SMX: lockingproblem detected inlbtsmx_txw_lock_rcvr_nodes (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing SMX shared resources.Please refer to the OS error numbergiven.

Core-6976-125: LBT-SMX: lockingproblem detected inlbtsmx_txw_lock_rcvr_nodes (%d)

An error occurred with the shared objectused to ensure mutual exclusion whenaccessing SMX shared resources.Please refer to the OS error numbergiven.

Core-6976-126: LBT-SMX: failed to openshared memory (%d)

The SMX shared memory region couldnot be opened for reading. This couldoccur if a receiver attempts to join an IPCtransport after the source has been

158 Chapter 8: UM Log Messages

Message Description Resolution

deleted. Please reference the OS errornumber given.

Core-6976-127: LBT-SMX: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.Please refer to the OS error numbergiven.

Core-6976-128: LBT-SMX: TransportVersion Mismatch: Joining 0x%x fromversion 0x%x

The SMX shared memory region'sversion does not match our own; eitherthe shared memory is corrupt or is not aversion of LBT-SMX that we understand(it may be a newer or older version).

If different versions of the LBT-SMXtransport have been used on the samemachine, run their respectivelbtsmx_resource_manager tools toreclaim and delete shared memoryresources. Do not mix versions of LBT-SMX on the same machine.

Core-6976-129: LBT-SMX: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.Please refer to the OS error numbergiven.

Core-6976-13: LBTSMX: error in sizingresource registry (%d)

An error occurred when attempting to setshared memory registry file to the correctsize. The registry is used to store SMXshared objects that are in use. The OSerror number is given.

Core-6976-130: LBT-SMX: can not openshared semaphore (%d)

The shared semaphore used to ensuremutual exclusion while accessing SMXshared resources could not be opened.This could occur if a receiver attempts tojoin an IPC transport after the source hasbeen deleted. Please refer to the OSerror number given.

Core-6976-131: LBT-SMX: failed to openshared memory (%d)

The SMX shared memory region couldnot be opened for reading. This couldoccur if a receiver attempts to join an IPCtransport after the source has beendeleted. Please reference the OS errornumber given.

Core-6976-132: LBT-SMX: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.Please refer to the OS error numbergiven.

Core-6976-133: LBT-SMX: TransportVersion Mismatch: Joining 0x%x fromversion 0x%x

The SMX shared memory region'sversion does not match our own; eitherthe shared memory is corrupt or is not aversion of LBT-SMX that we understand(it may be a newer or older version).

If different versions of the LBT-SMXtransport have been used on the samemachine, run their respectivelbtsmx_resource_manager tools toreclaim and delete shared memoryresources. Do not mix versions of LBT-SMX on the same machine.

Core-6976-134: LBT-SMX: failed to mapshared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.

UM Core Log Messages 159

Message Description Resolution

Please refer to the OS error numbergiven.

Core-6976-135: LBT-SMX: can not openshared Mutex (%d)

An error occurred trying to open themutex that protects the LBT-SMX sharedmemory region - see the OS error codefor more information.

Core-6976-136: LBT-SMX Error: GettingReceiver Monitor Mutex (%d)

The LBT-SMX monitor thread could notacquire the shared monitoring Mutex.This could be caused by a permissionerror. Please refer to the OS errornumber and resource name given.

Core-6976-137: SMX Error: CreatingReceiver Monitor Mutex (%d) (%s)

An SMX receiver could not create ashared monitoring Mutex. This could becaused by a permission error or theresource already exists. Please refer tothe OS error number and resource namegiven.

Core-6976-138: SMX Error: CreatingReceiver Monitor Mutex (%d) (%s)

An SMX receiver could not create ashared monitoring Mutex. This could becaused by a permission error or theresource already exists. Please refer tothe OS error number and resource namegiven.

Core-6976-139: Error: Creating ReceiverThread (%d)

An error occurred when the receiverattempted to create a thread for internalprocessing. Please refer to the OS errornumber given.

Core-6976-14: LBTSMX: error mapping(initial) resource registry (%d)

An error occurred when attempting tomap memory to the registry file. Theregistry is used to store SMX sharedobjects that are in use. The OS errornumber is given.

Core-6976-140: LBT-SMX Error: Joiningtransport; no more free receiver slots

An SMX receiver is attempting to join anSMX transport that has no more free slotsfor receivers. Please adjust the"transport_lbtsmx_maximum_receivers_per_transport" configuration attribute.

Core-6976-141: default thread stack sizeis perhaps too small, %u bytes.

The LBT-SMX receiver has created athread for internal processing and thedefault stack size is too small. The size ofthe default stack size is dumped and willthen be set to a larger sizeautomatically.

Core-6976-142: reset thread stack sizeto %u bytes.

The SMX receiver has created a threadfor internal processing and the defaultstack size is too small and is reallocated.This message reports the new size of thestack.

160 Chapter 8: UM Log Messages

Message Description Resolution

Core-6976-143: Error: Creating ReceiverThread (%d)

An error occurred when the SMX receiverattempted to create a thread for internalprocessing. Please refer to the OS errornumber given.

Core-6976-144: LBT-SMX Error: Joiningtransport; no more free receiver slots

An SMX receiver is attempting to join anSMX transport that has no more free slotsfor receivers. Please adjust the"transport_lbtsmx_maximum_receivers_per_transport" configuration attribute.

Core-6976-145: SMX Error: CreatingReceiver Monitor Semaphore

An error occurred when an SMX receiverattempted to allocate a sharedmonitoring semaphore. This could becaused by a permission error or no moreresources. Please refer to thedocumentation forlbtsmx_resource_manager.

Core-6976-146: SMX Error: InitializingReceiver Monitor Semaphore (%d)

An error occurred when an SMX receiverattempted to initialize a sharedmonitoring semaphore. Please refer tothe OS error number given.

Core-6976-147: SMX Error: InitializingReceiver Monitor Semaphore (%d)

An error occurred when an SMX receiverattempted to initialize a sharedmonitoring semaphore. Please refer tothe OS error number given.

Core-6976-148: LBT-SMX ProblemOpening Signal Semaphore (%d)

The SMX source has received aconnection request from an SMX receiverand has failed to open the sharedsignaling semaphore. This could happenif the connection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber given.

Core-6976-149: LBT-SMX ProblemOpening Event (%d)

The SMX source has received aconnection request from an SMX receiverand has failed to open the shared Event.This could happen if the connectionrequest is old and the receiver wasalready deleted or the source does nothave permission to open the object.Please reference the OS error numbergiven.

Core-6976-15: LBTSMX: error creatingregistry semaphore (%d)

The semaphore used to ensure mutualexclusion while accessing the registrycould not be initialized. The registry isused to store IPC shared objects that arein use. Please refer to the documentationfor lbtsmx_resource_manager.

UM Core Log Messages 161

Message Description Resolution

Core-6976-150: LBT-SMX ProblemOpening Monitor Semaphore (%d)

The SMX source has received aconnection request from an SMX receiverbut has failed to open the MonitoringSemaphore. This could happen if theconnection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber given.

Core-6976-151: LBT-SMX ProblemOpening Monitor Mutex (%d) (%s)

The SMX source has received aconnection request from an SMX receiverbut has failed to open the MonitoringMutex. This could happen if theconnection request is old and thereceiver was already deleted or thesource does not have permission to openthe object. Please reference the OS errornumber and object name given.

Core-6976-16: LBTSMX: error initializingregistry semaphore (%d)

The semaphore used to ensure mutualexclusion while accessing the registrycould not be initialized. The registry isused to store IPC shared objects that arein use. Please refer to the documentationfor lbtsmx_resource_manager.

Core-6976-160:lbm_transport_lbtsmx_ctlr_delete:WFSO res=%d, GLE=%d

The WaitForSingleObject() Windows callreturn an error while waiting for the IPCReceiver thread to exit. Please refer tothe response and OS error numbergiven.

Core-6976-161: Could not create LBT-SMX control source; will not be able tojoin any LBT-SMX transports. Checkpermissions and reclaim any stale LBT-SMX resources.

The LBT-SMX internal control sourcecould not be created; this probablymeans the user doesn't havepermissions to create shared mutexes orsemaphores, or we have run out ofmemory, or we have run out of ourallowed number of semaphores.

Try running lbtsmx_resource_manager -reclaim to get rid of stale sharedresources, and check permissions of theapplication to see if it is allowed to createshared mutexes, etc.

Core-6976-162: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-163: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

162 Chapter 8: UM Log Messages

Message Description Resolution

Core-6976-164: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-165: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-166: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-167: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-168: lbm_lbtsmx_block_waitfailed

Waiting for the LBT-SMX receiver threadto complete an action failed; the receiverthread may or may not have completedthe action. The application maypotentially now be in an unstable state.This is usually due to being out ofmemory or out of available semaphoresand should normally not happen.

Contact Informatica support.

Core-6976-17: LBTSMX: error openingresource registry (%d)

An error occurred when attempting toopen or map memory to the registry file.The OS error number is given.

Core-6976-18: LBTSMX: error mappingresource registry (%d)

An error occurred when attempting toopen or map memory to the registry file.The OS error number is given.

Core-6976-19: LBTSMX: resourceregistry version mismatch: uselbtsmx_resource_manager to clean-upand delete registry.

An IPC registry file existed, andcontained the wrong version.

For this to happen, a registry file withincorrect version information would haveto be deliberately put in place. 3.5 andpost3.5 use different naming schemes for

UM Core Log Messages 163

Message Description Resolution

registries, so this can't happen due toversion mismatch.

Core-6976-20: LBTSMX: error re-mapping resource registry (entries: %d)(%d)

An error occurred when attempting to re-map memory to the registry file. Theregistry is used to store IPC sharedobjects that are in use. The size in entriesand OS error number is given.

Core-6976-21: LBTSMX: error opening.The semaphore used to ensure mutualexclusion while accessing the registrycould not be created. The registry is usedto store IPC shared objects that are inuse. The OS error number is given.

Core-6976-22: LBTSMX: errorreinitializing registry semaphore (%d)

The semaphore used to ensure mutualexclusion while accessing the registrycould not be initialized. The registry isused to store IPC shared objects that arein use. The OS error number is given.

Core-6976-23: LBTSMX: error re-creating resource registry (%d)

The registry used to store IPC sharedobjects that are in use could not becreated. The OS error number is given.

Core-6976-24: LBTSMX: error in re-sizing resource registry (%d)

The registry used to store IPC sharedobjects that are in use could not be re-sized (expanded). The OS error numberis given.

Core-6976-25: LBTSMX: error re-mapping resource registry (%d)

An error occurred when attempting to re-map memory to the registry file (fileexpansion). The registry is used to storeIPC shared objects that are in use. TheOS error number is given.

Core-6976-26: LBTSMX: No freesemaphores could be found

A free semaphore required for the LBT-IPC transport could not be found. Pleaserefer to the documentation forlbtsmx_resource_manager.

Core-6976-27: LBTSMX: error creatingregistry semaphore (%d)

An error occurred when attempting tocreate the LBT-SMX registry semaphoreset. The OS error number is given.

Core-6976-28: LBTSMX: error openingsemaphore (%d)

A free semaphore allocated for the LBT-IPC transport could not be opened. TheOS error number is given.

Core-6976-29: LBTSMX: error freeingsemaphore; key 0x%x not found

A semaphore allocated for the LBT-IPCtransport could not be freed due to aninvalid internal key. Please contactInformatica support.

164 Chapter 8: UM Log Messages

Message Description Resolution

Core-6976-32: specifiedtransport_lbtsmx_transmission_window_size of %u will be ignored in favor of thenext highest power of two: %u

LBT-SMX transmission window sizemust be a power of 2; the user specified anon-power-of-2 size.

Core-6976-6: NOTICE: LBT-SMXtransport does not support UMP; optionwill be ignored.

The LBT-SMX transport does not supportUMP, but the user configured the sourceas a UMP source.

Perhaps the user shouldn't configure anLBT-SMX source to use UMP.

Core-6976-7: NOTICE: LBT-SMXtransport does not support ULB; optionwill be ignored.

The LBT-SMX transport does not supportULB, but the user configured the sourceas a ULB source.

Perhaps the user shouldn't configure anLBT-SMX source to use ULB.

Core-6976-8: NOTICE: LBT-SMXtransport does not support UMQ; optionwill be ignored.

The LBT-SMX transport does not supportUMQ, but the user configured the sourceas a UMQ source.

Perhaps the user shouldn't configure anLBT-SMX source to use UMQ.

Core-6976-84: an error occurred whilecanceling source buffers - possibly due tonon thread-safe use oflbm_src_buffs_cancel; LBT-SMX sharedmemory may be in an inconsistent state

The user probably called a series of non-thread-safe buffer-based send APIfunctions concurrently.

Code testing for race conditions & codeinspection is advised.

Core-6976-9: NOTICE: LBT-SMXtransport does not support late join;option will be ignored.

The LBT-SMX transport does not supportlate join, but the user configured thesource to use late join.

Perhaps the user shouldn't configure anLBT-SMX source to use late join.

Core-7007-1: LBMC encountered morethan 2 Destination headers. Origin: %s:%d.

Discovered too many duplicate LBMCDestination headers in the same packet.This should be harmless, but indicates anerror in packet handling elsewhere.

Contact Informatica support.

Core-7007-2: LBMC encountered morethan 2 Stream headers. Origin: %s:%d.

Discovered too many duplicate LBMCStream headers in the same packet. Thisshould be harmless, but indicates anerror in packet handling elsewhere.

Contact Informatica support.

Core-7049-1: NOTICE: Initiatingproactive retransmissions for UMEsource on topic "%s" starting at sequencenumber 0x%x.

Proactive retransmissions are enabledand are being sent for a given source.

This probably means either stabilityACKs from a store are not reaching thesource application or the source'smessages are not reaching the store. Ineither case, causes of loss orconnectivity issues in each directionbetween the source and the store shouldbe investigated.

Core-7175-6: INFO: OTR enabled andotr message caching threshold is lessthan cache proximity: setting cacheproximity to half of caching threshold

When OTR is enabled, cache proximitymust be set to a smaller value thanmessage caching threshold.

Set cache proximity less than messagecaching threshold

Core-7275-1: INFO: received PREGRESP that was not a deregistrationresponse while the receiver is in thederegistering state

A registration response message thatdoes not have the flag set to deregisterwas received from a store, but the sourceis in the deregistration state.

Client deregistered before all stores werefully registered with. This is a benignissue because messages could havecrossed on the wire

UM Core Log Messages 165

Message Description Resolution

Core-7322-1:lbm_unicast_message_buff() failed toreallocate message buffer to includeadditional headers (%p:%p:%p)

When sending a unicast message buffer,a buffer could not be re-allocated toinclude additional information.

This is an LBM buffer create error. This islikely due to running out of memory.

Core-7421-1: Source Side Filtering Initmessage with no return IP, usingtransport IP (%s)

The request_tcp_interface parameterwas not configured on the source.

Configure the source to setrequest_tcp_interface.

Core-7479-1: NOTICE from src (RID:%u:(%s)): store %s:%u reports it has notreceived TIR. Possible misconfiguration?

The UMP store reported it has not yetreceived SRI (source registrationinformation), it might have receivedTIR(topic advertisement) for a topicwhich already has one or more registeredsources. UMP registration happens via adifferent mechanism than topicresolution, and is sometimes a bit faster.Registration allows the source to beginsending, but the store does not actuallybegin listening for messages until itreceives a topic advertisement from thesource and sets up receivers for theappropriate topics. In that brief interval,the store will send these notices to thesource, just in case you actually didforget to configure the store to listen tothe correct topic resolution channel.Once the store receives a topic resolutionadvertisement and begins listening to thetopic, the store will perform a Late Joinrecovery if the source has already startedsending, and should be able to catch upunless you have changed your source'stransmission window to a small value (bydefault, a source keeps 24 MB of data forretransmission).Our recommendeddelay before sending should prevent youfrom seeing this notice most of the time,but you may occasionally see it duringstore failover.

Core-7521-7: Could not close LBT-SMXshared memory

Closing a shared transmission windowfailed; this likely indicates an internalerror and should really never happen.

Core-7582-1: DRO does not support theLBT-SMX transport; ignoring LBT-SMXAdvertisements.

The DRO is dropping LBT-SMX TopicResolution traffic because it does notsupport this transport. This message maynot be repeated for each Advertisement.

The customer should use a differenttransport when a DRO is involved.Please reconfigure the source transporttype.

Core-7582-2: DRO does not allow theLBT-SMX source transport to beconfigured; changing source transport toTCP. Topic (%s)

The DRO does not support the LBT-SMXsource transport. The source transportwill automatically be changed to TCP.

The customer should use a differentsource transport when the DRO isconfigured. Please reconfigure thesource transport type.

166 Chapter 8: UM Log Messages

UM Core API Log MessagesThe following table lists log messages from Ultra Messaging Streaming Edition core API functionality.

You may find searching on the Log Message ID the most effective method to find the message's description.

Table 2. UM Core API Log Messages

Message Description Resolution

CoreApi-3288-1: optlen incorrect size Attempted to set wildcard receiverattribute "hf_receiver" using the wrongsize optlen.

The parameter "optlen" must be the sizeof an integer.

CoreApi-3288-2: optval must be 0 or 1 Attempted to set wildcard receiverattribute "hf_receiver" using an invalidvalue.

The only valid values are 0 and 1.

CoreApi-3288-3: optval not numeric Attempted to set wildcard receiverattribute "hf_receiver" using a string thatis not a number.

The parameter "optval" must be a stringrepresentation of a number.

CoreApi-3288-4: optval must be 0 or 1 Attempted to set wildcard receiverattribute "hf_receiver" using an invalidvalue.

The only valid values are 0 and 1.

CoreApi-3288-5: optlen incorrect size Attempted to get wildcard receiverattribute "hf_receiver" using the wrongsize optlen.

The parameter "optlen" must be the sizeof an integer.

CoreApi-3288-6: optlen too small Attempted to get wildcard receiverattribute "hf_receiver" using a stringlength that is too long.

The parameter "optlen" must be less than80.

CoreApi-5230-1: optlen incorrect size optlen incorrect size Should have passed in a lbm_uint32_t.

CoreApi-5230-10: invalidume_message_stability_timeout_behavior specified

invalidume_message_stability_timeout_behavior setting

currently the only valid setting is 0

CoreApi-5230-11: optval not numeric optval not numeric optval is not a number

CoreApi-5230-12: invalidume_message_stability_timeout_behavior specified

invalidume_message_stability_timeout_behavior setting

currently the only valid setting is 0

CoreApi-5230-13: optlen incorrect size optlen incorrect size optlen should be of size lbm_uint8_t

CoreApi-5230-14: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-5230-2: optval not numeric optval not numeric optval must be a number.

CoreApi-5230-3: optlen incorrect size optlen incorrect size optlen must be a lbm_uint32_t.

CoreApi-5230-4: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

UM Core API Log Messages 167

Message Description Resolution

CoreApi-5230-5: optlen incorrect size optlen incorrect size should have passed in a lbm_uint32_t

CoreApi-5230-6: optval not numeric optval not numeric optval must be a number.

CoreApi-5230-7: optlen incorrect size optlen incorrect size optlen must be a lbm_uint32_t

CoreApi-5230-8: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-5230-9: optlen incorrect size optlen incorrect size optlen should be a lbm_uint8_t

CoreApi-5243-1: TCP server socket: %s An error was returned from the OS whiletrying to create a socket (TCP). Pleaserefer to the OS error number andmessage given after the UMS message"TCP server socket".

CoreApi-5243-2: TCP server listen: %s An error was returned from the OS whiletrying to listen to a socket (TCP). Pleaserefer to the OS error number andmessage given after the UMS message"TCP server listen".

CoreApi-5243-3: TCP servergetsockname: %s

An error was returned from the OS whiletrying to get the name of a socket (TCP).Please refer to the OS error number andmessage given after the UMS message"TCP server getsockname".

CoreApi-5333-1: ttl value %d invalid,must be between 0 and 255.

Value passed in forresolver_multicast_ttl was not a validvalue.

Review the configuration file and specifya valid value (0 - 255).

CoreApi-5402-2: src must be valid Send was called using a NULL srcpointer.

Use a valid source pointer to send calls.

CoreApi-5402-3: exinfo flags cannothave both HF 32 and HF 64 set

Hot failover send was called using anexinfo that had both HF 32 and HF 64 bitflags set.

Ensure exinfo is valid and has one orneither HF bit size flag set before callingsend

CoreApi-5402-4: 32 bit hf src cannotsend non-32bit sequence number

A source that previously sent 32 bit hotfailover sequence numbers is attemptingto send a non-32 bit hot failoversequence number.

Ensure that the parameter "exinfo" hasthe correct HF flags set

CoreApi-5402-5: 64 bit hf src cannotsend non-64bit sequence number

A source that previously sent 64 bit hotfailover sequence numbers is attemptingto send a non-64 bit hot failoversequence number.

Ensure that the parameter "exinfo" hasthe correct HF flag set

CoreApi-5434-1: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue name string.

CoreApi-5434-2: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue message list callback object.

168 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-5434-3: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue name string.

CoreApi-5434-4: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue message retrieve callback object.

CoreApi-5434-5: Could not create sourcestring [%s:%d]

UMQ ran out of memory while creating asource string.

CoreApi-5434-6: Could not create topicstring [%s:%d]

UMQ ran out of memory while creating atopic string.

CoreApi-5434-7: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue name string.

CoreApi-5434-8: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating aqueue topic list callback object.

CoreApi-5480-10: could not createinactive_loss_rec_queue [%s:%d]

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-11: could not createactive_loss_rec_queue [%s:%d]

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-12: could not createunavailable_loss_rec_queue [%s:%d]

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-13: rxr_ctlr destination listis NULL

Internal error. Specified rxr_ctlr has notbeen fully created.

Contact Informatica support.

CoreApi-5480-14: lbm_rxr_request_talready cancelled

Internal error. Attempted duplicaterequest cancellation.

Contact Informatica support.

CoreApi-5480-15: unable to insertloss_rec into loss_rec_map

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-16: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-17: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-18: unable to insertloss_rec into loss_rec_map

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-19: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

UM Core API Log Messages 169

Message Description Resolution

CoreApi-5480-20: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-21: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-22: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-23: unable to insertloss_rec into loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-24: unable to insertloss_rec into inactive loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-25: unable to reschedulerxr_ctlr timer

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-26: unable to insertloss_rec into unavailable loss rec queue

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-27: could not create lossASL [%s:%d]

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5480-28: could not insertrcvdc_loss_rec ASL map [%s:%d]

Internal error while handling a detectedgap in data.

Contact Informatica support.

CoreApi-5480-5: unable to insert o_entryinto omap->asl

Internal error while attempting to handlean out of order message.

Contact Informatica support.

CoreApi-5480-7: unable to insert o_entryinto omap->asl

Internal error while attempting to handledetected loss.

Contact Informatica support.

CoreApi-5480-8: min_unavailable_delaymust be smaller than therequest_generation_ivl

Internal error while creating an rxr_ctlr.Should never happen.

Contact Informatica support.

CoreApi-5480-9: could not createrxr_loss_rec_map ASL [%s:%d]

Internal error while attempting to createan internal data structure. Most likely theresult of insufficient memory.

Contact Informatica support.

CoreApi-5539-1: Can't allocate per-sendobject node; message not sent [%s:%d]

Could not set up source per send data injni when calling HF send reset.

Ensure that correct exinfo is being usedand that sufficient memory is available.

CoreApi-5688-1246: session id not anumber

The provided session ID was invalid. Specify a session ID that fits one of thefollowing formats: A hexadecimal valueprefixed by 0x, an octal value prefixed by0, or a decimal value. The value must be

170 Chapter 8: UM Log Messages

Message Description Resolution

smaller than 0xFFFFFFFFFFFFFFFFregardless of representation.

CoreApi-5688-1390: session id not anumber

The provided session ID was invalid. Specify a session ID that fits one of thefollowing formats: A hexadecimal valueprefixed by 0x, an octal value prefixed by0, or a decimal value. The value must besmaller than 0xFFFFFFFFFFFFFFFFregardless of representation.

CoreApi-5688-2014: optval not numeric Value passed in forresolver_multicast_ttl was not numeric.

Review the configuration file and specifya valid numeric value for the option (0 -255).

CoreApi-5688-2767: session id not anumber

The provided session ID was invalid. Specify a session ID that fits one of thefollowing formats: A hexadecimal valueprefixed by 0x, an octal value prefixed by0, or a decimal value. The value must besmaller than 0xFFFFFFFFFFFFFFFFregardless of representation.

CoreApi-5688-2859: context name toolong

The supplied context name is invalidbecause it is too long.

Context names must not exceed 128characters in length.

CoreApi-5688-3040: Can not specify anegative number for inflight messages

Attempting to set the flight size ofmessages to a negative number

Ensure a positive integer for inflightmessages is returned from the set flightsize callback

CoreApi-5688-3041: Cannot specify anegative number for inflight messages

Attempting to set the flight size ofmessages to a negative number

Ensure a positive integer for inflightmessages is returned from the set flightsize callback

CoreApi-5688-3043: inflight must bevalid

inflight parameter was NULL inflight must be a valid pointer

CoreApi-5688-3226: TCP server socket:%s

An error was returned from the OS whiletrying to create a socket (TCP). Pleaserefer to the OS error number andmessage given after the UMS message"could not create TCP server socket".

CoreApi-5688-3227: TCP serverSO_REUSEADDR: %s

An error was returned from the OS whiletrying to set option of a socket (TCP).Please refer to the OS error number andmessage given after the UMS message"TCP server SO_REUSEADDR".

CoreApi-5688-3229: TCP serverSO_EXCLUSIVEADDR: %s

An error was returned from the OS whiletrying to set option of a socket (TCP).Please refer to the OS error number andmessage given after the UMS message"TCP server SO_EXCLUSIVEADDR".

CoreApi-5688-3230: could not find openTCP server port in range [%d-%d]

An error was returned from the OS whiletrying to bind a socket (TCP)".

UM Core API Log Messages 171

Message Description Resolution

CoreApi-5688-3231: TCP server bind(port=%d): %s

An error was returned from the OS whiletrying to bind a socket (TCP)".

CoreApi-5688-3232: TCP servergetsockname: %s

An error was returned from the OS whiletrying to get the name of a socket (TCP).Please refer to the OS error number andmessage given after the UMS message"TCP server getsockname".

CoreApi-5688-3233: TCP server listen:%s

An error was returned from the OS whiletrying to listen to a socket (TCP). Pleaserefer to the OS error number andmessage given after the UMS message"TCP server listen".

CoreApi-5688-3337: lbm_socket_sendbsend. A send error occurred whilesending. The message will containaddition specific information, supplied bythe operating system.

This is a platform specific error; pleaseuse the operating system's error codeand description to further understand thecircumstances of the error.

CoreApi-5688-4243:lbm_src_topic_attr_" #name "_set:%s

An error was returned when an attemptwas made to set an attribute.\n The errormessage returned is included in the textof this message.

CoreApi-5688-606: LBT-IPC: failed toallocate shared memory (%d)

A shared memory object for the IPCtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

CoreApi-5688-608: LBT-IPC: failed tomap shared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

CoreApi-5688-610: LBT-IPC: can notinitialize shared semaphore (%d)

An error occurred when initializing theshared semaphore used to ensuremutual exclusion while accessing the IPCshared memory region. Please refer tothe OS error number given.

CoreApi-5688-611: LBT-IPC: failed toallocate shared memory (%d)

A shared memory object for the IPCtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

CoreApi-5688-612: LBT-IPC: failed tomap shared memory (%d)

An error occurred trying to map a pointerto the IPC shared memory region. Pleaserefer to the OS error number given.

CoreApi-5688-613: LBT-IPC: can notcreate shared Mutex (%d)

The shared Mutex used to ensure mutualexclusion while accessing the IPCshared memory region could not becreated. Please refer to the OS errornumber given.

172 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-5760-1: receiver must be anobserver receiver (setumq_queue_participation to 2)

lbm_rcv_umq_queue_msg_retrieve wascalled using a normal receiver for the rcvparameter. Only observer receivers(receivers with the "receiverumq_queue_participation" option set to"2") may be used with this API.

CoreApi-5760-2: receiver must be anobserver receiver (setumq_queue_participation to 2)

lbm_rcv_umq_queue_msg_list wascalled using a normal receiver for the rcvparameter. Only observer receivers(receivers with the "receiverumq_queue_participation" option set to"2") may be used with this API.

CoreApi-5867-1: optval must not beNULL

The optval passed in was a NULLpointer.

Ensure NULL is not passed as the valueof the optval pointer because this iswhere the data will be copied

CoreApi-5867-14: error occurred parsingmessage selector string <%s>

The message selector string is invalid orcould not be parsed.

Please check the UM Documentation forvalid syntax.

CoreApi-5867-15: error occurredevaluating message selector string dueto unknown property type [%d] forproperty [%s]

Message property type was invalid. Verify that the message properties havenot been corrupted.

CoreApi-5867-16: rcv cannot beconfigured with both message selectorand spectrum channel behavior

A receiver was configured with both amessage selector and channel behavior

Remove either the message selector orthe channel behavior from the receiverattributes

CoreApi-5867-17: rcv cannot beconfigured with both message selectorand spectrum channel

A receiver was configured with both amessage selector and channel

Remove either the message selector orthe channel

CoreApi-5867-18: rcv cannot beconfigured with both message selectorand spectrum channel behavior

A receiver was configured with both amessage selector and channel behavior

Remove either the message selector orthe channel behavior from the receiverattributes

CoreApi-5867-2: optlen must not beNULL

The optlen passed in was a NULLpointer.

Ensure NULL is not passed as the valueof the optlen pointer because this isneeded to make sure the data can becopied

CoreApi-5867-3: optval is not longenough

Based on the optlen passed in, the datacannot be copied into optval due to itssize

Ensure optval is large enough to hold thedata (check the update optlen for theneeded size)

CoreApi-6001-1: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6001-10: async operationcanceled because connection with queuewas lost

An outstanding asynchronous operationwas canceled because the connectionwith the queue was lost,\n rendering theoutstanding async operation unlikely toever complete on its own.

This is normal behavior if a queue hasbeen brought down on purpose;otherwise, check to see if\n the queue isoverloaded and unresponsive or if thereis a connectivity problem between theclient application and the queue.

UM Core API Log Messages 173

Message Description Resolution

CoreApi-6001-11: could not allocatelbm_umq_rcvdc_t waiting command list[%s:%d]

The UMQ delivery controller's waitingcommand list could not be created.

This usually indicates severe resourceexhaustion; check for out of memoryerrors.

CoreApi-6001-2: optval must be greaterthan 0

The UMQ command outstanding maxpassed in was 0, which is not a validvalue.

Make sure the value given is > 0.

CoreApi-6001-3: UMQ commandoutstanding max not a number

The string representing the UMQcommand outstanding max could not beparsed to find a number.

Check the string being passed in, makesure it's a number > 0.

CoreApi-6001-4: optval must be greaterthan 0

The string representing the UMQcommand outstanding max was 0, whichis not a valid value.

Check the string being passed in, makesure it's a number > 0.

CoreApi-6001-5: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6001-6: optlen too small The size of the buffer passed in was lessthan the minimum buffer size required.

Make sure the buffer is large enough - atleast LBM_MIN_SGET_OPTLEN bytesin size.

CoreApi-6001-7: could not allocatelbm_umq_queue_t waiting cmd ID list[%s:%d]

UMS could not allocate a queuecontroller waiting command list. Thisprobably means malloc failed or thesystem is otherwise out of resources.

This is likely the result of severe resourceexhaustion; contact Informatica support.

CoreApi-6001-8: could not insertlbm_umq_queue_t CMD WAITING LIST[%s:%d]

A waiting command could not beenqueued onto the queue's waitingcommand list.

This is a severe problem and usuallyindicates resource exhaustion; check forout of memory conditions.

CoreApi-6001-9: could not insertlbm_umq_queue_t CMD ASL [%s:%d]

Attempting to take a waiting command offthe waiting command list and put it in theactive\n commands list failed.

This usually indicates resourceexhaustion; check for out of memoryconditions.

CoreApi-6020-1: optlen incorrect size optlen parameter is not the correct size optlen should be the size of anlbm_uint64_t

CoreApi-6020-10: Cannot increaseinflight messages or bytes whiledecreasing the other

Attempting to increase the flight sizemessages or bytes and decrease theother.

Ensure that the inflight set callbackreturns a valid inflight structure, or callthe method twice to set each oneindividually.

CoreApi-6020-11: Cannot increaseinflight messages or bytes whiledecreasing the other

Attempting to increase the flight sizemessages or bytes and decrease theother.

Ensure that the inflight set callbackreturns a valid inflight structure, or callthe method twice to set each oneindividually.

CoreApi-6020-12: Payload exceedsflight size bytes maximum, can not send.

Attempted to send a single message withpayload length greater than theconfigured maximum allowed limit

Send smaller messages or increasesource ume_flight_size_bytes

CoreApi-6020-13: inflight parametermust be a valid pointer

inflight parameter was NULL inflight must be a valid pointer

174 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6020-14: RPP sources mustalso configure a non-zero value forume_flight_size_bytes

Attempted to create a RPP enabledsource without specifying a valid flightsize bytes

Set "source ume_flight_size_bytes" to benon-zero

CoreApi-6020-2: opval not numeric optval parameter was not a stringrepresentation of a number

Ensure that the optval string is aunsigned number

CoreApi-6020-3: optval not a number optval parameter was not a stringrepresentation of a number

Ensure that the optval string is aunsigned number

CoreApi-6020-4: optlen incorrect size optlen parameter is not the correct size optlen should be size of lbm_uint64_t

CoreApi-6020-5: optlen too small optlen parameter too small Increase optlen size

CoreApi-6020-8: exinfo properties mustbe valid whenLBM_SRC_SEND_EX_FLAG_PROPERTIES is set

Attempted send with message propertiesflag set, but exinfo->properties wasNULL

Turn off message properties flag or setexinfo->properties correctly.

CoreApi-6020-9: Payload exceeds flightsize bytes maximum, unable to send.

Attempted to send a single message withpayload length greater than themaximum limit while using UMP flightsize blocking behavior

Send smaller messages or increasesource ume_flight_size_bytes

CoreApi-6034-2: session id not anumber

The provided session ID was invalid. Specify a session ID that fits one of thefollowing formats: A hexadecimal valueprefixed by 0x, an octal value prefixed by0, or a decimal value. The value must besmaller than 0xFFFFFFFFFFFFFFFFregardless of representation.

CoreApi-6111-0: optlen incorrect size optlen is not the correct size optlen should be the size of albm_uint8_t

CoreApi-6111-1: invalidume_receiver_paced_persistencesetting

Invalid setting for rpp Valid settings are 0 and 1

CoreApi-6111-10: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6111-11: optlen incorrect size optlen too small optlen should be size_t

CoreApi-6111-12: optval not numeric optval is not numeric optval needs to be numeric

CoreApi-6111-13: optval not a number optval not a number optval needs to be a number

CoreApi-6111-14: optlen incorrect size optlen incorrect size optlen should be size_t

CoreApi-6111-15: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6111-16: optlen incorrect size optlen incorrect size optlen should be of size lbm_uint64_t

CoreApi-6111-17: optval not numeric optval not numeric optval should be numeric

UM Core API Log Messages 175

Message Description Resolution

CoreApi-6111-18: optval not a number optval not a number optval needs to be a number

CoreApi-6111-19: optlen incorrect size optlen incorrect size optlen incorrect size.. should be albm_uint64_t

CoreApi-6111-2: optval not numeric optval is not numeric optval must be numeric

CoreApi-6111-20: optlen too small optlen too small optlen should beLBM_MIN_SGET_OPTLEN

CoreApi-6111-21: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6111-22: optval not numeric optval not numeric optval is not a number

CoreApi-6111-23: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6111-24: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6111-25: optlen incorrect size optlen incorrect size optlen should be size of lbm_uint8_t

CoreApi-6111-26: invalidume_repository_ack_on_receptionsetting

invalidume_repository_ack_on_recepeptionsetting

value should be 0 or 1

CoreApi-6111-27: optval not numeric optval not numeric optval is not a number

CoreApi-6111-28: invalidume_repository_ack_on_receptionsetting

invalidume_repository_ack_on_receptionsetting

optval should be 0 or 1

CoreApi-6111-29: optlen incorrect size optlen incorrect size optlen should be of size lbm_uint8_t

CoreApi-6111-3: invalidume_receiver_paced_persistencesetting

optval not a valid value optval must be 0 or 1

CoreApi-6111-30: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6111-31: optlen incorrect size size of the option is incorrect optlen must be a lbm_uint8_t

CoreApi-6111-32: invalidume_receiver_paced_persistencesetting

ume_receiver_paced_persistence set toinvalid value

ume_receiver_paced_persistenceshould be 0 or 1

CoreApi-6111-33: optval not numeric optval is not a number optval needs to be numeric only

CoreApi-6111-34: invalidume_receiver_paced_persistencesetting

ume_receiver_paced_persistence set toinvalid value

ume_receiver_paced_persistence mustbe 0 or 1

CoreApi-6111-35: optlen incorrect size optlen is not a lbm_uint8_t optlen should be a lbm_uint8_t

CoreApi-6111-36: optlen too small optlen is too small optlen needs to be at least 80

176 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6111-4: optlen incorrect size optval is incorrect size optval must be a lbm_uint8_t size

CoreApi-6111-5: optlen too small optlen is too small optlen must be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6111-6: optlen incorrect size optlen incorrect size optlen must be a size_t

CoreApi-6111-7: optval not numeric optval is not numeric optval must be a number

CoreApi-6111-8: optval not a number optval is not a number optval needs to be a number

CoreApi-6111-9: optlen incorrect size optlen incorrect size optlen should be a size_t

CoreApi-6117-100: rcv must be valid lbm_rcv_ume_deregister was called witha null rcv.

Don't deregister your receiver afteryou've deleted it.

CoreApi-6117-101: not registered withany stores.

Tried to deregister from stores when youwere never registered with any.

Don't call deregister if you've neverregistered to any stores.

CoreApi-6254-20: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating amessage selector string.

CoreApi-6254-21: Can't allocate memory[%s:%d]

UMQ ran out of memory while creating amessage selector.

CoreApi-6259-17: Unicast ImmediateMessage failed: cannot find route toRemote Domain: %u:%s:%d

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

If the warning persists, the Gatewayconfiguration should be examined forinconsistencies.

CoreApi-6259-18: Unicast ImmediateRequest failed: cannot find route toRemote Domain: %u:%s:%d

There is no known route to the givendomain. This could happen momentarilyas an LBM context learns the domainroutes at startup.

If the warning persists, the Gatewayconfiguration should be examined forinconsistencies.

CoreApi-6273-1: Cannot enable RPPwith round-robin stores

Cannot enable receiver-pacedpersistence with round-robin stores

Only use Q/C with RPP

CoreApi-6298-1: src could not deregisterfrom store

source failed trying to deregister from astore.

try again, unicast control channelbetween source a store may be down

CoreApi-6298-2: src is alreadyderegistering from the stores

source is already deregistered. don't call lbm_src_ume_deregistermultiple times passing in the samesource.

CoreApi-6435-1: msg must be valid Message Pointer is NULL

CoreApi-6435-2: msg has no fragmentinformation

Message doesn't have any fragmentinformation

CoreApi-6452-10: optval must 0 or 1 The auto_create_transaction_mgrpassed in value was not 0 or 1, which isnot a valid value.

Make sure the value given is 0 or 1.

UM Core API Log Messages 177

Message Description Resolution

CoreApi-6452-11:auto_create_transaction_mgr optvalmust 0 or 1

The string representing theauto_create_transaction_mgr could notbe parsed to find a number.

Check the string being passed in, makesure it's a number 0 or 1.

CoreApi-6452-12:auto_create_transaction_mgr optvalmust be 0 or 1

The string representing theauto_create_transaction_mgr was not 0or 1, which is not a valid value.

Check the string being passed in, makesure it's a number 0 or 1.

CoreApi-6452-13: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6452-14: optval must bebetween 0 or 3

The transaction_mgr_role passed invalue was not between 0 and 3, which isnot a valid value.

Make sure the value given between 0 and3.

CoreApi-6452-15: optlen incorrect size The string representing thetransaction_mgr_role could not beparsed.

Check the string being passed in, makesure it's one of the following:PROPOSER, ACCEPTOR, LEARNER,NONE

CoreApi-6452-16: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6452-17: optlen too small The size of the buffer passed in was lessthan the minimum buffer size required.

Make sure the buffer is large enough - atleast LBM_MIN_SGET_OPTLEN bytesin size.

CoreApi-6452-18: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6452-19: optval must bebetween 0 or 2

The transaction_mgr_type passed invalue was between 0 and 2, which is not avalid value.

Make sure the value given be between 0and 2.

CoreApi-6452-20: optlen incorrect size The string representing thetransaction_mgr_type could not beparsed.

Check the string being passed in, makesure it's one of the following:PROPOSER, ACCEPTOR, LEARNER,NONE

CoreApi-6452-21: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6452-22: optlen too small The size of the buffer passed in was lessthan the minimum buffer size required.

Make sure the buffer is large enough - atleast LBM_MIN_SGET_OPTLEN bytesin size.

CoreApi-6452-3: optlen too small Invalid Attribute Change attribute to a valid value.

CoreApi-6452-4: optlen incorrect size Invalid Attribute Change attribute to a valid value.

CoreApi-6452-5: optval must be -1, 0 or1

Invalid Attribute Change attribute to a valid value.

178 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6452-6: optval not numeric Invalid Attribute Change attribute to a valid value.

CoreApi-6452-7: optval must be -1, 0 or1

Invalid Attribute Change attribute to a valid value.

CoreApi-6452-8: optlen incorrect size Invalid Attribute Change attribute to a valid value.

CoreApi-6452-9: optlen incorrect size The size of the option passed in is not thecorrect size for this option.

This is usually a coding mistake; checkthat the correct type is being used for thisoption.

CoreApi-6755-1: ip string is malformed The ip string passed into ume_store ismalformed.

The ume_store ip_string must be in ana.b.c.d dotted decimal format.

CoreApi-6759-12: context name too long The supplied context name is invalidbecause it is too long.

Context names must not exceed 128characters in length.

CoreApi-6759-13: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_ulong_t).

CoreApi-6759-14: optval not numeric Optval is not numeric. The optval string must consist ofnumbers only.

CoreApi-6759-15: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_ulong_t).

CoreApi-6759-16: optlen too small Optlen is too small. Optlen should be at leastLBM_MIN_SGET_OPTLEN.

CoreApi-6759-17: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_ulong_t).

CoreApi-6759-18: optval not numeric Optval is not numeric. The optval string must consist ofnumbers only.

CoreApi-6759-19: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_ulong_t).

CoreApi-6759-20: optlen too small Optlen is too small. Optlen should be at leastLBM_MIN_SGET_OPTLEN.

CoreApi-6759-21: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_uint64_t).

CoreApi-6759-22: optval not numeric Optval is not numeric. The optval string must consist ofnumbers only.

CoreApi-6759-23: optval not a validvalue

Optval is not numeric. The optval string must consist ofnumbers only and fit in a 64 bit value.

CoreApi-6759-24: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_uint64_t).

CoreApi-6759-25: optlen too small Optlen is too small. Optlen should be at leastLBM_MIN_SGET_OPTLEN.

CoreApi-6759-26: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_uint64_t).

CoreApi-6759-27: optval not numeric Optval is not numeric. The optval string must consist ofnumbers only.

UM Core API Log Messages 179

Message Description Resolution

CoreApi-6759-28: optval not a validvalue

Optval is not numeric. The optval string must consist ofnumbers only and must fit in a 64 bitvalue.

CoreApi-6759-29: optlen incorrect size The oplen parameter is incorrect. Optlen must be size of(lbm_uint64_t).

CoreApi-6759-30: optlen too small Optlen is too small. Optlen should be at leastLBM_MIN_SGET_OPTLEN.

CoreApi-6856-10: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6856-11: optval not numeric optval not numeric optval is not a number

CoreApi-6856-12: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6856-13: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6856-2: optlen incorrect size optlen incorrect size optlen should be lbm_uint16_t

CoreApi-6856-3: optval not numeric optval not numeric optval is not a number

CoreApi-6856-4: optlen incorrect size optlen incorrect size optlen should be lbm_uint16_t

CoreApi-6856-5: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6856-6: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6856-7: optval not numeric optval not numeric optval is not a number

CoreApi-6856-8: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6856-9: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6898-0: optlen incorrect size umq_explicit_ack_only needs to be 0 or1.:

Set umq_explicit_ack_only to 0 or 1.

CoreApi-6898-1: optval must be 0 or 1 umq_explicit_ack_only needs to be 0 or1.

Set umq_explicit_ack_only to 0 or 1.

CoreApi-6898-2: optval not numeric umq_explicit_ack_only needs to be 0 or1.

Set umq_explicit_ack_only to 0 or 1.

CoreApi-6898-3: optval must be 0 or 1 umq_explicit_ack_only needs to be 0 or1.

Set umq_explicit_ack_only to 0 or 1.

CoreApi-6898-4: optlen incorrect size lbm_rcv_topic_attr_umq_exack_only_get requires an Integer.

Pass a pointer to a Integer tolbm_rcv_topic_attr_umq_exack_only_get

CoreApi-6898-5: optlen too small lbm_rcv_topic_attr_umq_exack_only_sget requires an Integer.

Pass a pointer to a Integer tolbm_rcv_topic_attr_umq_exack_only_sget

180 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6898-6: must have explicit acksenabled

Explicit Acks must be set to 1 beforecalling sendExplicitAck.

Set umq_explicit_ack_only to 1.

CoreApi-6898-7: msg must be valid Invalid Message. lbm_msg_umq_send_explicit_ack mustbe called with a valid message.

CoreApi-6898-8: msg must be valid Invalid Message. lbm_msg_umq_can_send_explicit_ackmust be called with a valid message.

CoreApi-6932-1: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-11: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-12: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-13: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-14: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-15: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-16: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-17: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6932-2: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-21: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-22: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-23: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-24: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-25: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-26: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

UM Core API Log Messages 181

Message Description Resolution

CoreApi-6932-27: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6932-3: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-31: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-32: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-33: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-34: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-35: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-36: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-37: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6932-4: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-41: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-42: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-43: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-44: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-45: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-46: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-47: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6932-5: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

182 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6932-51: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-52: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-53: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6932-54: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-6932-55: optval must be greaterthan 0

The option value submitted was zero (0);this value must be greater than 0.

While 1 is an acceptable minimum; alarger value provides redundancy.

CoreApi-6932-56: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-57: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6932-6: optlen incorrect size The size of the option was too large and/or too small

sri_request_interval is an lbm_ulong_t

CoreApi-6932-7: optlen too small The size of the option buffer was toosmall to contain the option.

sri_request_interval is an lbm_ulong_t

CoreApi-6937-1: optlen incorrect size The size of the option was too large or toosmall

transport_tcp_use_session_id is an int

CoreApi-6937-2: optval must be 0 or 1 transport_tcp_use_session_id can eitherbe set "ON" or "OFF"

Please use "0" to indicate "OFF" and "1"to indicate "ON"

CoreApi-6937-3: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-6937-4: optval must be 0 or 1 transport_tcp_use_session_id can eitherbe set "ON" or "OFF"

Please use "0" to indicate "OFF" and "1"to indicate "ON"

CoreApi-6937-5: optlen incorrect size The size of the option was too large or toosmall

transport_tcp_use_session_id is an int

CoreApi-6937-6: optlen too small The size of the option buffer was toosmall to contain the option.

transport_tcp_use_session_id is an int

CoreApi-6976-1: buff_acquire wouldblock

A non-blocking lbm_src_buff_acquirewould block.

This is perfectly normal from time to time.If it happens every send call or veryfrequently, a receiver may be still alive,but hung.

CoreApi-6976-100: optval notunderstood

The value is not a supported operationalmode - either embedded or sequential.

UM Core API Log Messages 183

Message Description Resolution

CoreApi-6976-101: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

CoreApi-6976-102: optlen too small The value of optlen passed in is too smallto hold the option type.

CoreApi-6976-107: optlen incorrect size Value of optlen passed in is not equal tothe size of the option.

CoreApi-6976-108: optval not numeric Value of the option passed in does notappear to be a number - and it needs tobe.

CoreApi-6976-109: optval not a number Value of the option passed in does notappear to be a number - and it needs tobe.

CoreApi-6976-110: optlen incorrect size Value of optlen passed in is not equal tothe size of the option.

CoreApi-6976-111: optlen too small Value of optlen passed in is not bigenough to store the option type.

CoreApi-6976-112: lbm_imbq_createCreateMutex

We failed to create a mutex on Windows;this probably indicates resourceexhaustion.

Check machine for excessive memoryuse or excessive open handles (both canbe viewed in Task Manager)

CoreApi-6976-113: lbm_imbq_createCreateSemaphore

We failed to create a semaphore onWindows; this probably indicatesresource exhaustion.

Check machine for excessive memoryuse or excessive open handles (both canbe viewed in Task Manager)

CoreApi-6976-115: The LBT-SMXtransport type does not support HotFailover sources

User attempted to create a hot failoversource with an LBT-SMX transport, whichis not supported.

CoreApi-6976-116: optval either not anumber or a negative number

The value passed in does not appear tobe a number, or it is a negative number.

CoreApi-6976-119: Configured LBT-SMX transport_lbtsmx_id_low (%u) isgreater than configuredtransport_lbtsmx_id_high (%u)

The configured "contexttransport_lbtsmx_id_low" option ishigher than the configured "contexttransport_lbtsmx_id_high" option, whichis not allowed (and makes no sense).

CoreApi-6976-152: LBT-SMX: failed toallocate shared memory (%d)

A shared memory object for the SMXtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

CoreApi-6976-153: LBT-SMX: failed toallocate shared memory of sizeconfigured %d, rcvrs: %d (%d)

A shared memory object for the SMXtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

184 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6976-154: LBT-SMX: failed tomap shared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.Please refer to the OS error numbergiven.

CoreApi-6976-155: LBT-SMX: can notget shared semaphore

A shared memory object for the SMXtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

CoreApi-6976-156: LBT-SMX: can notinitialize shared semaphore (%d)

An error occurred when initializing theshared semaphore used to ensuremutual exclusion while accessing theSMX shared memory region. Please referto the OS error number given.

CoreApi-6976-157: LBT-SMX: failed toallocate shared memory (%d)

A shared memory object for the SMXtransport could not be created. This couldbe caused by a permission error or nomore resources. Please refer to the OSerror number given.

CoreApi-6976-158: LBT-SMX: failed tomap shared memory (%d)

An error occurred trying to map a pointerto the SMX shared memory region.Please refer to the OS error numbergiven.

CoreApi-6976-159: LBT-SMX: can notcreate shared Mutex (%d)

The shared Mutex used to ensure mutualexclusion while accessing the SMXshared memory region could not becreated. Please refer to the OS errornumber given.

CoreApi-6976-2: requested buffer lengthis higher than configuredtransport_lbtsmx_datagram_max_size(%u bytes) for source

A length parameter was passed tolbm_src_buff_acquire that was greaterthan the configured maximum datagramsize; this is a user error.

Application code should be fixed to notcall buff_acquire with a length parameterthat is too big.

CoreApi-6976-3: LBT-SMX: too manyoutstanding buffs; calllbm_src_buffs_complete beforeacquiring more

The LBT-SMX transport sessioncurrently has too many outstandingbuffers; if another was acquired now, thereceivers could never catch up and thebuff_acquire call would block forever.

Application code should be fixed to notcall buff_acquire too many times withoutcalling buffs_complete.

CoreApi-6976-30: LBT-SMX notsupported

The user is trying to set a config option orperform a function with a library that doesnot support the LBT-SMX transport.

CoreApi-6976-31: lbm_send_requestand lbm_send_request_ex are notsupported with transport type LBT-SMX

User tried to send a request via a sourceset to use the SMX transport; this is notcurrently supported.

Don't send requests on LBT-SMXsources.

CoreApi-6976-33: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

UM Core API Log Messages 185

Message Description Resolution

CoreApi-6976-34: LBT-SMXtransmission window size must be atleast %d bytes

The user tried to configure the LBT-SMXtransmission window size smaller thanthe minimum required size.

Change configuration to specify a largerLBT-SMX transmission window size.

CoreApi-6976-35: optval not numeric The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-36: optval not a number The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-37: LBT-SMXtransmission window size must be atleast %d bytes

The user tried to configure the LBT-SMXtransmission window size smaller thanthe minimum required size.

Change configuration to specify a largerLBT-SMX transmission window size.

CoreApi-6976-38: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-39: optlen too small The optlen parameter passed in specifiesa size that is too small to hold the optionvalue.

CoreApi-6976-4: LBT-SMX: too manyoutstanding buffs; calllbm_src_buffs_complete beforeacquiring more

The LBT-SMX transport sessioncurrently has too many outstandingbuffers; if another was acquired now, thereceivers could never catch up and thebuff_acquire call would block forever.

Application code should be fixed to notcall buff_acquire too many times withoutcalling buffs_complete.

CoreApi-6976-40: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-41: LBT-SMX maximumreceivers optval not a valid size

LBT-SMX max receivers must be set to atleast 1; 0 is not supported (or sensible).

CoreApi-6976-42: optval not numeric The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-43: LBT-SMX maximumreceivers optval not a valid size

LBT-SMX max receivers must be set to atleast 1; 0 is not supported (or sensible).

CoreApi-6976-44: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-45: optlen too small The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-46: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-47: optval not a validinterval

The LBT-SMX session message intervalmust be > 0; zero is not a valid value.

CoreApi-6976-48: optval not numeric The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-49: optval not a number The value passed in does not appear tobe a number - and it should be.

186 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6976-5: LBT-SMX: too manyoutstanding buffs; calllbm_src_buffs_complete beforeacquiring more

The LBT-SMX transport sessioncurrently has too many outstandingbuffers; if another was acquired now, thereceivers could never catch up and thebuff_acquire call would block forever.

Application code should be fixed to notcall buff_acquire too many times withoutcalling buffs_complete.

CoreApi-6976-50: optval not a validinterval

The LBT-SMX session message intervalmust be > 0; zero is not a valid value.

CoreApi-6976-51: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-52: optlen too small The optlen parameter passed in specifiesa size that is too small to hold the optionvalue.

CoreApi-6976-53: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-54: optval not numeric The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-55: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-56: optlen too small The optlen parameter passed in specifiesa size that is too small to hold the optionvalue.

CoreApi-6976-57: LBT-SMX is notsupported

User is trying to configure thelbtsmx_datagram_max_size on a buildthat doesn't support LBT-SMX.

CoreApi-6976-58: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

CoreApi-6976-59: value must be greaterthan or equal to %d

The datagram max size for LBT-SMXmust be >= the maximum header size.

CoreApi-6976-60: LBT-SMX is notsupported

The user tried to set or getlbtsmx_datagram_max_size using abuild that does not support LBT-SMX.

CoreApi-6976-61: datagram size not anumber

The value passed in does not appear tobe a number - and it should be.

CoreApi-6976-62: value must be greaterthan or equal to %d

The datagram max size for LBT-SMXmust be >= the maximum header size.

CoreApi-6976-63: LBT-SMX is notsupported

The user tried to set or getlbtsmx_datagram_max_size using abuild that does not support LBT-SMX.

CoreApi-6976-64: optlen incorrect size The optlen parameter passed in does notmatch the size of the option type.

UM Core API Log Messages 187

Message Description Resolution

CoreApi-6976-65: LBT-SMX is notsupported

The user tried to set or getlbtsmx_datagram_max_size using abuild that does not support LBT-SMX.

CoreApi-6976-66: optlen too small The optlen parameter passed in specifiesa size that is too small to hold the optionvalue.

CoreApi-6976-67: could not allocate newbuffer to retain lbm_msg_t

A buffer to hold message data could notbe allocated; usually this means mallocfailed due to being out of memory.

Check machine for excessive memoryuse.

CoreApi-6976-68: src cannot be NULL User passed NULL for the sourceparameter. NULL is not a valid source.

CoreApi-6976-69: LBT-SMX sources donot lbm_src_send_ex_info_t options;exinfo must be NULL

LBT-SMX does not support any of theoptions that can be specified with anlbm_src_send_ex_info_t object.Therefore, the exinfo parameter whensending with an LBT-SMX source shouldalways be NULL.

CoreApi-6976-70: source transport typedoes not support sending withlbm_src_buff_acquire

The current build does not support LBT-SMX, but the user is trying to call the newLBT-SMX-related send API calls.

CoreApi-6976-71: src must not be NULL The user specified a NULL pointer for thesource argument tolbm_src_buff_acquire, which is invalid.

CoreApi-6976-72: bufp must not beNULL

The user specified a NULL pointer for thebufp argument to lbm_src_buff_acquire,which is invalid.

CoreApi-6976-73: only LBT-SMXsources support sending withlbm_src_buff_acquire

The user called a new LBT-SMX-relatedsend API call using a source that is notLBT-SMX source; this is unsupported.

CoreApi-6976-74: source transport typedoes not support sending withlbm_src_buffs_complete

The current build does not support LBT-SMX, but the user is trying to call the newLBT-SMX-related send API calls.

CoreApi-6976-75: src must not be NULL The user specified a NULL pointer for thesource argument tolbm_src_buffs_complete, which isinvalid.

CoreApi-6976-76: only LBT-SMXsources support sending withlbm_src_buffs_complete

The user called a new LBT-SMX-relatedsend API call using a source that is notLBT-SMX source; this is unsupported.

CoreApi-6976-77: source transport typedoes not support sending withlbm_src_buffs_complete_and_acquire

The current build does not support LBT-SMX, but the user is trying to call the newLBT-SMX-related send API calls.

188 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6976-78: src must not be NULL The user specified a NULL pointer for thesource argument tolbm_src_buffs_complete_and_acquire,which is invalid.

CoreApi-6976-79: bufp must not beNULL

The user specified a NULL pointer for thebufp argument tolbm_src_buffs_complete_and_acquire,which is invalid.

CoreApi-6976-80: only LBT-SMXsources support sending withlbm_src_buffs_complete_and_acquire

The user called a new LBT-SMX-relatedsend API call using a source that is notLBT-SMX source; this is unsupported.

CoreApi-6976-81: source transport typedoes not support lbm_src_buffs_cancel

The current build does not support LBT-SMX, but the user is trying to call the newLBT-SMX-related send API calls.

CoreApi-6976-82: src must not be NULL The user specified a NULL pointer for thesource argument tolbm_src_buffs_cancel, which is invalid.

CoreApi-6976-83: only LBT-SMXsources support canceling outstandingbuffers with lbm_src_buffs_cancel

The user called a new LBT-SMX-relatedsend API call using a source that is notLBT-SMX source; this is unsupported.

CoreApi-6976-85: an error occurredwhile canceling source buffers - possiblydue to non thread-safe use oflbm_src_buffs_cancel; LBT-SMX sharedmemory may be in an inconsistent state

The user probably called a series of non-thread-safe buffer-based send APIfunctions concurrently.

Code testing for race conditions & codeinspection is advised.

CoreApi-6976-86: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

CoreApi-6976-87: optval not a valid ID Transport ID 0 is reserved for internal usefor LBT-SMX, so configuring a 0 is notallowed.

CoreApi-6976-88: optval not numeric The value given does not appear to be anumber - and it needs to be.

CoreApi-6976-89: optval not a valid ID Transport ID 0 is reserved for internal usefor LBT-SMX, so configuring a 0 is notallowed.

CoreApi-6976-90: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

CoreApi-6976-91: optlen too small The value of optlen passed in is too smallto hold the option type.

CoreApi-6976-92: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

UM Core API Log Messages 189

Message Description Resolution

CoreApi-6976-93: optval not a valid ID Transport ID 0 is reserved for internal usefor LBT-SMX, so configuring a 0 is notallowed.

CoreApi-6976-94: optval not numeric The value given does not appear to be anumber - and it needs to be.

CoreApi-6976-95: optval not a valid ID Transport ID 0 is reserved for internal usefor LBT-SMX, so configuring a 0 is notallowed.

CoreApi-6976-96: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

CoreApi-6976-97: optlen too small The value of optlen passed in is too smallto hold the option type.

CoreApi-6976-98: optlen incorrect size The value of optlen passed in does notmatch the size of the option type.

CoreApi-6976-99: optval not supported The value is not a supported operationalmode - either embedded or sequential.

CoreApi-6986-1:ume_sri_inter_sri_interval can not bezero

ume_sri_inter_sri_interval is set to zero ume_sri_inter_sri_interval can not bezero

CoreApi-6986-2:ume_sri_inter_sri_interval can not bezero

ume_sri_inter_sri_interval is set to zero ume_sri_inter_sri_interval can not bezero

CoreApi-6986-3: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6986-4:ume_source_timer_minimum_intervalcan not be zero

ume_src_timer_min_ivl is set to zero ume_src_timer_min_ivl can not be zero

CoreApi-6986-5: optval not numeric optval not numeric optval is not a number

CoreApi-6986-6:ume_source_timer_minimum_intervalcan not be zero

ume_src_timer_min_ivl is set to zero ume_src_timer_min_ivl can not be zero

CoreApi-6986-7: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6986-8: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6993-1: optval not numeric optval not numeric optval is not a number

CoreApi-6993-2: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6993-3: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6993-4: optval not numeric optval not numeric optval is not a number

190 Chapter 8: UM Log Messages

Message Description Resolution

CoreApi-6993-5: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6993-6: optlen too small optlen too small optlen should be at leastLBM_MIN_SGET_OPTLEN

CoreApi-6993-7: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-6993-8: optlen incorrect size optlen incorrect size optlen should be lbm_uint32_t

CoreApi-7160-1: optlen incorrect size optlen value contained the incorrectlength

optlen should be size of(lbm_ulong_t)

CoreApi-7160-10: optval not numeric Attempted to set receiverotr_request_message_timeout to a nonnumeric value

optval must be a string representation ofa number

CoreApi-7160-11: optval not a number Could not parse string optval into anumber

optval must be a number

CoreApi-7160-12: optval must be greaterthan 0

timeout value cannot be negative Change configuration to provide apositive value

CoreApi-7160-13: optlen incorrect size optlen contained an incorrect size optlen should be size of(lbm_ulong_t)

CoreApi-7160-14: optlen too small optlen was too small increase size of optlen

CoreApi-7160-2: optval must be greaterthan 0

optval contained a negative integer optval must be a positive integer

CoreApi-7160-3: optval not numeric Attempted to set receiverretransmit_request_message_timeout toa non numeric value

optval must be a string representation ofa number

CoreApi-7160-4: optval not a number Could not parse string optval into anumber

optval must be a number

CoreApi-7160-5: optval must be greaterthan 0

receiverretransmit_request_message_timeoutcannot be negative

Change configuration to provide apositive value

CoreApi-7160-6: optlen incorrect size optlen contained an incorrect size optlen should be size of(lbm_ulong_t)

CoreApi-7160-7: optlen too small optlen was too small increase size of optlen

CoreApi-7160-8: optlen incorrect size optlen value contained the incorrectlength

optlen should be size of(lbm_ulong_t)

CoreApi-7160-9: optval must be greaterthan 0

optval contained a negative integer optval must be a positive integer

CoreApi-7175-1: optlen incorrect size The size of the option was too large and/or too small

otr_message_caching_threshold is anlbm_ulong_t

UM Core API Log Messages 191

Message Description Resolution

CoreApi-7175-2: optval not numeric The option value string submittedcontains non numeric characters.

Be sure there are no trailing non numericcharacters such as spaces and that thenumber is not in hexadecimal.

CoreApi-7175-3: optval not a number The option value string submitted couldnot be converted into a number

Be sure that the size (magnitude) of thevalue is correct for an lbm_ulong_t

CoreApi-7175-4: optlen incorrect size The size of the option was too large and/or too small

otr_message_caching_threshold is anlbm_ulong_t

CoreApi-7175-5: optlen too small The size of the option buffer was toosmall to contain the option.

otr_message_caching_threshold is anlbm_ulong_t

CoreApi-7521-1: optlen incorrect size Incorrect length used for setting integeroptions

length must be size of int

CoreApi-7521-2: optval must be 0 or 1 Invalid value for optval optval must be 0 or 1

CoreApi-7521-3: optval not numeric Option string was not a number Provide number as a string

CoreApi-7521-4: optval must be 0 or 1 Invalid value for optval optval must be 0 or 1

CoreApi-7521-5: optlen incorrect size Size of optlen was incorrect optlen size must be size of int

CoreApi-7521-6: optlen too small Size of optlen was too small Size of optlen must be at least 80

UM Lbmrd Log MessagesThe following table lists log messages from Ultra Messaging Streaming Edition Lbmrd functionality.

You may find searching on the Log Message ID the most effective method to find the message's description.

ID Message Description Resolution

5688-4674 Lbmrd-5688-4674: LBMRTopic Query Recordmalformed. Droppingremainder.

UMS encountered amismatch in the length of areceived message and itsheaders, determining the restof the message to be invalid.The remainder of themessage is dropped. ContactInformatica support if thismessage occurs frequently.

5688-4675 Lbmrd-5688-4675: LBMRTopic Info Record malformed.Dropping remainder.

UMS encountered amismatch in the length of areceived message and itsheaders, determining the restof the message to be invalid.The remainder of themessage is dropped. Contact

192 Chapter 8: UM Log Messages

ID Message Description Resolution

Informatica support if thismessage occurs frequently.

UM Dynamic Routing Log MessagesThe following table lists log messages from the UM Dynamic Routing functionality.

You may find searching on the Log Message ID the most effective method to find the message's description.

Table 3. UM Dynamic Routing Log Messages

Message Description Resolution

Gwd-5975-1: error in PCRE patternoffset %d: %s

UMS detected a malformed PCREexpression while handling a wildcardreceiver pattern.

Contact Informatica support if thismessage occurs frequently or if topicresolution appears to be failing.

Gwd-5975-2: illegal regex: %s UMS detected a malformed REGEXexpression while handling a wildcardreceiver pattern.

Contact Informatica support if thismessage occurs frequently or if topicresolution appears to be failing.

Gwd-5975-3: peer portal [%s] failed tocreate control buffer (send EOS) [%d]:%s

Failed to create a control buffer neededto indicate EOS across the Peer link.

Failure to create buffers usually indicatesa serious memory issue. Configurationsettings may be causing excessivememory allocation.

Gwd-5975-4: tnwg_peer_propagate_cb:portal [%s] failed to create buffer [%d]:%s

Failed to create a control buffer neededto propagate route information throughthe Peer link.

Failure to create buffers usually indicatesa serious memory issue. Configurationsettings may be causing excessivememory allocation.

Gwd-5975-5: peer portal [%s] failed toschedule recalc timer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-5975-6: peer portal [%s] failed tocreate raw buffer (send fragment) [%d]:%s

Failed to create a control buffer neededto propagate MIM traffic through the Peerlink.

Failure to create buffers usually indicatesa serious memory issue. Configurationsettings may be causing excessivememory allocation.

Gwd-5975-7: peer portal [%s] failed toschedule peer shutdown timer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-5975-8: TMgr [%s] sourcemap sizeof zero is not allowed, using default(%d).

The sourcemap size config option cannot be zero. Setting it to the default.

User should update their configurationfile.

Gwd-5975-9: TMgr [%s] sourcemap sizemust be a power of two, adjusting sizefrom %d to %d

The sourcemap size config option mustbe a power of two. Setting it to the nexthighest power of two.

User should update their configurationfile.

UM Dynamic Routing Log Messages 193

Message Description Resolution

Gwd-6033-353: endpoint portal [%s]received one or more UIM controlmessages with no stream information -these will be dropped

This gateway has received messagesfrom a client using an earlier version ofthe library that does not include streaminformation.

If this is expected behavior, this messagecan be ignored; otherwise the clientshould have its library upgraded.

Gwd-6033-593: peer portal [%s] receivedone or more UIM control messages withno stream information - these will bedropped

This gateway has received messagesfrom a client using an earlier version ofthe library that does not include streaminformation.

If this is expected behavior, this messagecan be ignored; otherwise the clientshould have its library upgraded.

Gwd-6259-50: Message received with norouting information; dropping. Topic (%s)Source (%s)

A message was received by a Gatewaythat contains no routing information andtherefore was dropped.

This is likely due to a version mismatch.The Topic and Source string are given inthe message.

Gwd-6259-51: Message received withunusually high hop count (%d). Topic(%s) Source (%s)

A message was received by a Gatewaythat contains a high hop count (given inmessage).

The customer needs to evaluate theirnetwork topology.

Gwd-6259-52: Control messagereceived with no routing information;dropping. Origin: %s:%d

A control message was received by aGateway that contains no routinginformation and therefore was dropped.

This is likely due to a version mismatch.The origin is given in the message.

Gwd-6259-53: Control messagereceived with unusually high hop count(%d). Origin: %s:%d

A message was received by a Gatewaythat contains a high hop count (given inmessage).

The customer needs to evaluate theirnetwork topology.

Gwd-6259-54: endpoint portal [%s] failedto send unicast [%d]: %s to %u:%s:%d

A failure occurred trying to send a unicastmessage.

This failure is usually a result of not beingable to connect to the destination or anunexpected disconnect which couldindicate network issues. The specificLBM error message is given.

Gwd-6259-55: Message received withtoo many hops (255); dropping . Topic(%s) Source (%s)

A message was received by a Gatewaythat contains a high hop count (given inmessage).

The customer needs to evaluate theirnetwork topology.

Gwd-6259-56: Control messagereceived with too many hops (255);dropping . Origin: %s:%d

A message was received by a Gatewaythat contains a high hop count (given inmessage).

The customer needs to evaluate theirnetwork topology.

Gwd-6259-57: endpoint portal [%s] failedto create buffer (send topic controlpacket) [%d]: %s

When forwarding Topic Control Data, abuffer could not be allocated.

This is an LBM buffer create error. TheLBM error number and message is given.Please cross reference this information.

Gwd-6259-58: endpoint portal [%s] failedto send raw (send topic control packet)[%d]: %s

An error occurred while attempting tosend a message fragment.

This is an LBM send error. The LBM errornumber and message is given. Pleasecross reference this information.

Gwd-6259-59:tnwg_peer_psm_deliver_uim_packet_cb: portal [%s] failed to create buffer [%d]:%s

Failed to create a control buffer neededto send UIM across the Peer link.

Failure to create buffers usually indicatesa serious memory issue. Configurationsettings may be causing excessivememory allocation.

Gwd-6259-60:tnwg_peer_psm_deliver_cntl_packet_cb: portal [%s] failed to create buffer [%d]:%s

Failed to create a control buffer neededto send UIM across the Peer link.

Failure to create buffers usually indicatesa serious memory issue. Configurationsettings may be causing excessivememory allocation.

194 Chapter 8: UM Log Messages

Message Description Resolution

Gwd-6361-10: endpoint portal [%s]remote domain topic interest check failed[%d]: %s

An error occurred while checking topicinterest from remote domains.

Contact Informatica Support

Gwd-6361-100: failed to schedule thesource delete timer: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support.

Gwd-6361-101: Unable to enqueue asource entry onto the blocked queue: %s

An error occurred while attempting toenqueue data on to an internal queue.

Contact Informatica Support.

Gwd-6361-102: Unable to enqueue asource entry onto the wakeup queue: %s

An error occurred while attempting toenqueue data on to an internal queue.

Contact Informatica Support.

Gwd-6361-103: An error occurred whileprocessing a source notification: %s

An error occurred while attempting toprocess a source create/deletenotification.

Contact Informatica Support.

Gwd-6361-104: An error occurred whileattempting to create a source on topic[%s]

An error occurred while creating a proxysource. No data will be forwarded for thatsource.

Look for a prior error in the gateway logindicating what may have gone wrong.

Gwd-6361-105: Unable to enqueue asource entry onto the delete queue: %s

An error occurred while attempting toenqueue data on to an internal queue.

Contact Informatica Support.

Gwd-6361-106: psm %p failed to createsqn set [%d]: %s

An error occurred while attempting tocreate a sqn set, used for duplicatedetection.

Contact Informatica Support.

Gwd-6361-11: endpoint portal [%s] failedto schedule remote domain topic checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-111: an error occurred whileprocessing link state information fromanother gateway: %s

An error occurred while processing anincoming route information packet.

Contact Informatica Support.

Gwd-6361-112: unable to set pdm field[node_name] for link state propagation:[%s]

An error occurred while setting PDM fieldin an internal PDM message.

Contact Informatica Support.

Gwd-6361-116: failed to create aninternal domain list: %s

An error occurred while creating aninternal domain list.

Contact Informatica Support.

Gwd-6361-117: unable to read pdm field[%s]: [%s]

An error occurred while reading a PDMfield in a PDM message.

Contact Informatica Support.

Gwd-6361-118: unable to read pdm fieldvec [%s]: [%s]

An error occurred while reading a PDMfield vec in a PDM message.

Contact Informatica Support.

Gwd-6361-119: unable to set pdm field[%s] for link state forwarding: [%s]

An error occurred while setting a PDMfield in a PDM message.

Contact Informatica Support.

Gwd-6361-12: endpoint portal [%s]remote domain PCRE pattern interestcheck failed [%d]: %s

An error occurred while checking patterninterest from remote domains.

Contact Informatica Support

UM Dynamic Routing Log Messages 195

Message Description Resolution

Gwd-6361-123: portal [%s] could not findpath to domain %u. Dropping UIMpacket.

UIM traffic destined for a particulardomain arrived at a portal that is notsetup to forward to the domain inquestion.

Contact Informatica Support.

Gwd-6361-124: Received UIM packetbefore initial route calculationscompleted. Dropping.

UIM traffic was sent to the gatewaybefore it had completed it's first round ofroute calculations.

This can happen briefly when a gatewayis restarted. If the message persists,contact Informatica Support.

Gwd-6361-13: endpoint portal [%s]remote domain REGEX pattern interestcheck failed [%d]: %s

An error occurred while checking patterninterest from remote domains.

Contact Informatica Support

Gwd-6361-132: endpoint portal [%s]failed to schedule rcv_ctx recalc timer[%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-133: Received MIM packetwith no odomain header. Dropping.

MIM traffic was sent to the gatewaywithout an ODOMAIN header.

This is likely caused by running an olderversion of UM.

Gwd-6361-134: Received MIM packetwith no odomain header. Dropping.

MIM traffic was sent to the gatewaywithout an ODOMAIN header.

This is likely caused by a gateway versionmismatch.

Gwd-6361-14: endpoint portal [%s] failedto schedule remote domain pattern checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-15: endpoint portal [%s] failedto dup rcv attributes (rcv create) [%d]:%s

An error occurred while attempting toduplicate receiver attributes duringreceiver creation.

Contact Informatica Support

Gwd-6361-16: endpoint portal [%s] failedto set rcv attribute[source_notification_function] (rcvcreate) [%d]: %s

An error occurred while attempting to setreceiver attributes during receivercreation.

Contact Informatica Support

Gwd-6361-17: endpoint portal [%s] failedto lookup topic (rcv create) [%d]: %s

An error occurred while attempting tolookup a topic during receiver creation.

Contact Informatica Support

Gwd-6361-18: endpoint portal [%s] failedto create receiver (rcv create) [%d]: %s

An error occurred while attempting tocreate a receiver.

Contact Informatica Support

Gwd-6361-19: endpoint portal [%s] failedto alloc resolver topic message [%d]: %s

UM has failed to allocate requiredmemory for the purposes of constructingan interest list message.

Acquire more memory

Gwd-6361-20: endpoint portal [%s] failedto delete receiver (rcv delete) [%d]: %s

An error occurred while attempting todelete a receiver.

Contact Informatica Support

Gwd-6361-21: endpoint portal [%s] failedto dup wrcv attributes (wrcv create) [%d]:%s

An error occurred while attempting toduplicate wildcard receiver attributesduring wildcard receiver creation.

Contact Informatica Support

Gwd-6361-22: endpoint portal [%s] failedto set wrcv attribute

An error occurred while attempting to setwildcard receiver attributes duringreceiver creation.

Contact Informatica Support

196 Chapter 8: UM Log Messages

Message Description Resolution

[receiver_create_callback] (wrcv create)[%d]: %s

Gwd-6361-23: endpoint portal [%s] failedto set wrcv attribute[receiver_delete_callback] (wrcv create)[%d]: %s

An error occurred while attempting to setwildcard receiver attributes duringreceiver creation.

Contact Informatica Support

Gwd-6361-24: endpoint portal [%s] failedto set wrcv attribute [pattern_type] (wrcvcreate) [%d]: %s

An error occurred while attempting to setwildcard receiver attributes duringreceiver creation.

Contact Informatica Support

Gwd-6361-25: endpoint portal [%s] failedto create wildcard receiver (wrcv create)[%d]: %s

An error occurred while attempting tocreate a wildcard receiver.

Contact Informatica Support

Gwd-6361-26: endpoint portal [%s] failedto delete wildcard receiver (wrcv delete)[%d]: %s

An error occurred while attempting todelete a wildcard receiver.

Contact Informatica Support

Gwd-6361-27: endpoint portal [%s] failedto properly handle wildcard receivercreate [%d]: %s

An error occurred while attempting toprocess a wildcard receiver create.

Contact Informatica Support

Gwd-6361-28: endpoint portal [%s] failedto properly handle wildcard receiverdelete [%d]: %s

An error occurred while attempting toprocess a wildcard receiver delete.

Contact Informatica Support

Gwd-6361-29: endpoint portal [%s]received TransportOpts with no OTID forSourceName [%s] topic [%s], sourceignored (rcvdc create)

UM encountered a source with no OTID.This is likely caused by a versionmismatch with an old version of UM.

Resolve the version mismatch.

Gwd-6361-30: endpoint portal [%s] failedto create prm o_entry (rcvdc_create)[%d]: [%s]

An error occurred while attempting toprocess a delivery controller create.

Contact Informatica Support

Gwd-6361-31: endpoint portal [%s]unable to delete NULL src_clientd(rcvdc_delete)

UM encountered an unexpected NULLsource clientd while attempting to handlea delivery controller delete.

Contact Informatica Support

Gwd-6361-32: endpoint portal [%s] failedto properly handle a delivery controllerdelete [%d]: %s

An error occurred while attempting toprocess a delivery controller delete.

Contact Informatica Support

Gwd-6361-33: endpoint portal [%s]received advertisement for topic [%s]source [%s] with no transport options -this source will never be forwarded

UM encountered a source with notransport opts. This is likely caused by aversion mismatch with an old version ofUM.

Resolve the version mismatch.

Gwd-6361-34: endpoint portal [%s]received advertisement for topic [%s]source [%s] with no OTID - this sourcewill never be forwarded

UM encountered a source with no OTID.This is likely caused by a versionmismatch with an old version of UM.

Resolve the version mismatch.

Gwd-6361-35: endpoint portal [%s] failedto schedule src_ctx recalc timer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

UM Dynamic Routing Log Messages 197

Message Description Resolution

Gwd-6361-36: endpoint portal [%s] failedto duplicate src attr (src create) [%d]: %s

An error occurred while attempting toduplicate source attributes during sourcecreation.

Contact Informatica Support

Gwd-6361-37: endpoint portal [%s] failedto allocate source topic (src create) [%d]:%s

An error occurred while attempting toallocate a topic during source creation.

Contact Informatica Support

Gwd-6361-38: endpoint portal [%s] failedto create source (src create) [%d]: %s

An error occurred while attempting tocreate a source.

Contact Informatica Support

Gwd-6361-39: endpoint portal [%s] failedto flush source (src delete) [%d]: %s

An error occurred while attempting toflush a source prior to source deletion.

Contact Informatica Support

Gwd-6361-40: endpoint portal [%s] failedto delete source (src delete) [%d]: %s

An error occurred while attempting todelete a source.

Contact Informatica Support

Gwd-6361-41: endpoint portal [%s] failedto create raw buffer (send fragment)[%d]: %s

An error occurred while attempting tocreate a message buffer for sending.

Contact Informatica Support

Gwd-6361-42: endpoint portal [%s]unable to send: datagram size mismatch.transport_XXX_datagram_max_sizemust be properly configured. This is aconfiguration error.

Attempting to send a fragment that islarger than this egress portal's max size.

Resolve the datagram max sizemismatch

Gwd-6361-43: endpoint portal [%s] failedto send raw (send fragment) [%d]: %s

An error occurred while attempting tosend a message fragment.

Contact Informatica Support

Gwd-6361-44: endpoint portal [%s] failedto create raw buffer (IM) (send fragment)[%d]: %s

An error occurred while attempting tocreate a message buffer for sending.

Contact Informatica Support

Gwd-6361-45: endpoint portal [%s]unable to multicast immediate: datagramsize mismatch.transport_lbtrm_datagram_max_sizemust be properly configured. This is aconfiguration error.

Attempting to send a fragment that islarger than this egress portal's max size.

Resolve the datagram max sizemismatch

Gwd-6361-46: endpoint portal [%s] failedto multicast immediate raw (sendfragment) [%d]: %s

An error occurred while attempting tosend a message fragment.

Contact Informatica Support

Gwd-6361-47: endpoint portal [%s] failedto handle topic. An error occurred whileattempting to process local interest.

Contact Informatica Support

Gwd-6361-48: endpoint portal [%s] failedto handle pattern interest entry [%d]:[%s]

An error occurred while attempting toprocess remote interest.

Contact Informatica Support

Gwd-6361-49: endpoint portal [%s] failedto enqueue topic interest entry [%d]:[%s]

An error occurred while attempting toprocess remote interest.

Contact Informatica Support

198 Chapter 8: UM Log Messages

Message Description Resolution

Gwd-6361-5: endpoint portal [%s] failedto schedule remote domain topic checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-50: endpoint portal [%s] failedto allocate resolver buffer [%d]: %s

An error occurred while attempting toallocate a topic resolution buffer.

Contact Informatica Support

Gwd-6361-51: endpoint portal [%s] failedto generate portal list (topic res req) [%d]:%s

An error occurred while attempting togenerate a list of portals.

Contact Informatica Support

Gwd-6361-52: endpoint portal [%s] failedto allocate resolver buffer [%d]: %s

An error occurred while attempting toallocate a topic resolution buffer.

Contact Informatica Support

Gwd-6361-56: rm failed to join ctx thread,%s

UM was unable to join an internalthread.

Contact Informatica Support.

Gwd-6361-57: rm failed to join evqthread, %s

UM was unable to join an internalthread.

Contact Informatica Support.

Gwd-6361-6: endpoint portal [%s] failedto schedule remote domain topic checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-61: overriding 'interest' basedroute decisions on portal %d

Route decisions are now overriddenregarding whether or not to propagateinterest on the specified portal.

Don't set theTNWG_PORTAL_ROUTE_OVERRIDEenv variable.

Gwd-6361-62: overriding 'receiver'based route decisions on portal %d

Route decisions are now overriddenregarding whether or not to create areceiver on the specified portal.

Don't set theTNWG_PORTAL_ROUTE_OVERRIDEenv variable.

Gwd-6361-63: overriding 'source' basedroute decisions on portal %d

Route decisions are now overriddenregarding whether or not to propagatesources on the specified portal.

Don't set theTNWG_PORTAL_ROUTE_OVERRIDEenv variable.

Gwd-6361-67: portal [%s] failed to joinpsm evq thread, %s

UM has failed to join an event queuedispatch thread.

Contact Informatica Support.

Gwd-6361-69: portal [%s] psm evqlbm_event_dispatch() failed, %s

An error occurred while attempting toprocess events off an internal eventqueue.

Contact Informatica Support.

Gwd-6361-7: endpoint portal [%s] failedto schedule remote domain pattern checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-71: portal [%s] failed to joinprm evq thread, %s

UM has failed to join an internal eventqueue dispatch thread.

Contact Informatica Support.

Gwd-6361-72: TNWG PRM processingfailed [%d]: %s

An error occurred while attempting toprocess an internal interest notification.

Contact Informatica Support.

Gwd-6361-73: portal [%s] prm evqlbm_event_dispatch() failed, %s

An error occurred while attempting toprocess events off an internal eventqueue.

Contact Informatica Support.

UM Dynamic Routing Log Messages 199

Message Description Resolution

Gwd-6361-74: route recalculation took%u.%06u seconds

Running route recalculations took theindicated amount of time to complete.

Nothing. This is purely informational.

Gwd-6361-75: route recalculationbackoff has exceeded the specifiedthreshold

Your network topology has failed toconverge within the specified threshold.

Attempt to identify the gateway or peerlink that is causing the instability in yourtopology.

Gwd-6361-77: loop count == %d You're running a build of the gateway withTNWG_RM_LOOP_COUNT defined intnwgrm.c.

Contact Informatica Support

Gwd-6361-78: rm evqlbm_event_dispatch() failed, %s

An error occurred while attempting toprocess events off an internal eventqueue.

Contact Informatica Support

Gwd-6361-79: rm ctxlbm_context_process_events() failed,%s

An error occurred while attempting toprocess events on an internal context.

Contact Informatica Support

Gwd-6361-8: endpoint portal [%s] failedto schedule remote domain pattern checktimer [%d]: %s

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

Gwd-6361-81: TNWG PRM domainprocessing failed [%d]: %s

An error occurred while attempting toprocess an internal domain notification.

Contact Informatica Support.

Gwd-6361-84: unable to parse link statebuffer

An error occurred while deserializing anincoming link state packet.

Contact Informatica Support.

Gwd-6361-85: unable to read pdm field[node_name] for link state forwarding:[%s]

An error occurred while reading a field inan internal PDM message.

Contact Informatica Support.

Gwd-6361-86: unable to create neighborasl: %s

UM was unable to create an internal datastructure.

Contact Informatica Support.

Gwd-6361-87: unable to set pdm field[%s] for link state propagation: [%s]

An error occurred while setting PDM fieldin an internal PDM message.

Contact Informatica Support.

Gwd-6361-88: unable to set pdm fieldvec [%s] for link state propagation: [%s]

An error occurred while setting PDM fieldvec in an internal PDM message.

Contact Informatica Support.

Gwd-6361-89: unable to create pdmmessage for link state propagation: [%s]

An error occurred while creating internalPDM message.

Contact Informatica Support.

Gwd-6361-9: endpoint portal [%s]remote domain %s check ivl droppedbelow threshold of %d. Resetting to %d

Desired configuration for the interesttimeout threshold in conjunction with thecurrent number of symbols has causedUM to calculate a check interval lowerthan the threshold of 50 milliseconds.

Adjust the appropriate configurationparameters to check each symbol lessoften.

Gwd-6361-91: route recalculation istaking longer than the route infopropagation interval

Running route recalculations took longerthan the specified route info propagationinterval.

Adjust appropriate configuration options

200 Chapter 8: UM Log Messages

Message Description Resolution

Gwd-6361-93: shortest path from %u to%u not found

Unable to find an expected internal datastructure.

Contact Informatica Support.

Gwd-6361-94: failed to add node [%u] toan internal domain list: %s

An error occurred while creating aninternal domain list.

Contact Informatica Support.

Gwd-6361-97: psm %p failed topropagate a message [%d]: %s

An error occurred while attempting toforward a message.

Contact Informatica Support.

Gwd-6361-98: Unable to enqueue asource entry onto the wakeup queue: %s

An error occurred while attempting toenqueue data on to an internal queue.

Contact Informatica Support.

Gwd-6361-99: Unable to enqueue asource wakeup event on to an eventqueue: %s

An error occurred while attempting toenqueue a wakeup event on to aninternal event queue.

Contact Informatica Support.

Gwd-6814-10: invalid ingress-cost value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-11: egress-cost must not beblank

Must specify a valid numeric value.

Gwd-6814-12: invalid egress-cost value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-13: source-deletion-delaymust not be blank

Must specify a valid numeric value.

Gwd-6814-14: invalid source-deletion-delay value [%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-15: The late-join element hasbeen deprecated and will be ignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-16: The topic-purge elementhas been deprecated and will be ignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-17: The topic-interest-generate element has been deprecatedand will be ignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-18: The topic-domain-activityelement has been deprecated and will beignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-19: The pattern-purgeelement has been deprecated and will beignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-20: The pattern-interest-generate element has been deprecatedand will be ignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-21: The pattern-domain-activity element has been deprecatedand will be ignored

The specified element has beendeprecated.

Remove the element from the config file.

UM Dynamic Routing Log Messages 201

Message Description Resolution

Gwd-6814-22: size value [%s] forsourcemap is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-23: check interval value [%s]for remote-topic is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-24: max topics value [%s] forremote-topic is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-25: timeout value [%s] forremote-topic is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-26: check interval value [%s]for remote-pattern is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-27: max patterns value [%s]for remote-pattern is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-28: timeout value [%s] forremote-pattern is invalid

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-29: The topic-use-checkelement has been deprecated and will beignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-3: invalid min-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-30: The pattern-use-checkelement has been deprecated and will beignored

The specified element has beendeprecated.

Remove the element from the config file.

Gwd-6814-4: invalid max-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-5: invalid min-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-6: invalid max-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-7: invalid min-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-8: invalid max-interval value[%s]

The specified value is either non-numericor the value is out of range.

Please specify a valid value.

Gwd-6814-9: ingress-cost must not beblank

Must specify a valid numeric value.

Gwd-6873-1: endpoint portal [%s] failedto allocate resolver buffer [%d]: %s

An error occurred while attempting toallocate a topic resolution buffer.

Contact Informatica Support

Gwd-6945-1: Portal [%s] beganenqueueing data

The named portal began enqueueingdata due to LBM_EWOULDBLOCK.

This is an informational message only.The message traffic is higher than can behandled. Check config or network load.

202 Chapter 8: UM Log Messages

Message Description Resolution

Gwd-6945-2: Portal [%s] dropping datadue to high volume

The named portal is dropping data. Thisis due to the message queue being full ordisabled. Message is throttled and codemay be dropping at a higher rate thanindicated by log message. Check WebMonitor stats.

This is an informational message only.The message traffic is higher than can behandled. Check config or network load.

Gwd-6945-3: Portal [%s] completedflushing queue

The named portal completed dequeueingthe data previously enqueued.

This is an informational message only.The message traffic has slowed so thatthe queue could be emptied.

Gwd-7079-5: unable to create routemanager [%d]: %s

An error occurred while attempting tocreate an internal component.

Contact Informatica Support.

Gwd-7097-1: peer portal [%s] has justestablished a connection to gatewaynamed: [%s] with node id: %u

A peer connection has just beenestablished to the specified gateway.

Gwd-7097-3: peer portal [%s] failed toproperly connect to gateway with node id:%u [%d]: %s

The gateway failed to establish a logicalconnection to the gateway at the otherend of the peer link. The link will remainup, but no traffic will flow.

This is usually caused by having morethan one peer connection to the samegateway, which is an unsupportedconfiguration.

Gwd-7097-4: peer portal [%s] failed toproperly connect to gateway named: [%s]with node id: %u [%d]: %s

The gateway failed to establish a logicalconnection to the gateway at the otherend of the peer link. The link will remainup, but no traffic will flow.

This is usually caused by having morethan one peer connection to the samegateway, which is an unsupportedconfiguration.

Gwd-7122-1: Gateway named [%s] withnode id: %u has started.

Your gateway has just started.

Gwd-7136-1: Ultra Messaging Gatewayversion %s

Printed at startup.

Gwd-7136-2: %s Printed at startup.

Gwd-7136-3: EXPERIMENTAL BUILD -NOT FOR PRODUCTION USE

Printed at startup.

Gwd-7155-1: Gateways can not havemore than %d portals

The gateway had too many portalsspecified.

Specify fewer portals.

GwdApi-5688-4702: failed to set portalsource option [%s] to [%s]: %s

The portal was unable to set a sourceoption

GwdApi-5688-4703: failed to set portalreceiver option [%s] to [%s]: %s

The portal was unable to set a receiveroption

GwdApi-6103-0001: failed to set portalsource option [%s] to [%s]: %s

The portal was unable to set a sourceoption

GwdApi-6103-0002: failed to set portalreceiver option [%s] to [%s]: %s

The portal was unable to set a receiveroption

GwdApi-6361-110: unable to create pdmdefinition: %s

An error occurred while creating aninternal PDM definition.

Contact Informatica Support.

UM Dynamic Routing Log Messages 203

Message Description Resolution

GwdApi-6361-113: unable to add pdmfield definition [%s]: [%s]

An error occurred while adding a PDMfield to an internal PDM definition.

Contact Informatica Support.

GwdApi-6361-114: failed to create psmdelete q

UM has failed to create an internalqueue.

Contact Informatica Support.

GwdApi-6361-120: must not set the routerecalculation backoff interval greaterthan the route recalculation warninginterval

The backoff interval must be less than thewarning interval, otherwise the warningwill fire at least once for eachrecalculation.

Adjust the configuration.

GwdApi-6361-121: failed to propagatesource creation: %s

An error occurred while attempting topropagate the need to create a proxysource to another portal.

Contact Informatica Support.

GwdApi-6361-122: failed to propagatesource creation: %s

An error occurred while attempting topropagate the need to create a proxysource to another portal.

Contact Informatica Support.

GwdApi-6361-53: failed to create rm ctxattr: %s

UM was unable to create contextattributes.

Contact Informatica Support.

GwdApi-6361-54: failed to set rm contextoption [%s] to [%s]: %s

UM was unable to set the specifiedcontext attributes.

Contact Informatica Support.

GwdApi-6361-55: failed to create rm ctx:%s

UM was unable to create an internalreactor only context.

Contact Informatica Support.

GwdApi-6361-58: failed to create rm evqthread [%d]

UM was unable to create an internalthread.

Contact Informatica Support.

GwdApi-6361-59: failed to create rm ctxthread [%d]

UM was unable to create an internalthread.

Contact Informatica Support.

GwdApi-6361-60: unable to schedule rmtimer

UM was unable to schedule an internaltimer.

Contact Informatica Support.

GwdApi-6361-64: failed to create psmevq thread [%d]

UM has failed to create an internalthread.

Contact Informatica Support.

GwdApi-6361-65: failed to create psmwakeup q

UM has failed to create an internalqueue.

Contact Informatica Support.

GwdApi-6361-66: failed to create psmblocked q

UM has failed to create an internalqueue.

Contact Informatica Support.

GwdApi-6361-70: failed to create prmevq thread [%d]

UM has failed to create an internal eventqueue dispatch thread.

Contact Informatica Support.

GwdApi-6361-76: unable to schedule rmtimer

An error occurred while attempting toschedule an internal timer.

Contact Informatica Support

GwdApi-6361-80: could not inserto_entry into otid_list [%s:%d]

An error occurred while attempting toinsert a data entry into an internal datastructure.

Contact Informatica Support.

204 Chapter 8: UM Log Messages

Message Description Resolution

GwdApi-6361-82: unable to finalize pdmdefinition: [%s]

An error occurred while finalizing aninternal PDM definition.

Contact Informatica Support.

GwdApi-6361-83: unable to create pdmmessage for link state forwarding: [%s]

An error occurred while creating aninternal PDM message.

Contact Informatica Support.

GwdApi-6361-90: the specified gatewayname exceeds the max name length of%d

The gateway name is too long. Pick a shorter name.

GwdApi-6361-92: failed to propagatesource creation: %s

An error occurred while attempting topropagate the need to create a proxysource to another portal.

Contact Informatica Support.

GwdApi-6361-95: received a sourcedelete for an unknown source on topic[%s]

Unable to locate the source entry for thetopic in question.

Contact Informatica Support.

GwdApi-6814-1: topic interest maxinterval must be greater than the mininterval

The topic-interest min-interval must beless than the topic-interest max-interval.

Set the min/max intervals appropriately.

GwdApi-6814-2: pattern interest maxinterval must be greater than the mininterval

The pattern-interest min-interval must beless than the topic-interest max-interval.

Set the min/max intervals appropriately.

GwdApi-7097-2: duplicate adjacent nodeid detected: %u

A portal is adjacent to either a topicresolution domain or another gateway towhich another portal on this gateway isalready adjacent.

Adjust configuration so that no twoportals on any gateway are adjacent tothe same topic resolution domain or thesame gateway.

GwdApi-7582-10: failed to get portalsource transport option (%s)

The portal was unable to get a sourcetransport option.

This is an LBM error. Please refer to thegiven LBM error message.

GwdApi-7582-3: the DRO does not allowLBT-SMX to be the default sourcetransport.

The DRO does not support the LBT-SMXsource transport. This is a configurationfailure and the DRO will exit.

The customer should use a differentsource transport when the DRO isconfigured. Please reconfigure thesource transport type.

UM Dynamic Routing Log Messages 205