DDR for services
We could add:
# # This will make each ATMI client/server to parse ndrxconfig.xml # NDRX_USEDDR=Y
Then we could have "<services>" tag and "<routing>". the groups could be numberic (like rmid).
for these special services, we could advertise them with "<service_name>,<group_id>".
Thus if user makes "tpadvertise"/"tpunadvertise" we could use "rmid" and make two advertise calls one for common services and another for group shared.
#4 Updated by Madars about 2 years ago
ndrxd whould copy the rules to shared memory block, from start to finish (with RWLOCK installed). Binaries at tpinit point, would read the shared mem blocks, compile the rules and build the in-memory hash list of services. Then at tpadvertise or tpcall/tpforward/connet point we lookup the hash list, check the rules and detect the target group.
- Status changed from New to Resolved
- % Done changed from 0 to 100
- Implemented <services>/<service> tag and <routing>/<route> tags to enable DDR for services.
- Updated libraries to support additional service advertise in case if NDRX_RTGRP environment is set.
- Support dynamic on the fly config reload via xadmin reload.
- Implemented automatic transaction support for servers.
- Added APIs: tpsprio(3) and tpgprio(3) for priority handling.
See ndrxconfig.xml(5), ex_env(5) and xadmin(5) man pages.
With this release, two additional shared memory segments are added to Enduro/X (created at startup).