slaclab / aida-pva Goto Github PK

• When SLC_BPM provider is first called it fails first time
• Then it usually succeeds

This is the sequence:

1. Unexpected exception caught while calling RPCService.request(PVStructure): Message number 00000000; UnableToGetDataException; while making BPM acquisition
2. channel DISCONNECTED
3. ++ works fine

• Verify if still the case - may be removed when correct SUBMIT file is created #13

Intermittently when certain requests are made the EPICs framework reports Invalid header received from client warning. And disconnects the request, returning no results.

AIDA GetValue: NDRFACET//BUFFACQ[NRPOS=180, BPMD=57, BPMS=["BPMS:LI11:501", "BPMS:LI11:601", "BPMS:LI11:701", "BPMS:LI11:801"]] => TABLE:structure
Oct 7, 2021 8:51:56 AM org.epics.pvaccess.impl.remote.codec.AbstractCodec processHeader
WARNING: Invalid header received from client /134.79.120.187:43422, disconnecting...

• Note that this happens intermittently for some requests
• The requests it happens with seem to be limited to a small fixed set

• Investigate

• Remove all wildcard matches in channel files so all channel files contain the full list of channels they support

• Change the reading of config logic in aida-pva to accommodate changes required in #1
• Change the merging of config logic in aida-pva to accommodate changes required in #1
• Change JNI api to accommodate changes

• Copy existing submit scripts for legacy AIDA services
• Modify making sure to replace process names with new process names
• Run and test services locally, then in DEV, then on PROD
• Update/Create com files
• Make sure AIDA-PVA services can be started/stopped by warmslcx

• In SearchHandler when matching channels as well as using straight matches and wildcard matches also use the extended parameter matches to match channels.
• If extended parameters exists then they MUST be matched
• Translate some TYPE values such as SCALAR, SCALAR_ARRAY, ANY to properly match on the actual value provided in the request. SCALAR means any scalar type, SCALAR_ARRAY means any scalar array type, and ANY means any type. Any of these mean that a TYPE parameter MUST be included in the request

• Show fully configured and deployed AIDA-PVA
• Show full documentation
• Run full test suite
• Get approval for work

• Change format of channels files to add a section for argument config
• List arguments in the new section and read them by framework before getting to native code
• If any argument is specified that is not in the valid arguments list (or TYPE or VALUE) then reject the call

• For each of SLC, SLC_BPM, SLC_BUFFACQ, SLC_KLYS, SLC_MAGNET, SLC_MOSC, and SLC_UTIL
• Create CMS repository
• Copy in single C source file
• Copy in single C header file
• Copy in single Channels file
• Copy in single OPT file
• Copy in BUILD file which will create the library and place it in the same place as AIDA -PVA jars (see #12)

• When registering a channel postfix with &VALUE if one of the parameters name is VALUE
• When registering a channel postfix with &TYPE=<type> if one of the parameters name is TYPE and use it's value as the

• Improve PV -> Argument processing by including PVStructure to JSON translation
• Allow infinite depth to structures in the translation

• Update C Argument structure to handle the embedded floats and doubles (add new fields)
• Updated the getFloatArgument() and getDoubleArgument() functions to pull from the appropriate fields

• Update ascanf() function to pull out the embedded floats from the new Argument structure in #7

• Complete documentation

• Change aida-pva: Simply change all ‘//‘ into ‘:’ when accepting channel URIs
• Change all aida-server-helper functions manipulating URIs to expect only colons.
• Change all channel.YML files to contain only colons
• Verify provider implementations don't rely on legacy format

• Remove all C code from repository (will have already been moved to CMS see #10 and #11)
• Recompile and verify
• Update instructions on how to build library
• Build library using procedure which will copy library to standard location of legacy AIDA jars SLCLIBS

• Remove all wildcard matches in channel files so all channel files contain the full list of channels they support

• Separate out AIDA-PVA-MODULE code into (headers, and source) from rest of code in C project
• Move headers to standard header location for AIDASHR in CMS
• Move source to standard source location for AIDA-PVA-MODULE in CMS
• Commit and go through full process to release a new AIDASHR containing AIDA-PVA-MODULE

• Change format of channel.yml from one where channels are enumerated then under each the configuration is stated, to one in which the configuration types are enumerated and the channels served by each configuration group are enumerated underneath

• PVStructures returned for tables currently contain labels, and names as well as the data.
• This issue concerns adding units

• Add Units to config format for tables
• Update all CHANNELS.YML files with the units where appropriate
• Update the Fields to contain an optional units element
• Use the new units element to populate the PVStructure on return in getFieldsNamesLabelsAndTypes() which will be renamed to getFieldsNamesLabelsTypesAndUnits()
• Update aida-pva-tests to pull out the new units information into a new heading row

• If a Float is encountered in an argument then add an extra argument under floatArguments section
• If a Double is encountered in an argument then add an extra argument under doubleArguments section
• Along side that entry put the full path to the variable within the arguments e.g. value or value.data[0].num
• Store the unchanged ieee float/double there.

Intermittently SLC service dies with segmentation violations occurring during Java garbage collection

AIDA GetValue: XCOR:LI03:120//LEFF[TYPE=FLOAT] => FLOAT:scalar
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000000237F7DB4, PC=00000000000B55BC, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
 image    module    routine             line      rel PC           abs PC
JAVA$FVM_SHR  COPYGC  gc_unregister_reference
                                       59853 0000000000006BAC 00000000000B55BC
JAVA$FVM_SHR  CLASS  remove_from_cmap  48019 000000000000A9EC 00000000000AD8FC
JAVA$FVM_SHR  CLASS  class_undefine_class
                                       48161 000000000000AFC8 00000000000ADED8
JAVA$FVM_SHR  CLASS  unload_classes    48354 000000000000B628 00000000000AE538
JAVA$FVM_SHR  COPYGC  garbage_collect  58346 000000000000322C 00000000000B1C3C
JAVA$FVM_SHR  COPYGC  allocate_chunk   57649 0000000000001AA8 00000000000B04B8
JAVA$FVM_SHR  COPYGC  gc_malloc_more   57401 000000000000104C 00000000000AFA5C

• This is independent of any operation that is being carried out
• It appears to be because some memory that the Java VM thinks is no longer in use, is actually still being used.

• Verify that all of the correct procedures for releasing memory after JNI calls have been followed
• Verify all entry and exit points in NativeChannelProvider.c