Skip to content

Add counters for total puts and burst#16

Merged
simon-ess merged 10 commits intoepics-modules:masterfrom
henrique-silva:add-counters
May 30, 2024
Merged

Add counters for total puts and burst#16
simon-ess merged 10 commits intoepics-modules:masterfrom
henrique-silva:add-counters

Conversation

@henrique-silva
Copy link
Contributor

@henrique-silva henrique-silva commented Mar 9, 2023

The total counter is being displayed in all information levels. My reasoning for this is that this is a basic information that would be useful to get alongside the server information on the base information level.

Implements #11

@anjohnson
Copy link
Member

This new functionality looks great, thanks for doing this. There are some tests for the JSON implementation in the test directory, have you tried running them with your changes? Would you be able to extend them to check the new functionality as well?

The only request I have for your changes is to use the name burst instead of burst_count in the generated output logs, I like using short but meaningful names in specific cases like this.

@henrique-silva
Copy link
Contributor Author

henrique-silva commented Mar 10, 2023

The current tests for the JSON logger run okay, since it doesn't check for extra fields in the log message (maybe it should?).

I'll extend the tests for the burst checking (possibly in another PR, due to time availability).

@simon-ess
Copy link
Contributor

In general LGTM: is there any chance however that one might want this information from outside of the IOC? At the moment it seems that the only way to get this info is to be directly logged into the IOC shell. One could add a db record that could hold this information as well, perhaps?

@ralphlange
Copy link
Member

Sounds like an iocStats topic?!

@simon-ess
Copy link
Contributor

It could be, but that adds a dependency between iocstats and caputlog that need not be there.

@ralphlange
Copy link
Member

ralphlange commented Feb 26, 2024

Not sure if that opens a can of worms...

Well, many EPICS modules have health and stats monitoring. If they don't, they should.
Should all of that be somehow plugged into iocStats? With that, the dependency would be the other way: caPutLog-stats needs iocStats.
Or should iocStats rather be a Base mechanism that other modules can add their things to?

@simon-ess
Copy link
Contributor

That is a can of worms! 😄

@anjohnson
Copy link
Member

anjohnson commented Feb 26, 2024

Doesn't iocStats already handle checking whether the sequencer is present or not at runtime? APS has been using this code to do that for years, but I see it's in our own iocStd module, not in iocStats:

/* seqcaStats() is part of the sequencer, which might not be loaded */
#ifdef vxWorks
    #include <epicsFindSymbol.h>
    static void noSeq(int *pcount, int *pdiscon) {}
    /* The real seqcaStats() function is part of the sequencer, but
     * might not be loaded in this IOC.  We look it up at runtime,
     * cacheing the pointer if found, and call it if we found it.
     */
    static void seqcaStats(int *pcount, int *pdiscon) {
        static void (*seqcaStatsFunc)(int *, int *) = NULL;

        if (seqcaStatsFunc == NULL) {
            seqcaStatsFunc = epicsFindSymbol("seqcaStats");

            if (seqcaStatsFunc == NULL) {
                /* sequencer not loaded, use dummy */
                seqcaStatsFunc = noSeq;
            }
        }
        seqcaStatsFunc(pcount, pdiscon);
    }
#else
    /* everything else supports pragma weak */
    extern void seqcaStats(int *, int *);
    #pragma weak seqcaStats
#endif

Adding a plug-in mechanism to Base is probably better in the long run, but this works with existing Base versions.

@simon-ess
Copy link
Contributor

@anjohnson, if there are no issues with this I would like to merge this in. The separate question about a universal mechanism to have health of IOCs aside, of course 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants