Conference azur::mcc

    hi Brad,
    
    thanks for your note.
    
    Here's some background of what's going on.  Notification matches 
    entity events to domain members by the entity's identifier.  Because
    the DOMAIN FM identifies its members by fullname while the AM may
    return event information under a different identifier, notification
    must find a way to translate between the two.
    
    the notification FM has two choices:
    
    	1.  to get identifier information initially when the notification
    	    is getting setup.
    
    	2.  to get identifier information per event
    
    We chose the former, because we believe the latter to be ultimately
    more expensive.  
    
    At this time, this information can only be obtained from the entity.
    
    We are looking into ways to streamline the notification startup.
    
    Another way to make your notification request is to create and enable a
    domain rule for (OCCURS(NODE4 * CIRC * ANY EVENTS)) and request the
    default notification (NOTIFY DOMAIN D1).  The problem with this
    approach is that you will receive notification of ALL NODE4 * CIRC *
    events (eg - for node4's that may not be in your domain).
    
    Hope this helps some.
    
    -s
    
    

Hi again,

I must admit that this is a BIGGIE from an implementation standpoint. Adding
the global wildcard to ALARMS may turn out to be a valid solution to the
problem. BUT... notification needs to resolve this as best they can also.
    
>    Here's some background of what's going on.  Notification matches 
>    entity events to domain members by the entity's identifier.  Because
>    the DOMAIN FM identifies its members by fullname while the AM may
>    return event information under a different identifier, notification
>    must find a way to translate between the two.
 
Can't this be done thru local MIR or DNS [although I'm not convinced that
would be any faster :-)]? Do you need to determine the specific child 
entities or can you just work with the global names and *plug* in the
child name as the event comes in? Would this still create a resource issue?
   
>    the notification FM has two choices:
>    
>    	1.  to get identifier information initially when the notification
>    	    is getting setup.
>    
>    	2.  to get identifier information per event
>    
>    We chose the former, because we believe the latter to be ultimately
>    more expensive.  
 
That's your call, but if users DON'T use it because it takes too long to
start up, then the function won't translate to revenue as a usable feature.
  
>    At this time, this information can only be obtained from the entity.
>    
>    We are looking into ways to streamline the notification startup.
 
Glad to see it getting attention but I hope it has sufficient priority to
be resolved.
   
>    Another way to make your notification request is to create and enable a
>    domain rule for (OCCURS(NODE4 * CIRC * ANY EVENTS)) and request the
>    default notification (NOTIFY DOMAIN D1).  The problem with this
>    approach is that you will receive notification of ALL NODE4 * CIRC *
>    events (eg - for node4's that may not be in your domain).
    
I will definitely try this as soon as I get my DNA4 AM working again. But I
am a little confused, if alarms are bound by a domain why would I receive
notification of events from entities not within any of our domains? Although
the point is moot because it takes effort and resources to set up the SINKS
and therefore *nothing* will be sent to us unless we want it.

thanks for info,
brad...    
    

   >> if alarms are bound by a domain why would I receive notification
   >> of event from entities not within any of our domains?
    
    The AM that ALARMS calls can ignore the IN DOMAIN qualification.
    
    So a call like SHOW <entity> * ALL COUNTERS, IN DOMAIN x
    may return counters for Every instance of the entity and ALARMS
    won't know the difference.
    
    aud...
    

    Brad,
    
    As to your comment about priorities, the streamlining is our number
    1 priority. Stella has been, and will continue, to work on this as her
    top priority in the notification space. Note thought that Stella will
    be moving over onto the OSI AM slowly over the next 2 months.
    
    Your questions have triggered off a whole new line of ideas, I thought
    you we be interested in some of them.
    
    One of the items you mentioned was the use of the MIR. That got us
    thinking about how we could use the MIR once we knew what the primary
    identifier was for an entity class. In time the ECO proposal for
    explicitly specifying the primary identifier will be ready and the
    dictionary will contain the information, but for now the only want to
    guarantee what the primary identifier is for any class is to go out and
    ask the AM to do a show. Now comes the big but! what your question
    triggered was the idea that what if we only did one show, and then
    using the identifier code that was returned, we go out to DNS and do a
    get on the alternate identifier with the matching code/datatype. This
    would most likely be faster since it would not require the network
    connections, and it would make our handling of partially registered
    instances more robust.
    
    Well, no guarantees, but this looks like a potentially large win. We
    are looking into the implementation of it now.
    
    thanks!
    

Glad to see ideas coming out but I do have one warning with using the MIR
to get children info (if that's what you're looking to do). If the entity
gets reconfigured then it would also need re-registration. This may not be
a good thing. Also, if you go to DNS for all this info you may not gain
either because if the object is held on a replica out on the network (probably
close to the entity itself!!) you still deal with the delays you're trying
to avoid. Private DNS of course will see great gains.

good luck,
brad...

    we would only be querying the MIR for global entity information. We
    request all children info directly from the AM. So far preliminary test
    show that the speed up is going to be well worth the effort to
    implement it.
    
    Thanks for the ideas.
    

Hi Jill/Notify team,

>    we would only be querying the MIR for global entity information. We
>    request all children info directly from the AM. So far preliminary test
>    show that the speed up is going to be well worth the effort to
>    implement it.
    
>    Thanks for the ideas.
    
I just did some more testing with the t1.2.7 kit in this area. What was taking
20 minutes in t1.2.4 is now taking 3 minutes to start up each event now. We
have a winner.

thanks for the ears,
brad...

    thanks for testing it. We have been working hard to get things down
    so that we really can be scalable in v1.2. Your measurment shows
    and 800% improvement!
    
    great, I'm glad you noticed.