CA client does not indicate to the monitor callback what event mask bit(s) triggered the event

[Jeff Hill]

This discussion between Dirk Zimoch and Ralph Lange
sums up the situation.

> 1. The archiver gets a lot more data. Is ADEL
> ignored through the gateway? Does the gateway
> make DBE_VALUE monitors from DBE_LOG monitors?
> I tried '-mask avl' but that didn't help.
> If the gateway does not preserve the type of
> monitor (v or l), why not?

Any CA client can set up a monitor specifying an
event mask telling the server which kind of events
it is interested in.

Alas, when the data update messages come in, CA
does not tell the client for what reason a particular
update was sent.

The Gateway can set up its IOC side connection for
multiple event types, but has to distribute the event
to all the Gateway's clients because the upcoming
data has no tag which event type triggered the update,
so the Gateway simply has no way of knowing which
clients to send it to.

There's a workaround that was implemented a while ago:
the Gateway takes a command line argument specifying
what value event mask it should use on its IOC side.

With that trick e.g. an archiver can be pointed
to a special Gateway that is started with '-mask l'
to see only DBE_LOG updates.

The appropriate extension/change of the CA
protocol (tagging the data update with the event
types that triggered that update) is on the list
for the next major CA update.

Additional information:
Thanks to Dirk Zimoch and Ralph Lange for identifying the issue

Original Mantis Bug: mantis-104
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=104

[Jeff Hill (johill-lanl)]

On Wed Oct 19 2011 01:34:02 GMT+0200 (CEST), Martin Konrad
<email address hidden> wrote:
> It's possible to build cagateway on Debian/Ubuntu against Michael
> Davidsaver's Debian packages. Just make sure you have epics-pcas-dev
> installed.
>
> I still don't understand why casCtx.h is included by cagateway while it
> is not installed into the include directory of base. To me this seems to
> be a bug either in cagateway or base. Handling this situation becomes
> more difficult with 3.15 because the file has been moved to another
> directory in this revision. Can someone help to resolve this issue? Does
> it make sense to add this file to the include directory in 3.15? This
> would make the epics-pcas-dev package unnecessary for 3.15+, too.

Konrad,

thanks for your efforts!

I also stumbled over the CAS include issue. Have a look at
   http://www.aps.anl.gov/epics/core-talk/2011/msg00065.php
to see the (still current) state of discussion.

Michael was helping by adding the epics-pcas-dev package as a quick
workaround until a final fix is available.

Cheers,
~Ralph

[Jeff Hill (johill-lanl)]

Also,

http://www.aps.anl.gov/epics/core-talk/2011/msg00065.php

[mdavidsaver (mdavidsaver)]

While useful, at this point I don't see ever being implemented. This issue can be reopened if the situation changes.