Hi Mahesh, In the OpenSAF_extensions_PR, it stated clearly how to enable extended SaNameT in application at 4.3 section. I am wondering it is redundant to re-state such info in every services that has Long DN support.
Regards, Vu > -----Original Message----- > From: A V Mahesh [mailto:mahesh.va...@oracle.com] > Sent: Friday, July 8, 2016 11:42 AM > To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; > lennart.l...@ericsson.com > Cc: opensaf-devel@lists.sourceforge.net > Subject: Re: [PATCH 1 of 1] log: Readme file for long DN support [#1315] > > Hi Vu, > > It seems this README doesn't explained , how to enable > SA_ENABLE_EXTENDED_NAMES on a node, > > if some application is creating an app stream ( NOT using saflogger tool > ) DN is longer than 255 characters in length. > > -AVM > > On 7/4/2016 8:36 AM, Vu Minh Nguyen wrote: > > osaf/services/saf/logsv/README_LONGDN | 138 > ++++++++++++++++++++++++++++++++++ > > 1 files changed, 138 insertions(+), 0 deletions(-) > > > > > > Show changes for long DN, including: > > 1) saflogger tool > > 2) log agent > > 3) log services > > 4) test suite > > > > diff --git a/osaf/services/saf/logsv/README_LONGDN > b/osaf/services/saf/logsv/README_LONGDN > > new file mode 100644 > > --- /dev/null > > +++ b/osaf/services/saf/logsv/README_LONGDN > > @@ -0,0 +1,138 @@ > > +# > > +# -*- OpenSAF -*- > > +# > > +# (C) Copyright 2016 The OpenSAF Foundation > > +# > > +# This program is distributed in the hope that it will be useful, but > > +# WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY > > +# or FITNESS FOR A PARTICULAR PURPOSE. This file and program are > licensed > > +# under the GNU Lesser General Public License Version 2.1, February > 1999. > > +# The complete license can be accessed from the following location: > > +# http://opensource.org/licenses/lgpl-license.php > > +# See the Copying file included with the OpenSAF distribution for full > > +# licensing terms. > > +# > > +# Author(s): Ericsson AB > > +# > > + > > +I. GENERAL INFORMATION (#1315) > > +============================== > > + > > +The SaNameT type, which is used to pass distinguished stream DNs name > in saLogStreamOpen_2() API, > > +or in `logSvcUsrName`, `notificationObject` or `notifyingObject` which > belong to `SaLogRecordT` > > +data structure passed to `saLogWriteLogAsync()` API, contains a fixed-size > buffer that limits > > +the string length to a maximum of 255 bytes. > > + > > +#1315 ticket was raised for LOG to support long DN. The use cases could > be: > > +UC1) Write log records using the long DN in @Sl, @No, @Ng tokens using > Log API. > > +UC2) Create any long DN name stream using Log API. > > +UC3) Write record to long DN app stream using saflogger tool. > > + > > +The implementation was split into following parts: > > +1) Update saflogger tool - add one more option `-f` > > +2) Update LOG agent (API) to support Long DN > > +3) Update LOG service to support Long DN > > +4) Create test cases > > + > > +Besides, README file and OpenSAF_LOG_PR.odt have to be updated. > > + > > + > > +II) IMPLEMENTATION (#1315) > > +============================== > > + > > +1) Update saflogger tool - Add One More Option `-f` > > +------------------------------------------------- > > +`-f` option is only applicable for application stream. Means it is only valid > > +when comes together with option `-a`. If no `-f` is provided, default > behavior is maintained. > > + > > +Why need to add new option `-f` to saflogger tool? > > +When long DN is supported, user is able to put long DN name after option > `-a`, and saflogger tool will > > +use that long DN for log file name of that app stream. In that case, the log > file name will be over 256 characters in length. > > +As the result, logsv could get failed to create such long file name (most > Unix system supports file name length up to 255 characters). > > + > > + > > +2) Update LOG Agent (API) to Support Long DN > > +--------------------------------------------- > > +All internal SaNameT will be replaced by SaConstStringT and functions > handling extended SaNameT are used. > > + > > +One point needs to be noticed is that, with extended SaNameT, data size > could be up to 2048 bytes (not limited to 256 bytes any more). > > +As the result, several condition checking for max length size against 256 > bytes will be updated to 2048 bytes (kOsafMaxDnLength). > > +So, when supported long DN client (e.g: log client running on OpenSAF 5.1 > or newer versions) sends an record containing long DN > > +(e.g: `notificationObject` length > 256 bytes) to active Log service not > support long DN (e.g: active log running on OpenSAF 5.0 > > +or older versions), that log client will get `SA_AIS_ERR_TRY_AGAIN` > always and make cause the log client hang. > > +There is no problem with the opposite case (non-support long DN do > communicate with supported long DN). > > + > > + > > +3) Update LOG Service to Support Long DN > > +---------------------------------------- > > +In original code, logsv used NCS PATRICIA TREE as an database to hold all > existing LOG streams in system, > > +and taking stream DN as the keyword for searching/adding/deleting tree > elements. > > +NCS PATRICIA TREE has a limitation with keyword size. It is only supported > the key size up to 600 bytes. > > +With long DN, stream DN could be up to 2024 bytes (kOsafMaxDnLength), > that tree is no longer valid. > > + > > +Besides, logsv is providing other database named `stream_array` which is > used to hold all LOG existing streams. > > +When there is any new stream created, `log_stream_t` holding > information of that stream, will be added to that database > > +and when the stream is closed and no client connects to that stream, it > will be removed from the database. > > +That database is a two-dimensional array with data format: > > + { > > + { <streamId1>, <pointer to `log_stream_t`> }, > > + { <streamId2>, <pointer to `log_stream_t`> }, > > + ... > > + } > > + > > +Logsv is able to query below infos from `stream_array` that logsv used to > do so based on NCS PATRICIA TREE: > > +- Is there any current log stream with specific DN in system? > > +- Or what are the current log existing streams in system? > > +Therefore, NCS PATRICIA TREE can be removed from logsv code. > `stream_array` database can play the same role as NCS_PATRICIA_TREE. > > + > > +More on `stream_array` database. All rooms in `stream_array` is > clean/reset at startup. > > +First three rooms are reserved for well-known streams. > > +At the moment (OpenSAF 5.1), there are total 67 rooms (64 for app > streams + 3 for well-known streams). > > +Adding/deleting/searching items to/from this database is fast. > > + > > +In addition to above change, internal SaNameT will be replaced by > SaConstStringT or C++ strings and functions handling extended SaNameT are > used. > > + > > +NOTES: > > +If active node is OpenSAF 5.1 or newer communicate with older versions > such as OpenSAF 5.0 (not support Long DN), > > +then if there is operation on creating app stream with Long DN, standby > node will be crashed. > > +This will happen because active node sends checkpoint data to standby > node, and there is copying data operation (strcpy) > > +to SaNameT type. Make the data is overflowed. strcpy() should not be > used anywhere in code, but strncpy() instead. > > + > > +To avoid this happens, two options: > > +a) During upgrade, make sure there is no long DN operation run until the > upgrade is finished. > > +b) Raise one ticket to fix all places using strcpy() > > + > > + > > +4) Create Test Cases > > +----------------------------- > > +New test suite - suite #13 with ten test cases were created to cover > minimum requirement described at `GENERAL` section. > > +Including five normal use cases and five abnormal use cases. > > + > > +Each test cases is done with following frame: > > +a) Backup data such as current IMM attribute values, so that it can be > restored back after test run. > > +b) Set up environment such as enabling long DN support in IMM, change > log stream attribute values > > +c) Write log record containing long DN or creating streams with Long DN. > > +d) Verify the data if it contains what we expect to have such as log file > contains long DN at specific token or not. > > +e) Close all opened handles > > +f) Restore the data back to original values. > > + > > +At verifying step, if the environment variable `LOGTEST_ENABLE_STDOUT` > is set, user will be able to see > > +the verifying data such as long notifyingObj at specific log file name. > > +And when running the test suite #13, user does not have to to take care > how to set up environment > > +for long DN testing, all precondition are set to make sure the long DN > work. > > + > > +Users can refer to these test cases to see how to pass long DN data to > LOG APIs, > > +and what are precondition settings for using extended SaNameT. > > +The tests are located in the file `~/tests/logsv/tet_log_longDN.c` > > + > > +Besides, some other tests/check have been done: > > +a) Valgrind check > > +b) Upgrade/downgrade test > > +c) Cppcheck run > > + > > + > > +III. REFERENCES > > +======================= > > + > > +1) OpenSAF_Extensions_PR.odt > > + ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
