QSRV 2 #37
QSRV 2 #37
Conversation
|
❌ Build pvxs 1.0.851 failed (commit 606e2a77a3 by @mdavidsaver) |
|
❌ Build pvxs 1.0.856 failed (commit 5d8737676b by @mdavidsaver) |
|
❌ Build pvxs 1.0.859 failed (commit b8d6bcddf0 by @mdavidsaver) |
|
❌ Build pvxs 1.0.861 failed (commit 71e3ea4120 by @mdavidsaver) |
mdavidsaver
force-pushed
the
qsrv
branch
2 times, most recently
from
ba68874
to
a124ddc
Compare
|
❌ Build pvxs 1.0.869 failed (commit 1aba651cea by @mdavidsaver) |
|
✅ Build pvxs 1.0.869 completed (commit 1aba651cea by @mdavidsaver) |
|
Hi! Are there any attention points I should focus on? Things to stress test? |
mdavidsaver
force-pushed
the
qsrv
branch
2 times, most recently
from
93136b5
to
4ee3edd
Compare
This is a good question for which I don't have a simple answer. The areas where I can imagine problems include:
Especially the odd corners of group mappings and other
I expect that performance with a single client will be similar to QSRV1. However, the PVXS client and server don't use as many threads as pvAccessCPP, so there is a potential for performance regression with a large number of clients.
This was (and is) a common bug with the pv*CPP modules. Particularly those were the "leak" is cleaned up on exit, but grows without bound in a long running process. The kind which are "invisible" to tools like valgrind. |
|
✅ Build pvxs 1.0.879 completed (commit 4bf6e46f5a by @mdavidsaver) |
…iption not client connection
mdavidsaver
force-pushed
the
qsrv
branch
2 times, most recently
from
7546dde
to
ff4abff
Compare
I have added a set of three IOC shell commands to help with monitoring long term resource usage: eg. the delta after a client monitoring one PV has disconnected. |
|
At this point I am satisfied that with QSRV2 runtime disabled (the default) current users will not see a regression. Even in the pathological case where both libpvxsIoc and libqsrv (from pva2pva) are loaded at the same time. So this meets my criteria for merging and releasing this code as a "feature preview". |
ioc: check for mis-matched onStartSubscription()/onDisableSubscription() ioc: fix subscription lifetime ioc: catch exceptions in dbEvent callbacks ioc: avoid unnecessary virtual ioc: minor ioc: fix qsrv -S ioc: qsrvGroupSourceInit() catch+log ioc: runOnServer avoid std::function ioc: cleanup and simplifications. Avoid some redundant std::map lookups. Make Group partially const to prevent implicit ctor. ioc: avoid typedefs only used once ioc: overhaul Group::show(). shows triggers ioc: MappingType ioc: pvxsgl -> pvxgl ioc: separate group config singleton from server singleton ioc: remove unnecessary forward declarations ioc: restructure pvxsInitHook ioc: qsrv runtime disable by default ioc: compat w/ older Base ioc: link pvxsIoc w/ DB libs ioc: Channel proper detection of invalid PV ioc: no need to keep vector<dbCommon*> around ioc: fix initial group update for mappings w/o dbChannel ioc: redo testing split out group tests, only run with Base >= 7.0 ioc: minor ioc: loc_bad_alloc ioc: avoid symbol/DTYP clash with pva2pva ioc: test record alias in group json ioc: test put failure when SPC_NOMOD and DISP=1 ioc: test channel filters ioc: unnecessary capture ioc: avoid sharing Value between multiple subscriptions It is possible to create two subscriptions through the same channel. ioc: group subscription include queueSize ioc: eliminate unused atomicMonitor ioc: consolidate GroupSource::get() avoid some indirection ioc: pvRequest override of atomicPutGet ioc: fix group non-atomic put ioc: test asTrap hooks ioc: test putOrder also sets field order ioc: simplify GroupConfigProcessor::loadConfigFiles() Also ensure that groupMapMutex is held ioc: testqgroup cover JSON def. ioc: dbLoadGroup() use macros ioc: pvxsl() take integer argument ioc: display.form and info(Q:form ioc: "NO_ALARM" -> "" ioc: use dbServer at least for informational callbacks. ioc: consolidate createRequestAndSubscriptionHandlers() ioc: eliminate ChannelAndLock properties dbChannel doesn't need a separate DBManyLock ioc: test that putOrder also controls field order ioc: MappingType -> MappingInfo Handle info(Q:time:tag Add +type:"const" ioc: cleanup includes ioc: test dbNotifyCancel() ioc: inline checkForTrailingCommentsAtEnd()
Allow for use by pvxsIoc
inline runOnServer(), which shouldn't re-throw anyway
|
✅ Build pvxs 1.0.886 completed (commit 1a05e2338f by @mdavidsaver) |
|
Merged. Please continue to report test results here. Open issues for any bugs encountered. |
The rewrite of QSRV using PVXS.
Current Status: Alpha. Testable, but lacking features. Principally PVA links.
My compatibly target for the QSRV functionality is Base
>= 3.15for Single PV, and>= 7.0for Group PV. Lack of support for Group PV with3.16is only a case of my not spending the time to add#ifdefs and testing.Following the pattern of
pvget -> pvxget, this branch adds asoftIocPVXexecutable.QSRV functionality is added to the existing
libpvxsIoc.solibrary when available (aka.> 3.14). So the build time instructions don't change. However, while the PVXS server is started duringiocInit, at the moment the database interactions must be explicitly enabled by setting:If all goes well
iocInit()will print:Open Questions:
TODO:
softIocPVXpaths w/ Base 3.15info(Q:time:tag, ...display.formanddisplay.precision. cf. Add display.precision and .format pva2pva#19DISPhandling. cf. DISP field ignored in pvAccess pva2pva#33putOrder. cf. Allow qsrv fields to be generated in parse order pva2pva#53dbServer. cf. QSRV: Please register with the dbServer API pva2pva#18dbLoadGroup()w/ macrosrecord._optionsfor monitor/getdbNotifyCancel()pva2pva issues already addressed:
$modifier is enough to trigger long string handling for link and string fields. cf. info() to mark waveform w/ FTVL=CHAR as "long string" pva2pva#17 and Support for long DBF_STRING fields pva2pva#22structuremapping works as intended/documented. cf. QSRV specify struct ID w/o mapping pva2pva#47 and+type:"structure"does not work as documented. pva2pva#49Added features:
dbLoadGroup()accepts macros.