Same messageId being registered multiple times: Server.NewEventIndication

MIP
, , ,
1

MIP LOG getting a lot of these…

Same messageId being registered multiple times: Server.NewEventIndication

QUESTIONS:

  1. Is it okay to register Server.NewEventIndication in different applications?
  2. Does “Same messageId being registered multiple times” mean by one application, or is it wrong to register the same messageId but from different applications?
  3. In other words, please provide a fuller description of what that error means.
public void set_NewAlarm(bool turnOn)
{
  if (turnOn && _obj2A == null)
  {
    _obj2A = _messageCommunication.RegisterCommunicationFilter(NewAlarmMessageHandler,
        new CommunicationIdFilter(MessageId.Server.NewAlarmIndication));
  }
  else if (_obj2A != null)
  {
    _messageCommunication.UnRegisterCommunicationFilter(_obj2A);
    _obj2A = null;
  }
}
2
  1. Yes
  2. One application. Note however that if you use this in a plugin there might be another plugin subscribing to the same, and this will trigger the warning. I believe it is logged as an error, it would have been better if the Smart Client (in case the plugin is in that environment) could make sure multiple plugins could share a subscription, so the design is not optimal.
  3. The error / warning was introduced when cases were seen where new subscriptions were spawned in a high rate causing issues. If you see the error just verify that you do not register more of these than you need. Basically the error means that the application is doing the registration or subscriptiuon on this message more than once. The error can safely be ignored if you establish that you will not raise indefinite of these by some logic loop or similar.
3

That helps a lot. Thanks.

I get his idea, but I’d like to know an even clearer suggestion.

Do you mean by “multiple plugins”:

  1. one plugin that is dragged into view multiple times, or

  2. does multiple plugins mean, fully different plugins, or

  3. both (1) and (2)?

Are you suggesting that we: to support several completely different plugins requesting the same messages, that we should implement our own background plugin to service our different plugins. Or when you said, “make sure multiple plugins could share a subscription”, did you mean the Milestone service should be changed by Milestone to handle this?

Sorry if I’m drawing on the issue too long, and just let it be the way it is for now.

4

Good example. If you have a viewitem plugin and you subscribe to NewEventsIndication (or another message) in each instance you have the situation that Milestone has intended to warn against. If you see the samples that does use NewEventsIndication they subscribe from a background plugin ensuring to subscribe only once.

In my answer I think I imagined full plugins covering maybe multiple plugin items, but as you can see above it is actually more accurate to think how often you instantiate something that will initiate a subscription.

When I said “make sure multiple plugins could share a subscription” I meant Milestone developing better functionality for this. Only Milestone can ensure something being reused across multiple plugins from multiple vendors.

I would like to emphasize that multiple subscriptions from various sources is not a big issue, when we have seen issues is when we see is when the number of subscription can rise to very high numbers.