4 Replies Latest reply on Aug 15, 2013 3:56 AM by djohnstone@informatica.com

    Detecting Topic Resolution Completion

    New Member

      Is it possible to tell when the topic resolution has completed when using multicast transport?

       

      The knowledgebase article here: https://communities.informatica.com/infakb/faq/5/Pages/80181.aspx states:

      "If you want your application to run quickly when topic resolution has completed quickly, yet you want your application to still work (if more slowly) when topic resolution takes more time, it's best to code your application to discover when topic resolution completes rather than to predict when it should be complete."

       

      The same article refers to the lbmprice.c example which I have looked at but can't see anything that specifically detects that topic resolution has completed.

       

      An example of my problem:

       

      Create receiver on topic "B".

      Send message to another process on topic "A", asking it to publish data on topic "B".

       

      In this case it is possible for the other process to start publishing on "B" before our new receiver has completed topic resolution and we miss some messages.

      What I would like to do is create the receiver and then wait until the topic resolution has completed before asking the other process to start publishing data, is that possible?


        • 1. Detecting Topic Resolution Completion
          New Member

          In terms of the .NET API, I believe you can register an LBMReceiverCallback in your call to the context's createReceiver(), then in the callback, check if the type of LBMMessage you received (by calling it's .type() method) is equal to LBM.MSG_BOS. The BOS message is defined as "Beginning of Transport Session (source connection established) (data received)" and I believe is only received after topic resolution is completed.

          • 2. Detecting Topic Resolution Completion
            New Member

            We strongly recommend not using the BOS message to decide if a receiver is ready to receive messages from a source. 

             

            The BOS event is a transport event, and is not for a specific source or topic. If a receiver joins a transport and receives a message for any of the topics that are being published on the transport, it will log a BOS in its receiver callback. This is telling the app that the receiver has successfully joined the transport, but gives no indication as to whether the source has been plumbed to the transport.

             

            To solve the problem that I believe you're asking, you need to consider using the UM Request/Response model so that a source can send out a request to a receiver, and when it receives a response, it will have confirmed that the receiver is ready to receive on that specific topic and the source can then start publishing data messages.

            • 3. Detecting Topic Resolution Completion
              New Member

              David - in your proposed solution:

              1) To clarify: are you suggested an application-level request/response (rather than something built into the API)  ?

              2) Is it guaranteed that that the receiver would get the initial request ?  or is there a chance that it might arrive before the topic resolution had completed, causing the receiver to miss it  ?  

              3) (or are you suggesting that the source keeps sending the initial request at intervals until the receiver responds to indicate readiness?)

              • 4. Detecting Topic Resolution Completion
                New Member

                Hi,

                 

                Thanks for your follow-up questions.

                 

                1. I mean using the UM Request-Response Model, which you can find details of in the UM Documentation under Ultra Messaging Concepts > UMS Features > Request/Response Model.
                2. No, you're correct in that the initial request may be lost or arrive before topic resolution has completed, or even that the source times out before the reply is received.
                3. Exactly, be prepared to send multiple requests until a response is successfully received, although it's unlikely that you will need to send more than two requests.