Re: [devel] [PATCH 0 of 3] Review Request for log: implement SaLogFilterSetCallbackT and version handling V4 [#2146]

[Canh Truong]

Hi Mahesh,

SaLogFilterSetCallbackT was already declared before  . So we don't have to
add more one header file. 

Regards
Canh

-Original Message-
From: Canh Truong [mailto:canh.v.tru...@dektech.com.au] 
Sent: Tuesday, February 21, 2017 4:41 PM
To: 'A V Mahesh'; 'lennart.l...@ericsson.com'; 'vu.m.ngu...@dektech.com.au'
Cc: 'opensaf-devel@lists.sourceforge.net'
Subject: RE: [devel] [PATCH 0 of 3] Review Request for log: implement
SaLogFilterSetCallbackT and version handling V4 [#2146]

Hi Mahesh,

The saLogFilterSetCallback is already existing in spec. But it has not
implemented yet. The patch implemented to received filter callback from log
server. So we increase version to A.02.03.
You can refer at Lennart's comments in
https://sourceforge.net/p/opensaf/tickets/2146/ for version handling.

Regards
Canh

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Tuesday, February 21, 2017 4:31 PM
To: Canh Truong; lennart.l...@ericsson.com; vu.m.ngu...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 0 of 3] Review Request for log: implement
SaLogFilterSetCallbackT and version handling V4 [#2146]

Hi Canh,

I am sorry saLogFilterSetCallback is existing call back in specification and
it seem we increased initialized  version jut to support  agent version is
that right ?

-AVM

On 2/21/2017 2:51 PM, A V Mahesh wrote:
> Hi Canh,
>
> The  general practice of implementing  any upcoming functionality of 
> SAF specification we do define in relevant structures 
> `src//saf/` file for example 
> `src/ckpt/saf/saCkpt_B_02_03.h` in addition to 
> `src/ckpt/saf/saCkpt.h`, so that user will include that new .h file 
> for new definitions
>
> Is their any reson  `SaLogFilterSetCallbackT` didn't followed this ?
> How application will include this  `SaLogFilterSetCallbackT` ?
>
> -AVM
>
> On 2/21/2017 2:07 PM, A V Mahesh wrote:
>> Hi Canh,
>>
>> I can see that you are passing NULL callbacks as `` for 
>> "logtest 1 10" and " logtest 1 11" by seeing
>>
>> -AVM
>>
>>
>> On 2/21/2017 1:02 PM, Canh Truong wrote:
>>> Hi Mahesh,
>>>
>>> The test case " logtest 1 10" and " logtest 1 11"  are created for 
>>> version handling. In standby node, it has new code for log agent 
>>> (with #2146), that means that version handling in log agent have been
added.
>>> The log agent check if minor version bigger than the agent support, 
>>> it will return ERROR_VERSION.  The test case is successful.
>>>
>>> In test case 11, log agent reassign for version of client is A.02.01 
>>> before sending to the initialized request to log server. So the test 
>>> case is successful.
>>>
>>> The test cases for filter callback is in test suite 17. (logtest 17)
>>>
>>> Regards
>>> Canh
>>>
>>>
>>> -Original Message-
>>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>>> Sent: Tuesday, February 21, 2017 2:10 PM
>>> To: Canh Van Truong; lennart.l...@ericsson.com; 
>>> vu.m.ngu...@dektech.com.au
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [PATCH 0 of 3] Review Request for log: implement 
>>> SaLogFilterSetCallbackT and version handling V4 [#2146]
>>>
>>> Hi  Canh,
>>>
>>> I was jut testing Agent in-service upgrade , so I have following 
>>> setup and run the New FilterSetCallback test case and i was 
>>> expecting case should receive fail/not-supported , but they are getting
succeed how ?
>>>
>>>
>>> -SC-2  ACTIVE  Old Node ( LOG is old code with out #2146 patch )
>>> -SC-1  STANDBY  New Node ( LOG is new code with #2146 patch )
>>>
>>> SC-1# /usr/bin/logtest 1 10
>>>
>>> Suite 1: Library Life Cycle
>>>10  PASSED   saLogInitialize() with minor version is set bigger
than
>>> supported version;
>>>
>>> 
>>> 
>>> =
>>>
>>>Test Result:
>>>   Total:  1
>>>   Passed: 1
>>>   Failed: 0
>>>
>>> SC-1# /usr/bin/logtest 1 11
>>>
>>> Suite 1: Library Life Cycle
>>>11  PASSED   saLogInitialize() with minor version is not set;
>>>
>>> 
>>> 
>>> =
>>>
>>>Test Result:
>>>   Total:  1
>>>   Passed: 1
>>>   Failed: 0
>>&g

Re: [devel] [PATCH 0 of 3] Review Request for log: implement SaLogFilterSetCallbackT and version handling V4 [#2146]

[Canh Truong]

Hi Mahesh,

The saLogFilterSetCallback is already existing in spec. But it has not
implemented yet. The patch implemented to received filter callback from log
server. So we increase version to A.02.03.
You can refer at Lennart's comments in
https://sourceforge.net/p/opensaf/tickets/2146/ for version handling.

Regards
Canh

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, February 21, 2017 4:31 PM
To: Canh Truong; lennart.l...@ericsson.com; vu.m.ngu...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 0 of 3] Review Request for log: implement
SaLogFilterSetCallbackT and version handling V4 [#2146]

Hi Canh,

I am sorry saLogFilterSetCallback is existing call back in specification and
it seem we increased initialized  version jut to support  agent version is
that right ?

-AVM

On 2/21/2017 2:51 PM, A V Mahesh wrote:
> Hi Canh,
>
> The  general practice of implementing  any upcoming functionality of 
> SAF specification we do define in relevant structures 
> `src//saf/` file for example 
> `src/ckpt/saf/saCkpt_B_02_03.h` in addition to 
> `src/ckpt/saf/saCkpt.h`, so that user will include that new .h file 
> for new definitions
>
> Is their any reson  `SaLogFilterSetCallbackT` didn't followed this ?
> How application will include this  `SaLogFilterSetCallbackT` ?
>
> -AVM
>
> On 2/21/2017 2:07 PM, A V Mahesh wrote:
>> Hi Canh,
>>
>> I can see that you are passing NULL callbacks as `` for 
>> "logtest 1 10" and " logtest 1 11" by seeing
>>
>> -AVM
>>
>>
>> On 2/21/2017 1:02 PM, Canh Truong wrote:
>>> Hi Mahesh,
>>>
>>> The test case " logtest 1 10" and " logtest 1 11"  are created for 
>>> version handling. In standby node, it has new code for log agent 
>>> (with #2146), that means that version handling in log agent have been
added.
>>> The log agent check if minor version bigger than the agent support, 
>>> it will return ERROR_VERSION.  The test case is successful.
>>>
>>> In test case 11, log agent reassign for version of client is A.02.01 
>>> before sending to the initialized request to log server. So the test 
>>> case is successful.
>>>
>>> The test cases for filter callback is in test suite 17. (logtest 17)
>>>
>>> Regards
>>> Canh
>>>
>>>
>>> -Original Message-
>>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>>> Sent: Tuesday, February 21, 2017 2:10 PM
>>> To: Canh Van Truong; lennart.l...@ericsson.com; 
>>> vu.m.ngu...@dektech.com.au
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [PATCH 0 of 3] Review Request for log: implement 
>>> SaLogFilterSetCallbackT and version handling V4 [#2146]
>>>
>>> Hi  Canh,
>>>
>>> I was jut testing Agent in-service upgrade , so I have following 
>>> setup and run the New FilterSetCallback test case and i was 
>>> expecting case should receive fail/not-supported , but they are getting
succeed how ?
>>>
>>>
>>> -SC-2  ACTIVE  Old Node ( LOG is old code with out #2146 patch )
>>> -SC-1  STANDBY  New Node ( LOG is new code with #2146 patch )
>>>
>>> SC-1# /usr/bin/logtest 1 10
>>>
>>> Suite 1: Library Life Cycle
>>>10  PASSED   saLogInitialize() with minor version is set bigger
than
>>> supported version;
>>>
>>> 
>>> 
>>> =
>>>
>>>Test Result:
>>>   Total:  1
>>>   Passed: 1
>>>   Failed: 0
>>>
>>> SC-1# /usr/bin/logtest 1 11
>>>
>>> Suite 1: Library Life Cycle
>>>11  PASSED   saLogInitialize() with minor version is not set;
>>>
>>> 
>>> 
>>> =
>>>
>>>Test Result:
>>>   Total:  1
>>>   Passed: 1
>>>   Failed: 0
>>>
>>> -AVM
>>>
>>> On 2/16/2017 12:18 PM, Canh Van Truong wrote:
>>>> Summary: log: implement SaLogFilterSetCallbackT and version 
>>>> handling
>>>> V4 [#2146] Review request for Trac Ticket(s): #2146 Peer Reviewer(s):
>>>> Lennart, Vu, Mahesh Pull request to: Vu Affected branch(es): 
>>>> default Development branch: default
>>>>
>>>> 
>&

[devel] FW: [PATCH 1 of 3] log: add alternative destinations of log records [#2258]

[Canh Truong]

Hi Vu,

Please see some my comments with [Canh]

Regards
Canh

-Original Message-
From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] 
Sent: Thursday, February 16, 2017 5:30 PM
To: lennart.l...@ericsson.com; mahesh.va...@oracle.com;
canh.v.tru...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 3] log: add alternative destinations of log records
[#2258]

 src/log/Makefile.am  |8 +-
 src/log/config/logsv_classes.xml |7 +-
 src/log/logd/lgs_config.cc   |  193 +++--
 src/log/logd/lgs_config.h|3 +-
 src/log/logd/lgs_dest.cc |  746
+++
 src/log/logd/lgs_dest.h  |  580 ++
 src/log/logd/lgs_evt.cc  |   33 +
 src/log/logd/lgs_imm.cc  |  140 ++-
 src/log/logd/lgs_mbcsv.cc|   91 -
 src/log/logd/lgs_mbcsv.h |6 +-
 src/log/logd/lgs_mbcsv_v7.cc |  177 +
 src/log/logd/lgs_mbcsv_v7.h  |   67 +++
 src/log/logd/lgs_stream.cc   |   54 ++-
 src/log/logd/lgs_stream.h|   16 +
 14 files changed, 2041 insertions(+), 80 deletions(-)


Here are major info, detailed info will be added to PR doc soon.
1) Add attribute "saLogRecordDestination" to log stream.
2) Add Local socket destintion handler
3) Integrate into first increment made by Lennart

diff --git a/src/log/Makefile.am b/src/log/Makefile.am
--- a/src/log/Makefile.am
+++ b/src/log/Makefile.am
@@ -71,9 +71,11 @@ noinst_HEADERS += \
src/log/logd/lgs_mbcsv_v2.h \
src/log/logd/lgs_mbcsv_v3.h \
src/log/logd/lgs_mbcsv_v5.h \
+   src/log/logd/lgs_mbcsv_v7.h \
src/log/logd/lgs_recov.h \
src/log/logd/lgs_stream.h \
-   src/log/logd/lgs_util.h
+   src/log/logd/lgs_util.h \
+   src/log/logd/lgs_dest.h
 
 bin_PROGRAMS += bin/saflogger
 osaf_execbin_PROGRAMS += bin/osaflogd
@@ -117,10 +119,12 @@ bin_osaflogd_SOURCES = \
src/log/logd/lgs_mbcsv_v2.cc \
src/log/logd/lgs_mbcsv_v3.cc \
src/log/logd/lgs_mbcsv_v5.cc \
+   src/log/logd/lgs_mbcsv_v7.cc \
src/log/logd/lgs_mds.cc \
src/log/logd/lgs_recov.cc \
src/log/logd/lgs_stream.cc \
-   src/log/logd/lgs_util.cc
+   src/log/logd/lgs_util.cc \
+   src/log/logd/lgs_dest.cc
 
 bin_osaflogd_LDADD = \
lib/libosaf_common.la \
diff --git a/src/log/config/logsv_classes.xml
b/src/log/config/logsv_classes.xml
--- a/src/log/config/logsv_classes.xml
+++ b/src/log/config/logsv_classes.xml
@@ -147,12 +147,13 @@
SA_CONFIG
SA_WRITABLE

-   
+   
saLogRecordDestination
-   SA_UINT32_T
+   SA_STRING_T
SA_CONFIG
SA_WRITABLE
-SA_MULTI_VALUE
+   SA_MULTI_VALUE
+   SA_NO_DUPLICATES


saLogStreamCreationTimestamp
diff --git a/src/log/logd/lgs_config.cc b/src/log/logd/lgs_config.cc
--- a/src/log/logd/lgs_config.cc
+++ b/src/log/logd/lgs_config.cc
@@ -40,6 +40,7 @@
 #include "osaf/immutil/immutil.h"
 #include "log/logd/lgs_file.h"
 #include "log/logd/lgs.h"
+#include "log/logd/lgs_dest.h"
 
 static SaVersionT immVersion = { 'A', 2, 11 };
 
@@ -117,10 +118,6 @@ typedef struct _lgs_conf_t {
   std::vector logRecordDestinationConfiguration; // Default
empty
   /* --- end correspond to IMM Class --- */
 
-  /* --- Used with OpenSafLogCurrentConfig runtime object only --- */
-  /* Note: Has no cnfflag */
-  std::vector logRecordDestinationStatus; // Default empty
-
   /* Used for checkpointing time when files are closed */
   time_t chkp_file_close_time;
 
@@ -254,6 +251,9 @@ void lgs_cfgupd_multival_add(const std::
  const std::vector& value_list,
  lgs_config_chg_t *config_data) {
   TRACE_ENTER();
+
+  CfgDestination(value_list, ModifyType::kAdd);
+
   // Get the existing multi-values and add them to the config data list
   lgs_logconfGet_t param_id = param_name_to_id(attribute_name);
   const std::vector *exist_list =
@@ -294,6 +294,9 @@ void lgs_cfgupd_multival_delete(std::str
 std::vector value_list,
 lgs_config_chg_t *config_data) {
   TRACE_ENTER();
+
+  CfgDestination(value_list, ModifyType::kDelete);
+
   // Get the existing multi-values
   lgs_logconfGet_t param_id = param_name_to_id(attribute_name);
   const std::vector *exist_list =
@@ -325,6 +328,9 @@ void lgs_cfgupd_mutival_replace(std::str
 std::vector value_list,
 lgs_config_chg_t *config_data) {
   TRACE_ENTER();
+
+  CfgDestination(value_list, ModifyType::kReplace);
+
   // Add given value-list to the config data list
   for (auto& value : value_list) {

Re: [devel] [PATCH 0 of 3] Review Request for log: implement SaLogFilterSetCallbackT and version handling V4 [#2146]

[Canh Truong]

Hi Mahesh,

The test case " logtest 1 10" and " logtest 1 11"  are created for version
handling. In standby node, it has new code for log agent (with #2146), that
means that version handling in log agent have been added.  
The log agent check if minor version bigger than the agent support, it will
return ERROR_VERSION.  The test case is successful.

In test case 11, log agent reassign for version of client is A.02.01 before
sending to the initialized request to log server. So the test case is
successful.

The test cases for filter callback is in test suite 17. (logtest 17)

Regards
Canh


-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, February 21, 2017 2:10 PM
To: Canh Van Truong; lennart.l...@ericsson.com; vu.m.ngu...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 0 of 3] Review Request for log: implement
SaLogFilterSetCallbackT and version handling V4 [#2146]

Hi  Canh,

I was jut testing Agent in-service upgrade , so I have following setup and
run the New FilterSetCallback test case and i was expecting case should
receive fail/not-supported , but they are getting succeed how ?


-SC-2  ACTIVE  Old Node ( LOG is old code with out #2146 patch )
-SC-1  STANDBY  New Node ( LOG is new code with #2146 patch )

SC-1# /usr/bin/logtest 1 10

Suite 1: Library Life Cycle
10  PASSED   saLogInitialize() with minor version is set bigger than 
supported version;


=

Test Result:
   Total:  1
   Passed: 1
   Failed: 0

SC-1# /usr/bin/logtest 1 11

Suite 1: Library Life Cycle
11  PASSED   saLogInitialize() with minor version is not set;


=

Test Result:
   Total:  1
   Passed: 1
   Failed: 0

-AVM

On 2/16/2017 12:18 PM, Canh Van Truong wrote:
> Summary: log: implement SaLogFilterSetCallbackT and version handling 
> V4 [#2146] Review request for Trac Ticket(s): #2146 Peer Reviewer(s): 
> Lennart, Vu, Mahesh Pull request to: Vu Affected branch(es): default 
> Development branch: default
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesn
>   OpenSAF servicesy
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 05726400fc1a27cf50255b70bb7f952156cbe68f
> Author:   Canh Van Truong 
> Date: Mon, 21 Nov 2016 17:19:56 +0700
>
>   log: implement SaLogFilterSetCallbackT [#2146]
>
>   Implement SaLogFilterSetCallbackT which is mentioned at section
3.6.5
>   SaLogFilterSetCallbackT @ AIS LOG document.
>
>   LGS:
>- Whenever severity filter is changed for app and systerm
streams, lgs will
>   find which clients that associate with the stream. Then lgs sends
message
>   callback to clients.
>- Encoding callback message for severity filter callback
>
>   LGA:
>- Decoding callback message for severity callback from lgs and
send the
>   message to the client which setting filter callback.
>- Dispatching severity filter callback
>
>   - Encrease version of log service to A.02.03
>
> changeset 8d41edf85334f1b14d858e2ad2f705aecf6b9a68
> Author:   Canh Van Truong 
> Date: Tue, 17 Jan 2017 14:24:33 +0700
>
>   log: Add minor version checking in log server [#2146]
>
>   Checking minor version and return version error if major/minor
version is
>   higher than supported major/minor
>
>   Add client_version to log_client_t and checkpoint struct in lgs
>
>   Increase checkpoint version and checkpoint client_ver to stand by
>
>   Only send filter callback to client that initialized with minor 
> version > 3
>
> changeset ff130149eb45136a50563878431a92b52e024997
> Author:   Canh Van Truong 
> Date: Tue, 17 Jan 2017 15:42:40 +0700
>
>   log: fix checking version in log agent [#2146]
>
>   Fix checking version in log agent
>
>   The agent report highest supported version except getting
ERR_VERSION from
>   server. if agent get ERR_VERSION, it will set supported version to 
> A.02.03
>
>
> Added Files:
> 
>   src/log/logd/lgs_mbcsv_v6.cc
>   src/log/logd/lgs_mbcsv_v6.h
>
>
> Complete diffstat:
> --
>   src/log/Makefile.am   |3 +
>   src/log/agent/lga.h   |4 +
>   src/log/agent/lga_api.c   |   58 +++--
>   

Re: [devel] [PATCH 1 of 1] ntf: workaround to fix failed upgrade [#2300]

[Canh Truong]

Hi aMinh,

NTFS has already re-assigned length of buffer  to MAX_ADDITIONAL_TEXT_LENGTH
if it is exceeds to MAX_ADDITIONAL_TEXT_LENGTH.
So we don't need to add any more for this check.

Regards
Canh

-Original Message-
From: minh chau [mailto:minh.c...@dektech.com.au] 
Sent: Wednesday, February 15, 2017 10:08 AM
To: Canh Van Truong; praveen.malv...@oracle.com; vu.m.ngu...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] ntf: workaround to fix failed upgrade [#2300]

Hi Canh,

Ack with comments:

- The patch #2006 introduced another check against
MAX_ADDITIONAL_TEXT_LENGTH, it's equal to SA_LOG_MAX_RECORD_SIZE too
(65535). So we need to add the same check of #2006 for #2300 so that NTF
server copes with possibly invalid input.
- We encounter the upgrade problem because NTF Agent in Opensaf 5.0 does not
have patch of #2006, so when we move on and Opensaf 5.0 is no longer
maintained, then this workaround should be removed from NTF server side. 
The reason is this kind of check (or auto-adjustment) should be done in NTF
Agent only, not in NTF Server side. So I think we should add comment besides
this workaround as a reminder.

Thanks,
Minh

On 14/02/17 17:20, Canh Van Truong wrote:
>   src/ntf/ntfd/NtfLogger.cc |  9 +
>   1 files changed, 9 insertions(+), 0 deletions(-)
>
>
> During cluster upgrade from an old OpenSAF version which have not 
> included the fix #2006 to one that have the fix in, if there is an 
> code fault related to inconsistent in additionalText and
lengthAdditionalText in NTF application, could lead to upgadate failed.
>
> This patch fix to add an workwround in NTFs, adjust 
> lengthAdditionalText to correct one if NTFs find the mismatch
>
> Note: The patch applies on branch 5.0 has little differences. There 
> are some changes in test cases ntftest 30 3... to change the length of
additionalText+1  and lengthAdditionalText are the same.
>
> diff --git a/src/ntf/ntfd/NtfLogger.cc b/src/ntf/ntfd/NtfLogger.cc
> --- a/src/ntf/ntfd/NtfLogger.cc
> +++ b/src/ntf/ntfd/NtfLogger.cc
> @@ -197,6 +197,15 @@ SaAisErrorT NtfLogger::logNotification(N
>   
> sendNotInfo = notif->getNotInfo();
> ntfsv_get_ntf_header(sendNotInfo, );
> +
> +  // Workaround to fix with failed upgrade  // Auto correction if 
> + there is inconsistent b/w lengthAdditionalText and additionalText  
> + if (ntfHeader->additionalText != NULL &&
> +  ntfHeader->lengthAdditionalText > strlen(ntfHeader->additionalText)
+ 1) {
> +LOG_WA("Mismatch b/w lengthAdditionalText and additionalText.
Re-Adjust!");
> +ntfHeader->lengthAdditionalText = 
> + strlen(ntfHeader->additionalText) + 1;  }
> +
> logBuffer.logBufSize = ntfHeader->lengthAdditionalText;
> logBuffer.logBuf = (SaUint8T*)[0];
>   
>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

[Canh Truong]

Hi Lennart,

Thanks for your comments.

As I understand you mean that the agent shall send to the server with  the
minor version that is initialized with client [in minor version] , except if
minor = 0, it will be set to 1. But as section of 3.5.1 AIS document  "
minorVersion = highest value of the minor versions that this implementation
can support for the returned values of releaseCode and majorVersion", so the
minor version has to update to highest value that  supported in agent before
sent to server. In this patch. The minor version is increased to 3. So if
client initialized with minor is:
0 or 1  minor version 1 shall be sent to server
2   minor version 3 shall be sent to server
3   minor version 3 shall be sent to server
Correct me if there is problem. 

In the log server, I will fix to check to return a SA_AIS_ERR_VERSION if
minor version > than highest supported version.

The new ticket will created for PR document and README. 

Thanks
Canh

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Thursday, January 05, 2017 10:03 PM
To: Canh Van Truong; Vu Minh Nguyen; mahesh.va...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

Hi Canh

Some more comments:
 - The server shall not send any filter changed message (for callback) if
not initialized with minor version 3 or higher
 - Validation of minor version is incorrect in the agent saLogInitialize():
If minor version:
0 or 1  minor version 1 shall be sent to server
2   minor version 2 shall be sent to server
3   minor version 3 shall be sent to server
> 3 saLogInitialize() shall return SA_AIS_ERR_VERSION and minor
version 3 shall be set in version [out]
If the server return SA_AIS_ERR_VERSION the agent shall return that
to the client and minor version 3 has to be set in version [out]
 - The server shall check minor version, preferable already in decoding
function. If minor version > than highest supported version a
SA_AIS_ERR_VERSION shall be returned to the agent

Regards
Lennart

> -Original Message-
> From: Canh Van Truong [mailto:canh.v.tru...@dektech.com.au]
> Sent: den 1 januari 2017 13:27
> To: Lennart Lund ; Vu Minh Nguyen 
> ; mahesh.va...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]
> 
>  src/log/agent/lga.h   |3 +
>  src/log/agent/lga_api.c   |2 +-
>  src/log/agent/lga_mds.c   |   70 +
>  src/log/agent/lga_util.c  |   60 -
>  src/log/apitest/logtest.c |2 +-
>  src/log/apitest/logtestfr.c   |2 +-
>  src/log/apitest/saflogtest.c  |2 +-
>  src/log/apitest/tet_LogOiOps.c|   71 +
>  src/log/apitest/tet_log_longDN.c  |2 +-
>  src/log/apitest/tet_saLogFilterSetCallbackT.c |  364
> +-
>  src/log/apitest/tet_saLogStreamOpen_2.c   |2 -
>  src/log/common/lgsv_defs.h|2 +-
>  src/log/common/lgsv_msg.h |7 +
>  src/log/logd/lgs_imm.cc   |7 +
>  src/log/logd/lgs_mds.cc   |   57 ++-
>  src/log/logd/lgs_util.cc  |   80 +
>  src/log/logd/lgs_util.h   |2 +
>  src/log/tools/saf_logger.c|2 +-
>  src/osaf/saflog/saflog.c  |4 +-
>  19 files changed, 707 insertions(+), 34 deletions(-)
> 
> 
> Implement SaLogFilterSetCallbackT which is mentioned at section 3.6.5 
> SaLogFilterSetCallbackT @ AIS LOG document.
> 
> LGS:
>  - Whenever severity filter is changed for app and systerm streams,
lgs will
>find which clients that associate with the stream. Then lgs sends
message
>callback to clients.
>  - Encoding callback message for severity filter callback
> 
> LGA:
>  - Decoding callback message for severity callback from lgs and 
> send the message
>to the client which setting filter callback.
>  - Dispatching severity filter callback
> 
> - Encrease version of log service to A.02.03
> 
> diff --git a/src/log/agent/lga.h b/src/log/agent/lga.h
> --- a/src/log/agent/lga.h
> +++ b/src/log/agent/lga.h
> @@ -155,5 +155,8 @@ extern bool lga_validate_lga_client_hdl(  extern 
> lga_client_hdl_rec_t *lga_find_hdl_rec_by_regid(lga_cb_t *lga_cb, 
> uint32_t client_id);  extern void lga_msg_destroy(lgsv_msg_t *msg);  
> extern bool lga_is_extended_name_valid(const SaNameT* name);
> +extern lga_log_stream_hdl_rec_t
> *lga_find_stream_hdl_rec_by_regid(lga_cb_t *lga_cb,
> +   uint32_t
> client_id,
> +

Re: [devel] [PATCH 1 of 1] log: fix bad file discriptor error when changing imm attributes[#2215]

[Canh Truong]

Hi Mahesh,

Could you explain more clear about this?

The first ` if (*stream->p_fd == -1) {`  is to avoid closing and rename log
file if file descriptor is -1.
The second is checked if open log if open log file fail.

Regards
Canh

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Wednesday, December 14, 2016 1:45 PM
To: Canh Van Truong; vu.m.ngu...@dektech.com.au; lennart.l...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] log: fix bad file discriptor error when changing
imm attributes[#2215]

Hi Canh Van,

One more point : In function log_stream_config_change() , you have

` if (*stream->p_fd == -1) {`  at the top and bottom , try to optimize to ,

code  looks confusing .

Normal testing done.

-AVM


On 12/14/2016 11:52 AM, A V Mahesh wrote:
> Hi ,
>
> ACK with following minor comment. NOT tested.
>
> On 12/3/2016 11:35 AM, Canh Van Truong wrote:
>> /* first time open? */
>> -  if (stream->numOpeners == 0) {
>> +  if (stream->numOpeners == 0 || *stream->p_fd == -1) {
> Some compilers will through error if we don't have `( )` for each 
> condition
>
> -AVM
>
> On 12/3/2016 11:35 AM, Canh Van Truong wrote:
>> osaf/services/saf/logsv/lgs/lgs_imm.cc|  14 +-
>>   osaf/services/saf/logsv/lgs/lgs_mbcsv.cc  |   2 +-
>>   osaf/services/saf/logsv/lgs/lgs_stream.cc |  38
>> ++
>>   3 files changed, 26 insertions(+), 28 deletions(-)
>>
>>
>> Issues:
>> This is happen when changing IMM attribute in logs service.
>> Following actions will be happen in IMM apply callback:
>> 1. closing log file  2. Rename cfg/log file  3. create/open new 
>> cfg/log file
>>
>> In closing action(1), it need time to sync data from cache to disc 
>> device before closing file. The sync data takes long time and cause 
>> log service timeout.
>> With closing action timeout, we do not know that closing file is 
>> successful or not.
>>
>> After closing action(1) timeout, apply callback is returned and new 
>> cfg/log file are not created.
>> If closing action timeout but log file was closed successfully, 2 
>> cases may be happen:
>>
>> a. Continue change this attribute with the same stream. Closing file 
>> action is happen again.
>> One request is send to log file handle thread to sync data and 
>> closing file with the fd that could be closed successfull from 
>> previous closing file action. That causes bad discriptor error.
>>
>> b. Write log records. Because the new log file has not be created and 
>> log server still write the record to file with old fd that has be 
>> closed successfull from previous closing file action.
>> This also causes bad file discriptor.
>>
>>
>> Solution:
>> In step 1 above, after closing log file fail, log service can contine 
>> to rename and open new file actions.
>> Convert ER to WA and add some WA.
>>
>> diff --git a/osaf/services/saf/logsv/lgs/lgs_imm.cc 
>> b/osaf/services/saf/logsv/lgs/lgs_imm.cc
>> --- a/osaf/services/saf/logsv/lgs/lgs_imm.cc
>> +++ b/osaf/services/saf/logsv/lgs/lgs_imm.cc
>> @@ -1849,7 +1849,7 @@ void logRootDirectory_filemove(
>>   if (log_stream_config_change(!LGS_STREAM_CREATE_FILES,
>>old_logRootDirectory, stream, 
>> current_logfile,
>>cur_time_in) != 0) {
>> -  LOG_ER("Old log files could not be renamed and closed for 
>> stream: %s",
>> +  LOG_WA("Old log files could not be renamed and closed for 
>> stream: %s",
>>stream->name.c_str());
>>   }
>> }
>> @@ -1865,7 +1865,7 @@ void logRootDirectory_filemove(
>> while ((stream = iterate_all_streams(endloop, jstart)) && 
>> !endloop) {
>>   jstart = SA_FALSE;
>>   if (lgs_create_config_file_h(new_logRootDirectory, stream) != 0) {
>> -  LOG_ER("New config file could not be created for stream: %s",
>> +  LOG_WA("New config file could not be created for stream: %s",
>>stream->name.c_str());
>>   }
>>   @@ -1875,7 +1875,7 @@ void logRootDirectory_filemove(
>> if ((*stream->p_fd = log_file_open(new_logRootDirectory,
>>  stream, 
>> stream->logFileCurrent, NULL)) == -1) {
>> -  LOG_ER("New log file could not be created for stream: %s",
>> +  LOG_WA("New log file could not be created for stream: %s",
>>stream->name.c_str());
>>   }
>>   @@ -2325,13 +2325,13 @@ static void stream_ccb_apply_modify(cons
>>   if ((rc = log_stream_config_change(!LGS_STREAM_CREATE_FILES,
>>  root_path, stream, 
>> current_logfile_name, _time))
>>   != 0) {
>> -  LOG_ER("log_stream_config_change failed: %d", rc);
>> +  LOG_WA("log_stream_config_change failed: %d", rc);
>>   }
>> stream->fileName = fileName;
>> if ((rc = lgs_create_config_file_h(root_path, stream)) != 0) {
>> -  LOG_ER("lgs_create_config_file_h failed: %d", rc);
>> +  

Re: [devel] [PATCH 1 of 1] ntfd: process NTFA down event with high priority[#2206]

[Canh Truong]

Hi Praveen,

When app do saNtfInitialize(), the ntfa will send initialized message with
normal priority (MDS_SEND_PRIORITY_MEDIUM = 2) to NTFS. NTFS pick this
message up in mds callback and put  to mbx with same priority . if app is
dead suddenly after initializing, NTFS will receive both initialized message
and MDS_DOWN  event message and NTFS will process which messages have higher
priority firstly. When you change the priority of MDS_DOWN  event message to
high, the MDS_DOWN event message will be process before initialized message.
This cause the new ntf client for app is created in NTFS while app was dead.

Regards,
Canh

-Original Message-
From: praveen.malv...@oracle.com [mailto:praveen.malv...@oracle.com] 
Sent: Monday, November 28, 2016 4:16 PM
To: minh.c...@dektech.com.au; canh.v.tru...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] ntfd: process NTFA down event with high
priority[#2206]

 osaf/services/saf/ntfsv/ntfs/NtfAdmin.cc|  2 +-
 osaf/services/saf/ntfsv/ntfs/NtfClient.cc   |  2 ++
 osaf/services/saf/ntfsv/ntfs/NtfSubscription.cc |  7 +++
osaf/services/saf/ntfsv/ntfs/NtfSubscription.hh |  1 +
 osaf/services/saf/ntfsv/ntfs/ntfs_com.c |  3 ++-
 osaf/services/saf/ntfsv/ntfs/ntfs_mds.c |  4 ++--
 6 files changed, 15 insertions(+), 4 deletions(-)


syslog gets flooded with following messages:
Nov 24 12:38:00 SC-1 osafntfd[11771]: ER ntfs_mds_msg_send FAILED Nov 24
12:38:00 SC-1 osafntfd[11771]: ER ntfs_mds_msg_send to ntfa failed rc: 2 Nov
24 12:38:00 SC-1 osafntfd[11771]: ER ntfs_mds_msg_send FAILED

In reported problem, an application like ntfsend is continuously sending
notifications. Other subscriber application like ntfsubscribe with matching
filter criteria is receiving those notifications. When subscriber suddenly
exits, NTFS receives MDS_DOWN event for it. At the same time MDS is
continuously delievering notifications sent by the sender app to the NTFS.
NTFS posts internal events for both notification messages and NTFA down
messages with HIGH and NORMAL priority respectively.
Since priority of NTFA down event is NORMAL, NTFS processes down event
relatively late compare to notificatin send messages. So notification send
messages are processed before NTFA down events. While sending these
notification to the subscriber, ncsmds_api returns failure because MDS has
already cleared subscriber data like mds_dest.

With this patch, NTFS will process NTFA down event with HIGH priority.
Also LOG_ER is converted to LOG_WA or trace at some places.

diff --git a/osaf/services/saf/ntfsv/ntfs/NtfAdmin.cc
b/osaf/services/saf/ntfsv/ntfs/NtfAdmin.cc
--- a/osaf/services/saf/ntfsv/ntfs/NtfAdmin.cc
+++ b/osaf/services/saf/ntfsv/ntfs/NtfAdmin.cc
@@ -540,7 +540,7 @@ void NtfAdmin::discardedAdd(unsigned int
   }
   else
   {
-LOG_ER("client %u not found", clientId);
+LOG_WA("client %u not found", clientId);
   }
 }
 
diff --git a/osaf/services/saf/ntfsv/ntfs/NtfClient.cc
b/osaf/services/saf/ntfsv/ntfs/NtfClient.cc
--- a/osaf/services/saf/ntfsv/ntfs/NtfClient.cc
+++ b/osaf/services/saf/ntfsv/ntfs/NtfClient.cc
@@ -55,6 +55,8 @@ NtfClient::~NtfClient() {
   SubscriptionMap::iterator pos;
   for (pos = subscriptionMap.begin(); pos != subscriptionMap.end(); pos++)
{
 NtfSubscription* subscription = pos->second;
+TRACE("For subscription:'%u', num of discarded Notifications: '%u'",
+  subscription->getSubscriptionId(), 
+ subscription->discardedListSize());
 delete subscription;
   }
   // delete all readers
diff --git a/osaf/services/saf/ntfsv/ntfs/NtfSubscription.cc
b/osaf/services/saf/ntfsv/ntfs/NtfSubscription.cc
--- a/osaf/services/saf/ntfsv/ntfs/NtfSubscription.cc
+++ b/osaf/services/saf/ntfsv/ntfs/NtfSubscription.cc
@@ -277,3 +277,10 @@ void NtfSubscription::printInfo() {
   TRACE("Subscription information");
   TRACE("  subscriptionId %u", subscriptionId_);  }
+/**
+ *  Returns size of discarded list.
+ */
+unsigned int NtfSubscription::discardedListSize() {
+  return discardedNotificationIdList.size();
+}
+
diff --git a/osaf/services/saf/ntfsv/ntfs/NtfSubscription.hh
b/osaf/services/saf/ntfsv/ntfs/NtfSubscription.hh
--- a/osaf/services/saf/ntfsv/ntfs/NtfSubscription.hh
+++ b/osaf/services/saf/ntfsv/ntfs/NtfSubscription.hh
@@ -41,6 +41,7 @@ class NtfSubscription{
   void sendNotification(NtfSmartPtr& notification, NtfClient *client);
   void discardedAdd(SaNtfIdentifierT n_id);
   void discardedClear();
+  unsigned int discardedListSize();
   void syncRequest(NCS_UBAID *uba);
  private:
   FilterMap filterMap;
diff --git a/osaf/services/saf/ntfsv/ntfs/ntfs_com.c
b/osaf/services/saf/ntfsv/ntfs/ntfs_com.c
--- a/osaf/services/saf/ntfsv/ntfs/ntfs_com.c
+++ b/osaf/services/saf/ntfsv/ntfs/ntfs_com.c
@@ -305,7 +305,8 @@ int send_notification_lib(ntfsv_send_not
   MDS_SEND_PRIORITY_HIGH);
if (rc != NCSCC_RC_SUCCESS) {
discarded = NTFS_NOTIFICATION_DISCARDED;
-  

Re: [devel] [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

[Canh Truong]

Hi Lennart,

I already did the upgrade test as your below and it was passed from my side.
I will check and run all test again

Regards,
Canh

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Tuesday, November 15, 2016 11:16 PM
To: Canh Van Truong; Vu Minh Nguyen; mahesh.va...@oracle.com; Anders Widell
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

Hi Canh

I have done some testing and have found problems with compatibility between
versions that will cause problems e.g. during an upgrade.
I have used three nodes running different variants of OpenSAF 5.1 and
default with your patch (5.2) and have found the following:

All nodes running 5.2: All tests Ok
SC-1 and SC-2 (5.2) and PL-3 (5.1): Many tests fail. No test should fail
SC-1 and SC-2 (5.1) and PL-3 (5.2): Many tests fail. No test except suite 17
should fail
SC-1 (5.2) SC-2 (5.1) and PL-3 (5.2): Ok

Yet to test:
Does filter settings still work after switch over or fail over?

Thanks
Lennart


> -Original Message-
> From: Canh Van Truong [mailto:canh.v.tru...@dektech.com.au]
> Sent: den 14 november 2016 11:43
> To: Lennart Lund ; Vu Minh Nguyen 
> ; mahesh.va...@oracle.com; Anders Widell 
> 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]
> 
>  osaf/libs/agents/saf/lga/lga.h|7 +-
>  osaf/libs/agents/saf/lga/lga_api.c|4 +-
>  osaf/libs/agents/saf/lga/lga_mds.c|   72 +-
>  osaf/libs/agents/saf/lga/lga_util.c   |   58 -
>  osaf/libs/common/logsv/include/lgsv_msg.h |8 +
>  osaf/libs/saf/include/saLog.h |4 +
>  osaf/services/saf/logsv/lgs/lgs_cb.h  |1 +
>  osaf/services/saf/logsv/lgs/lgs_evt.cc|9 +-
>  osaf/services/saf/logsv/lgs/lgs_evt.h |2 +-
>  osaf/services/saf/logsv/lgs/lgs_imm.cc|7 +
>  osaf/services/saf/logsv/lgs/lgs_mbcsv.cc  |3 +-
>  osaf/services/saf/logsv/lgs/lgs_mbcsv.h   |1 +
>  osaf/services/saf/logsv/lgs/lgs_mds.cc|   76 --
>  osaf/services/saf/logsv/lgs/lgs_recov.cc  |5 +-
>  osaf/services/saf/logsv/lgs/lgs_recov.h   |1 +
>  osaf/services/saf/logsv/lgs/lgs_util.cc   |   81 ++
>  osaf/services/saf/logsv/lgs/lgs_util.h|3 +-
>  tests/logsv/tet_saLogFilterSetCallbackT.c |  364
> +-
>  tests/logsv/tet_saLogStreamOpen_2.c   |2 -
>  19 files changed, 663 insertions(+), 45 deletions(-)
> 
> 
> Implement SaLogFilterSetCallbackT which is mentioned at section 3.6.5 
> SaLogFilterSetCallbackT @ AIS LOG document.
> 
> LGS: - Storing filter callback flag when client request open stream
>  - Whenever severity filter is changed for app and systerm 
> streams, lgs will find which clients that need severity filter 
> callback and associate with the stream. Then lgs sends message callback to
clients.
>  - Encoding callback message for severity filter callback
> 
> LGA: - Sending filter callback flag to lgs when open stream
>  - Decoding callback message for severity callback from lgs
>  - Dispatching severity filter callback
> 
> diff --git a/osaf/libs/agents/saf/lga/lga.h 
> b/osaf/libs/agents/saf/lga/lga.h
> --- a/osaf/libs/agents/saf/lga/lga.h
> +++ b/osaf/libs/agents/saf/lga/lga.h
> @@ -35,9 +35,9 @@
>  #include "lgsv_msg.h"
>  #include "lgsv_defs.h"
> 
> -#define LGA_SVC_PVT_SUBPART_VERSION  1
> +#define LGA_SVC_PVT_SUBPART_VERSION  2
>  #define LGA_WRT_LGS_SUBPART_VER_AT_MIN_MSG_FMT 1 -#define 
> LGA_WRT_LGS_SUBPART_VER_AT_MAX_MSG_FMT 1
> +#define LGA_WRT_LGS_SUBPART_VER_AT_MAX_MSG_FMT 2
>  #define LGA_WRT_LGS_SUBPART_VER_RANGE   \
>(LGA_WRT_LGS_SUBPART_VER_AT_MAX_MSG_FMT - \
> LGA_WRT_LGS_SUBPART_VER_AT_MIN_MSG_FMT + 1) @@ -153,6 +153,9 @@ 
> extern bool lga_validate_lga_client_hdl(
> 
>  /* lga_util.c */
>  extern lga_client_hdl_rec_t *lga_find_hdl_rec_by_regid(lga_cb_t 
> *lga_cb, uint32_t client_id);
> +extern lga_log_stream_hdl_rec_t
> *lga_find_stream_hdl_rec_by_regid(lga_cb_t *lga_cb,
> +   uint32_t
> client_id,
> +   uint32_t
> stream_id);
>  extern void lga_msg_destroy(lgsv_msg_t *msg);  extern bool 
> lga_is_extended_name_valid(const SaNameT* name);
> 
> diff --git a/osaf/libs/agents/saf/lga/lga_api.c
> b/osaf/libs/agents/saf/lga/lga_api.c
> --- a/osaf/libs/agents/saf/lga/lga_api.c
> +++ b/osaf/libs/agents/saf/lga/lga_api.c
> @@ -81,6 +81,8 @@ static void populate_open_params(lgsv_st  {
>   TRACE_ENTER();
>   open_param->client_id = hdl_rec->lgs_client_id;
> + open_param->filter_cb_flags = hdl_rec-
> >reg_cbk.saLogFilterSetCallback == NULL ?
> + 0 :
> SA_LOG_STREAM_FILTER_CALLBACK;
>   

Re: [devel] [PATCH 0 of 1] Review Request for log: improve test cases for log service [#1913] V2

[Canh Truong]

Thanks Lennart,

I will check these functions and move some of them if needed.

Regards,
Canh

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Thursday, October 13, 2016 5:38 PM
To: Canh Van Truong; mahesh.va...@oracle.com; Vu Minh Nguyen
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 0 of 1] Review Request for log: improve test cases for
log service [#1913] V2

Hi Canh

Ack

Of course there is always more that can be done but this is a good increment
and do clean up a number of things.
I saw that there are some utility functions in logtest.c and it may be good
to move some of them to the new utility file? But that I leave to you to
decide.

Thanks
Lennart

> -Original Message-
> From: Canh Van Truong [mailto:canh.v.tru...@dektech.com.au]
> Sent: den 13 oktober 2016 08:52
> To: Lennart Lund ; mahesh.va...@oracle.com; 
> Vu Minh Nguyen 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 0 of 1] Review Request for log: improve test cases for 
> log service [#1913] V2
> 
> Summary: log: improve test cases for log service [#1913] V2 Review 
> request for Trac Ticket(s): #1913 Peer Reviewer(s): Vu, Lennart, 
> Mahesh Pull request to: Vu Affected branch(es): default Development 
> branch: default
> 
> 
> Impacted area   Impact y/n
> 
>  Docsn
>  Build systemn
>  RPM/packaging   n
>  Configuration files n
>  Startup scripts n
>  SAF servicesn
>  OpenSAF servicesn
>  Core libraries  n
>  Samples n
>  Tests   y
>  Other   n
> 
> 
> Comments (indicate scope for each "y" above):
> -
>  <>
> 
> changeset 2fd2c08225292a0afe38a583bf71fbde137909a8
> Author:   Canh Van Truong 
> Date: Thu, 06 Oct 2016 18:55:51 +0700
> 
>   log: improve test cases for log service [#1913]
> 
>   The patch fixes to improve following cases:
> 
>   1) The APIs may return TRY_AGAIN, this may not be a fault. Writing 
> some
>   wrapper functions here to handle TRY_AGAIN case for log API.
> 
>   2) Remove abort (safassert) in test case and handle it as test case 
> failed.
> 
>   3) Some test cases (in testsuite 4) have dependence on other test 
> cases.
>   Make them independency.
> 
>   4) Some test cases (in testsuite 4, 5, 6) change setting such as IMM
>   attributes values and don't restore them back to previous. Get the
>   attributes values before changing attributes, then restore its to 
> previous
>   values at end of test cases.
> 
>   5) Some test cases in testsuite 6 change attributes base on the 
> present
>   value of logMaxLogrecsize without read the present value of its.
> They use
>   constanst values (=1024). Changing to read logMaxLogrecsize value
and 
> use
>   it.
> 
> 
> Added Files:
> 
>  tests/logsv/logutil.c
>  tests/logsv/logutil.h
> 
> 
> Complete diffstat:
> --
>  tests/logsv/Makefile.am   | 1 +
>  tests/logsv/logtest.c |12 +-
>  tests/logsv/logtest.h | 5 +-
>  tests/logsv/logutil.c |   129 
>  tests/logsv/logutil.h |51 +
>  tests/logsv/tet_LogOiOps.c|  2285
> ++--
> ---
>  tests/logsv/tet_Log_recov.c   | 2 +-
>  tests/logsv/tet_saLogDispatch.c   | 9 +-
>  tests/logsv/tet_saLogFinalize.c   |11 +-
>  tests/logsv/tet_saLogInitialize.c | 8 +-
>  tests/logsv/tet_saLogLimitGet.c   |19 +-
>  tests/logsv/tet_saLogSelectionObjectGet.c |13 +-
>  tests/logsv/tet_saLogStreamClose.c|21 +-
>  tests/logsv/tet_saLogStreamOpenAsync_2.c  |14 +-
>  tests/logsv/tet_saLogStreamOpen_2.c   |   541 ++--
>  tests/logsv/tet_saLogWriteLog.c   |21 +-
>  tests/logsv/tet_saLogWriteLogAsync.c  |   478 +-
>  tests/logsv/tet_saLogWriteLogCallbackT.c  |   116 ++-
>  18 files changed, 2229 insertions(+), 1507 deletions(-)
> 
> 
> Testing Commands:
> -
> Re-run all test cases
> 
> 
> Testing, Expected Results:
> --
> All test cases passed
> 
> 
> Conditions of Submission:
> -
> Ack from reviewers
> 
> 
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
> 
> 
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any 
> checkmarks!]
> 
> 
> Your 

Re: [devel] [PATCH 1 of 1] log: fix cppcheck with performance severity [#1975]

[Canh Truong]

Thanks Lennart,

I will add this before pushing code.

Regards,
Canh.

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Tuesday, October 11, 2016 8:51 PM
To: Canh Van Truong; Vu Minh Nguyen; mahesh.va...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1 of 1] log: fix cppcheck with performance severity
[#1975]

Hi Canh,

Ack with comment

1)
Why not initialize all variables in the structs in initialization list? At
least for the lists where some variables are. More consistent
Example:
struct file_communicate {
  bool request_f; /* True if pending request */
  bool answer_f;  /* True if pending answer */
  bool timeout_f; /* True if API has got a timeout. Thread shall not answer
*/
  lgsf_treq_t request_code;   /* Request code from API */
  int return_code;/* Return code from handlers */
  void *indata_ptr;   /* In-parameters for handlers */
  size_t outdata_size;
  void *outdata_ptr;  /* Out data from handlers */

  file_communicate() : request_code(LGSF_NOREQ)
  {
answer_f = false;
request_f = false;
timeout_f = false;
return_code = LGSF_NORETC;
indata_ptr = NULL;
outdata_ptr = NULL;
outdata_size = 0;
  }
};

Could be initialized as:

struct file_communicate {
  bool request_f; /* True if pending request */
  bool answer_f;  /* True if pending answer */
  bool timeout_f; /* True if API has got a timeout. Thread shall not answer
*/
  lgsf_treq_t request_code;   /* Request code from API */
  int return_code;/* Return code from handlers */
  void *indata_ptr;   /* In-parameters for handlers */
  size_t outdata_size;
  void *outdata_ptr;  /* Out data from handlers */

  file_communicate() :
request_f(false),
answer_f(false),
timeout_f(false),
request_code(LGSF_NOREQ),
return_code(LGSF_NORETC),
indata_ptr(NULL),
outdata_size(0),
outdata_ptr(NULL)
  {  }
};


> -Original Message-
> From: Canh Van Truong [mailto:canh.v.tru...@dektech.com.au]
> Sent: den 31 augusti 2016 10:49
> To: Vu Minh Nguyen ; Lennart Lund 
> ; mahesh.va...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] log: fix cppcheck with performance severity 
> [#1975]
> 
>  osaf/services/saf/logsv/lgs/lgs_config.cc |  35
--
>  osaf/services/saf/logsv/lgs/lgs_file.cc   |   4 +-
>  2 files changed, 16 insertions(+), 23 deletions(-)
> 
> 
> Fix performance reported by cppcheck.
> 
> diff --git a/osaf/services/saf/logsv/lgs/lgs_config.cc
> b/osaf/services/saf/logsv/lgs/lgs_config.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_config.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_config.cc
> @@ -137,32 +137,25 @@ typedef struct _lgs_conf_t {
>lgs_conf_flg_t logDataGroupname_cnfflag;
>lgs_conf_flg_t logStreamFileFormat_cnfflag;
> 
> -  _lgs_conf_t() {
> -/*
> - * For the following flags, LGS_CNF_DEF means that no external
> - * configuration exists and the corresponding attributes hard-coded
> - * default value is used.Is set to false if configuration is found in
> - * IMM object or environment variable.
> - * See function lgs_logconf_get() for more info.
> - */
> +  _lgs_conf_t()
> +  : logRootDirectory(lgs_conf_def.logRootDirectory),
> +logRootDirectory_cnfflag(LGS_CNF_DEF),
> +logMaxLogrecsize_cnfflag(LGS_CNF_DEF),
> +logStreamSystemHighLimit_cnfflag(LGS_CNF_DEF),
> +logStreamSystemLowLimit_cnfflag(LGS_CNF_DEF),
> +logStreamAppHighLimit_cnfflag(LGS_CNF_DEF),
> +logStreamAppLowLimit_cnfflag(LGS_CNF_DEF),
> +logMaxApplicationStreams_cnfflag(LGS_CNF_DEF),
> +logFileIoTimeout_cnfflag(LGS_CNF_DEF),
> +logFileSysConfig_cnfflag(LGS_CNF_DEF),
> +logDataGroupname_cnfflag(LGS_CNF_DEF),
> +logStreamFileFormat_cnfflag(LGS_CNF_DEF)
> +  {
>  OpenSafLogConfig_object_exist = false;
> -logRootDirectory_cnfflag = LGS_CNF_DEF;
> -logStreamSystemHighLimit_cnfflag = LGS_CNF_DEF;
> -logStreamSystemLowLimit_cnfflag = LGS_CNF_DEF;
> -logStreamAppHighLimit_cnfflag = LGS_CNF_DEF;
> -logStreamAppLowLimit_cnfflag = LGS_CNF_DEF;
> -logDataGroupname_cnfflag = LGS_CNF_DEF;
>  /*
>   * The following attributes cannot be configured in the config file
>   * Will be set to false if the attribute exists in the IMM config
object
>   */
> -logMaxLogrecsize_cnfflag = LGS_CNF_DEF;
> -logMaxApplicationStreams_cnfflag = LGS_CNF_DEF;
> -logFileIoTimeout_cnfflag = LGS_CNF_DEF;
> -logFileSysConfig_cnfflag = LGS_CNF_DEF;
> -logStreamFileFormat_cnfflag = LGS_CNF_DEF;
> -
> -logRootDirectory = lgs_conf_def.logRootDirectory;
>  (void) strcpy(logDataGroupname, lgs_conf_def.logDataGroupname);
>  (void) strcpy(logStreamFileFormat, lgs_conf_def.logStreamFileFormat);
>  logMaxLogrecsize = lgs_conf_def.logMaxLogrecsize; diff --git 
> a/osaf/services/saf/logsv/lgs/lgs_file.cc
> 

Re: [devel] [PATCH 1 of 1] ntf: fix ntfa does not remove subscriber in subscriberNoList at finalize [#1978]

[Canh Truong]

Hi Praveen,

What I understand about deadlock as below:

When other API and saNtfFinalize() called in parallel, both take the
ntfhandle by ncshm_take_hdl(), the cell->use_ct increase 
(and > 1). The saNtfFinalize() call ncshm_destroy_hdl() to destroy
ntfhandle, but ncshm_destroy_hdl() will check cell->use_ct greater than
1 or not. If it greater than one, the thread will be blocked by creating a
semaphore, and wait until cell->use_ct is decrease and equal 1. 
This mean that waiting other thread give handle by ncshm_give_hdl().

If both another API and saNtfFinalize() use locking on ntfa_cb.cb_lock and
the locking in saNtfFinalize() cover ncshm_destroy_hdl(),
the deadlock may be happen. Because the thread run saNtfFinalize() will stop
in ncshm_destroy_hdl() to wait for other thread given handle, and don't
unlock on ntfa_cb.cb_lock while another API in other thread need to lock on
ntfa_cb.cb_lock and it cannot. This makes the deadlock. 

But if the locking in in saNtfFinalize() does not cover ncshm_destroy_hdl(),
the deadlock won't happen. Because in locking in saNtfFinalize(),
it does not need to wait for any resources.

The fixing of issue need to remove item in the list. Other API use the same
list to do removing or adding action. So we need to use mutex to protect
here.

Do I misunderstand or be wrong here?

Thanks,
Canh.

-Original Message-
From: praveen malviya [mailto:praveen.malv...@oracle.com] 
Sent: Wednesday, October 05, 2016 6:42 PM
To: Canh Van Truong
Cc: minh.c...@dektech.com.au; opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] ntf: fix ntfa does not remove subscriber in
subscriberNoList at finalize [#1978]

Hi Canh,

Please find one comment inline with [Praveen].

Thanks,
Praveen

On 28-Sep-16 9:05 AM, Canh Van Truong wrote:
>  osaf/libs/agents/saf/ntfa/ntfa_api.c |   2 +
>  osaf/libs/agents/saf/ntfa/ntfa_util.c|  68
+++
>  tests/ntfsv/tet_saNtfNotificationSubscribe.c |  32 +
>  3 files changed, 81 insertions(+), 21 deletions(-)
>
>
> In finalize(), ntfa deletes client and does not remove the subscriber 
> that relate to this client from subscriber list. The subscriber with 
> subscriptionId keep in list, then we cannot subscribe with this
subscriptionId.
>
> The patch does:
>   - Deleting all subscribers that relate to finalized client.
>   - Checking pointer before using in subscriberListItemRemove()
>
> diff --git a/osaf/libs/agents/saf/ntfa/ntfa_api.c 
> b/osaf/libs/agents/saf/ntfa/ntfa_api.c
> --- a/osaf/libs/agents/saf/ntfa/ntfa_api.c
> +++ b/osaf/libs/agents/saf/ntfa/ntfa_api.c
> @@ -2059,6 +2059,7 @@ static void subscriberListItemRemove(SaN
>   ntfa_subscriber_list_t *listPtr = NULL;
>   osafassert(pthread_mutex_lock(_cb.cb_lock) == 0);
>   listPtr = listItemGet(subscriptionId);
> + if (listPtr == NULL) goto done;
>   if (listPtr->next != NULL) {
>   listPtr->next->prev = listPtr->prev;
>   }
> @@ -2074,6 +2075,7 @@ static void subscriberListItemRemove(SaN
>   TRACE_1("REMOVE: listPtr->SubscriptionId %d",
listPtr->subscriberListSubscriptionId);
>   ntfa_del_ntf_filter_ptrs(>filters);
>   free(listPtr);
> +done:
>   osafassert(pthread_mutex_unlock(_cb.cb_lock) == 0);  }
>
> diff --git a/osaf/libs/agents/saf/ntfa/ntfa_util.c 
> b/osaf/libs/agents/saf/ntfa/ntfa_util.c
> --- a/osaf/libs/agents/saf/ntfa/ntfa_util.c
> +++ b/osaf/libs/agents/saf/ntfa/ntfa_util.c
> @@ -743,6 +743,46 @@ void ntfa_subscriber_list_del()
>   }
>   subscriberNoList = NULL;
>  }
> +
>
+/**
**
> +  Name  : subscriber_removed_by_handle
> +
> +  Description   : This routine delete subscribers of this client out of
the
> +   subcriberNoList
> +
> +  Arguments : SaNtfHandleT ntfHandle
> +
> +  Return Values : None
> +
> +  Notes :
> +*
> +*/ void ntfa_subscriber_del_by_handle(SaNtfHandleT ntfHandle) 
> +{
> + TRACE_ENTER();
> + ntfa_subscriber_list_t* subscriber_hdl = subscriberNoList;
> + while (subscriber_hdl != NULL) {
> + ntfa_subscriber_list_t *rm_subscriber = subscriber_hdl;
> + subscriber_hdl = subscriber_hdl->next;
> + if (ntfHandle == rm_subscriber->subscriberListNtfHandle) {
> + if (rm_subscriber->next != NULL) {
> + rm_subscriber->next->prev =
rm_subscriber->prev;
> + }
> +
> + if (rm_subscriber->prev != NULL) {
> + rm_subscriber->prev->next =
rm_subscriber->next;
> + } else {
> + if (rm_subscriber->next != NULL)
> + subscriberNoList =
rm_subscriber->next;
> + else
> + subscriberNoList = 

Re: [devel] [PATCH 1 of 1] ntf: fix to keep MDS connection when last client finalize [#1895]

[Canh Truong]

Hi Praveen,

The problem is not always happen. After #1818 is fixed, it's still happen
sometimes. I cannot reproduce this problem, just have trace log (attached
here: https://sourceforge.net/p/opensaf/tickets/1895/).

The test case in this patch may not reproduce the problem. It  just proves
that we can initialize and finalize many times normally. The finalize  keep
MDS connection and use next new initialize.

Regards,
Canh.


-Original Message-
From: praveen malviya [mailto:praveen.malv...@oracle.com] 
Sent: Tuesday, September 13, 2016 2:00 PM
To: Canh Van Truong
Cc: lennart.l...@ericsson.com; opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] ntf: fix to keep MDS connection when last client
finalize [#1895]

Hi Canh,

Such a problem was fixed in #1818 (may be in part) and current tests in
tests/ntfsv case does not reproduce it.
Will the test case provided in this patch reproduce the problem if the fix
is not applied?

Thanks,
Praveen
On 01-Sep-16 3:12 PM, Canh Van Truong wrote:
>  osaf/libs/agents/saf/ntfa/ntfa_api.c  |   1 +
>  osaf/libs/agents/saf/ntfa/ntfa_util.c |  19 -
>  tests/ntfsv/tet_saNtfFinalize.c   |  36
--
>  3 files changed, 43 insertions(+), 13 deletions(-)
>
>
> Currently, when finalizing the last client, ntfa uninstall MDS connection.
> This causes that the NCSMDS_DOWN event will be sent to ntfs. ntfs will 
> remove all clients that relates to this MDS.
> But if we initializes new client immediately after finalizing, ntfs 
> may reviece the message of initialization before message of 
> NCSMDS_DOWN event. This cause new client will be removed without
finalizing and all action will be failed after that.
>
> This patch fixes that ntfa keep MDS connection when last client 
> finalized, and re-use it when next initializing call.
>
> diff --git a/osaf/libs/agents/saf/ntfa/ntfa_api.c 
> b/osaf/libs/agents/saf/ntfa/ntfa_api.c
> --- a/osaf/libs/agents/saf/ntfa/ntfa_api.c
> +++ b/osaf/libs/agents/saf/ntfa/ntfa_api.c
> @@ -35,6 +35,7 @@
>  ntfa_cb_t ntfa_cb = {
>   .cb_lock = PTHREAD_MUTEX_INITIALIZER,
>   .ntfa_ntfsv_state = NTFA_NTFSV_NONE,
> + .mds_hdl = 0,
>  };
>
>  /* list of subscriptions for this process */ diff --git 
> a/osaf/libs/agents/saf/ntfa/ntfa_util.c 
> b/osaf/libs/agents/saf/ntfa/ntfa_util.c
> --- a/osaf/libs/agents/saf/ntfa/ntfa_util.c
> +++ b/osaf/libs/agents/saf/ntfa/ntfa_util.c
> @@ -25,7 +25,7 @@
>
>  /* Variables used during startup/shutdown only */  static 
> pthread_mutex_t ntfa_lock = PTHREAD_MUTEX_INITIALIZER; -static 
> unsigned int ntfa_use_count;
> +static unsigned int ntfa_use_count = 0;
>
>  /**
>   *
> @@ -604,21 +604,20 @@ unsigned int ntfa_startup(void)
>   pthread_mutex_lock(_lock);
>
>   TRACE_ENTER2("ntfa_use_count: %u", ntfa_use_count);
> - if (ntfa_use_count > 0) {
> - /* Already created, just increment the use_count */
> - ntfa_use_count++;
> - goto done;
> - } else {
> + if (ntfa_cb.mds_hdl == 0) {
>   if ((rc = ncs_agents_startup()) != NCSCC_RC_SUCCESS) {
>   TRACE("ncs_agents_startup FAILED");
>   goto done;
>   }
>
>   if ((rc = ntfa_create()) != NCSCC_RC_SUCCESS) {
> + ntfa_cb.mds_hdl = 0;
>   ncs_agents_shutdown();
>   goto done;
>   } else
>   ntfa_use_count = 1;
> + } else {
> + ntfa_use_count++;
>   }
>
>   done:
> @@ -639,14 +638,14 @@ unsigned int ntfa_shutdown(bool forced)
>   TRACE_ENTER2("ntfa_use_count: %u, forced: %u", ntfa_use_count,
forced);
>   pthread_mutex_lock(_lock);
>
> - if ((forced && (ntfa_use_count > 0)) || (ntfa_use_count == 1)) {
> + if (ntfa_use_count > 0) {
> + /* Decrement the use count */
> + ntfa_use_count--;
> + } else if (forced) {
>   ntfa_destroy();
>   rc = ncs_agents_shutdown();
>   ntfa_use_count = 0;
>   ntfa_cb.ntfa_ntfsv_state = NTFA_NTFSV_NONE;
> - } else if (ntfa_use_count > 1) {
> - /* Users still exist, just decrement the use count */
> - ntfa_use_count--;
>   }
>
>   pthread_mutex_unlock(_lock);
> diff --git a/tests/ntfsv/tet_saNtfFinalize.c 
> b/tests/ntfsv/tet_saNtfFinalize.c
> --- a/tests/ntfsv/tet_saNtfFinalize.c
> +++ b/tests/ntfsv/tet_saNtfFinalize.c
> @@ -42,7 +42,7 @@ void saNtfFinalize_03(void)
>  test_validate(rc, SA_AIS_ERR_BAD_HANDLE);  }
>
> -SaAisErrorT subscribe()
> +SaAisErrorT subscribe(SaNtfSubscriptionIdT subscriptionId)
>  {
>  SaAisErrorT ret;
>  SaNtfObjectCreateDeleteNotificationFilterT obcf; @@ -54,7 +54,7 
> @@ SaAisErrorT subscribe()
>  obcf.notificationFilterHeader.notificationClassIds->majorId = 222;
>  obcf.notificationFilterHeader.notificationClassIds->minorId = 222;
>  

Re: [devel] [PATCH 1 of 1] log: fix cppcheck with performance severity [#1975]

[Canh Truong]

Hi Mahesh,

I run cppcheck with latest version 1.75. I got from:
https://sourceforge.net/projects/cppcheck/files/cppcheck/1.75/
And build, then run with option --enable=performance.

Regards,
Canh.

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Thursday, September 01, 2016 11:03 AM
To: Canh Van Truong; vu.m.ngu...@dektech.com.au; lennart.l...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] log: fix cppcheck with performance severity
[#1975]

  Hi Canh Van Truong,

  Can you please share the suggestion reported by cppcheck.

-AVM


On 8/31/2016 2:19 PM, Canh Van Truong wrote:
>   osaf/services/saf/logsv/lgs/lgs_config.cc |  35
--
>   osaf/services/saf/logsv/lgs/lgs_file.cc   |   4 +-
>   2 files changed, 16 insertions(+), 23 deletions(-)
>
>
> Fix performance reported by cppcheck.
>
> diff --git a/osaf/services/saf/logsv/lgs/lgs_config.cc 
> b/osaf/services/saf/logsv/lgs/lgs_config.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_config.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_config.cc
> @@ -137,32 +137,25 @@ typedef struct _lgs_conf_t {
> lgs_conf_flg_t logDataGroupname_cnfflag;
> lgs_conf_flg_t logStreamFileFormat_cnfflag;
>   
> -  _lgs_conf_t() {
> -/*
> - * For the following flags, LGS_CNF_DEF means that no external
> - * configuration exists and the corresponding attributes hard-coded
> - * default value is used.Is set to false if configuration is found in
> - * IMM object or environment variable.
> - * See function lgs_logconf_get() for more info.
> - */
> +  _lgs_conf_t()
> +  : logRootDirectory(lgs_conf_def.logRootDirectory),
> +logRootDirectory_cnfflag(LGS_CNF_DEF),
> +logMaxLogrecsize_cnfflag(LGS_CNF_DEF),
> +logStreamSystemHighLimit_cnfflag(LGS_CNF_DEF),
> +logStreamSystemLowLimit_cnfflag(LGS_CNF_DEF),
> +logStreamAppHighLimit_cnfflag(LGS_CNF_DEF),
> +logStreamAppLowLimit_cnfflag(LGS_CNF_DEF),
> +logMaxApplicationStreams_cnfflag(LGS_CNF_DEF),
> +logFileIoTimeout_cnfflag(LGS_CNF_DEF),
> +logFileSysConfig_cnfflag(LGS_CNF_DEF),
> +logDataGroupname_cnfflag(LGS_CNF_DEF),
> +logStreamFileFormat_cnfflag(LGS_CNF_DEF)
> +  {
>   OpenSafLogConfig_object_exist = false;
> -logRootDirectory_cnfflag = LGS_CNF_DEF;
> -logStreamSystemHighLimit_cnfflag = LGS_CNF_DEF;
> -logStreamSystemLowLimit_cnfflag = LGS_CNF_DEF;
> -logStreamAppHighLimit_cnfflag = LGS_CNF_DEF;
> -logStreamAppLowLimit_cnfflag = LGS_CNF_DEF;
> -logDataGroupname_cnfflag = LGS_CNF_DEF;
>   /*
>* The following attributes cannot be configured in the config file
>* Will be set to false if the attribute exists in the IMM config
object
>*/
> -logMaxLogrecsize_cnfflag = LGS_CNF_DEF;
> -logMaxApplicationStreams_cnfflag = LGS_CNF_DEF;
> -logFileIoTimeout_cnfflag = LGS_CNF_DEF;
> -logFileSysConfig_cnfflag = LGS_CNF_DEF;
> -logStreamFileFormat_cnfflag = LGS_CNF_DEF;
> -
> -logRootDirectory = lgs_conf_def.logRootDirectory;
>   (void) strcpy(logDataGroupname, lgs_conf_def.logDataGroupname);
>   (void) strcpy(logStreamFileFormat,
lgs_conf_def.logStreamFileFormat);
>   logMaxLogrecsize = lgs_conf_def.logMaxLogrecsize; diff --git 
> a/osaf/services/saf/logsv/lgs/lgs_file.cc 
> b/osaf/services/saf/logsv/lgs/lgs_file.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_file.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_file.cc
> @@ -51,11 +51,11 @@ struct file_communicate {
> size_t outdata_size;
> void *outdata_ptr;  /* Out data from handlers */
>   
> -  file_communicate() {
> +  file_communicate() : request_code(LGSF_NOREQ)  {
>   answer_f = false;
>   request_f = false;
>   timeout_f = false;
> -request_code = LGSF_NOREQ;
>   return_code = LGSF_NORETC;
>   indata_ptr = NULL;
>   outdata_ptr = NULL;



--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: fix errors reported by cppcheck version 1.75 [#1985]

[Canh Truong]

Hi  Mahesh,

Please see my comment inline.

Regards,
Canh.

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Thursday, September 01, 2016 10:59 AM
To: Canh Van Truong; vu.m.ngu...@dektech.com.au; lennart.l...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] log: fix errors reported by cppcheck version
1.75 [#1985]

Hi Canh Van Truong,

On 8/31/2016 12:04 PM, Canh Van Truong wrote:
>   sprintf(command, VERIFY_CMD_, appLogPath,
> - "safLgStrCfg=verDefaultLogFileFmt", tZoneMillP);
> + "safLgStr=verDefaultLogFileFmt",tZoneMillP);
[AVM] why string changed , what was the errors, reported by cppcheck ?
[Canh]  No, this is not reported by cppcheck.
In the test case, we created runtime stream, object with command:
(saflogger -a ...).
And RDN to create runtime object is  'safLgStr=' , not is '
safLgStrCfg='. 

On 8/31/2016 12:04 PM, Canh Van Truong wrote:
>   osaf/services/saf/logsv/lgs/lgs_clm.cc |  2 +-
>   osaf/services/saf/logsv/lgs/lgs_evt.cc |  3 ++-
>   tests/logsv/tet_LogOiOps.c |  4 ++--
>   tests/logsv/tet_log_longDN.c   |  2 +-
>   4 files changed, 6 insertions(+), 5 deletions(-)
>
>
> Fix errors, reported by cppcheck:
>
> osaf/services/saf/logsv/lgs/lgs_clm.cc:120]: (error) Uninitialized 
> variable: rc
> osaf/services/saf/logsv/lgs/lgs_evt.cc:892]: (error) Invalid strncmp()
argument nr 3. A non-boolean value is required.
>
> diff --git a/osaf/services/saf/logsv/lgs/lgs_clm.cc 
> b/osaf/services/saf/logsv/lgs/lgs_clm.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_clm.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_clm.cc
> @@ -93,7 +93,7 @@ static uint32_t lgs_clm_node_find(NODE_I
>*/
>   static uint32_t lgs_clm_node_add(NODE_ID clm_node_id) {
> TRACE_ENTER();
> -  uint32_t rc;
> +  uint32_t rc = NCSCC_RC_SUCCESS;
> lgs_clm_node_t *clm_node;
>   
> clm_node = new lgs_clm_node_t();
> diff --git a/osaf/services/saf/logsv/lgs/lgs_evt.cc 
> b/osaf/services/saf/logsv/lgs/lgs_evt.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_evt.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_evt.cc
> @@ -799,6 +799,7 @@ SaAisErrorT create_new_app_stream(lgsv_s
> SaUint32T logMaxLogrecsize_conf = 0;
> SaConstStringT str_name;
> int num, err = 0;
> +  const char *dnPrefix = "safLgStr=";
>   
> TRACE_ENTER();
>   
> @@ -873,7 +874,7 @@ SaAisErrorT create_new_app_stream(lgsv_s
>   
> /* Verify that the name seems to be a DN */
> str_name = osaf_extended_name_borrow(_sync_param->lstr_name);
> -  if (strncmp("safLgStr=", str_name, sizeof("safLgStr=") != 0)) {
> +  if (strncmp(dnPrefix, str_name, strlen(dnPrefix)) != 0) {
>   TRACE("'%s' is not a valid stream name => invalid param", str_name);
>   rc = SA_AIS_ERR_INVALID_PARAM;
>   goto done;
> diff --git a/tests/logsv/tet_LogOiOps.c b/tests/logsv/tet_LogOiOps.c
> --- a/tests/logsv/tet_LogOiOps.c
> +++ b/tests/logsv/tet_LogOiOps.c
> @@ -2443,7 +2443,7 @@ void verDefaultLogFileFmt(void)
>   rc = system(command);
>   if (WEXITSTATUS(rc) == 0) {
>   /* Send an system log to app stream */
> - rc = system("saflogger -a
safLgStrCfg=verDefaultLogFileFmt");
> + rc = system("saflogger -a safLgStr=verDefaultLogFileFmt");
>   if (WEXITSTATUS(rc)) {
>   /* Failed to send log record to app stream */
>   fprintf(stderr, "Failed to invoke saflogger -a\n");
@@ -2457,7 
> +2457,7 @@ void verDefaultLogFileFmt(void)
>   /* Verify the content of log file if it is reflected with
right format */
>   sprintf(appLogPath, "%s/saflogger", log_root_path);
>   sprintf(command, VERIFY_CMD_, appLogPath,
> - "safLgStrCfg=verDefaultLogFileFmt", tZoneMillP);
> + "safLgStr=verDefaultLogFileFmt",tZoneMillP);
>   
>   rc = system(command);
>   if (rc == -1) {
> diff --git a/tests/logsv/tet_log_longDN.c 
> b/tests/logsv/tet_log_longDN.c
> --- a/tests/logsv/tet_log_longDN.c
> +++ b/tests/logsv/tet_log_longDN.c
> @@ -905,7 +905,7 @@ void longDNIn_AppStreamDN(void)
>   memset(appStreamDN, 'D', sizeof(appStreamDN) - 1);
>   
>   // Perform testing
> - sprintf(command, "saflogger -a safLgStrCfg=%s -f longDN
longDN_test", appStreamDN);
> + sprintf(command, "saflogger -a safLgStr=%s -f longDN longDN_test", 
> +appStreamDN);
>   rc = system(command);
>   if (WEXITSTATUS(rc) != 0) {
>   fprintf(stderr, "Failed to perform cmd = %s\n", command);



--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: fix issue with priority of messages adding to mailbox in the server[1396]

[Canh Truong]

Hi Lennart,

I'd like to send to you latest patch that shall be reviewed. 

Thanks,
Canh.

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Thursday, August 04, 2016 5:38 PM
To: A V Mahesh; Canh Van Truong; Vu Minh Nguyen
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1 of 1] log: fix issue with priority of messages adding to 
mailbox in the server[1396]

Hi Canh

My comments are very old, October 2015 and they are mostly about list handling 
(see attached mail). Since then the log server has been refactored to C++ so 
C++ tools for lists can be used.
There seems to be a lot of mail conversations with included patches etc. and 
since I haven't been following this I have some problem understanding what to 
review. Can you please send out a review request containing the latest patches 
that shall actually be reviewed.

Thanks
Lennart

> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: den 21 juni 2016 08:49
> To: Canh Van Truong <canh.v.tru...@dektech.com.au>; Vu Minh Nguyen 
> <vu.m.ngu...@dektech.com.au>; Lennart Lund <lennart.l...@ericsson.com>
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] log: fix issue with priority of messages 
> adding to mailbox in the server[1396]
> 
> Hi Canh,
> 
> It seems Lennart already provide comments  please check.
> 
> -AVM
> 
> 
> On 6/21/2016 12:07 PM, Canh Truong wrote:
> > Hi Mahesh,
> >
> > Thanks for your comments. I will send new version after Lennart
> comments.
> > I have checked your idea about multiple thread test case. The idea 
> > may be
> same with patch that I sent it before.
> >
> > Regards,
> > Canh.
> >
> > -Original Message-
> > From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> > Sent: Tuesday, June 21, 2016 11:47 AM
> > To: Canh Truong; vu.m.ngu...@dektech.com.au;
> lennart.l...@ericsson.com
> > Cc: opensaf-devel@lists.sourceforge.net
> > Subject: Re: [PATCH 1 of 1] log: fix issue with priority of messages 
> > adding to
> mailbox in the server[1396]
> >
> > Hi Canh,
> >
> > It will be good to send V2 patch with Lennart comments and adding 
> > new
> test cases.
> >
> > -AVM
> > On 6/21/2016 9:46 AM, A V Mahesh wrote:
> >> Hi Canh,
> >>
> >> Some how we were not able to open your attachment , so  my self 
> >> written
> >>
> >> a multi threaded test case ( attached 
> >> `thread_LogInitializeFinalize.c`
> >> ) and reviewed/tested it is working fine.
> >>
> >> ACK  from me with following :
> >>
> >> - Please add such as attached  multi threaded test case to logtest, 
> >> before pushing
> >>
> >> - add # before ticket number in commit message  #1396
> >>
> >> -AVM
> >>
> >>
> >> On 6/14/2016 2:47 PM, Canh Truong wrote:
> >>> Hi Mahesh,
> >>>
> >>> I have created new test case for multiple threads. Please help 
> >>> check new patch in attachment.
> >>>
> >>> Thanks,
> >>> Canh.
> >>>
> >>> -Original Message-
> >>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> >>> Sent: Tuesday, June 14, 2016 11:03 AM
> >>> To: Canh Van Truong; vu.m.ngu...@dektech.com.au; 
> >>> lennart.l...@ericsson.com
> >>> Cc: opensaf-devel@lists.sourceforge.net
> >>> Subject: Re: [PATCH 1 of 1] log: fix issue with priority of 
> >>> messages adding to mailbox in the server[1396]
> >>>
> >>> Hi Canh Van Truong,
> >>>
> >>> I hope this patch will work for multiple threads doing
> >>> saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() 
> >>> concurrently in a single process and reaches lga_use_count = 0 , 
> >>> againg restarting
> >>> saLogInitialize() , saLogStreamOpen_2()  and
> >>> saLogFinalize()
> >>> without process exist.
> >>>
> >>> If so let us have a  test case like for multiple threads doing
> >>> saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() 
> >>> concurrently
> >>>
> >>> -AVM
> >>>
> >>>
> >>> On 6/13/2016 12:37 PM, Canh Van Truong wrote:
> >>>> osaf/libs/agents/saf/lga/lga_api.c |   3 ++-
> >>>> osaf/libs/agents/saf/lga/lga_util.c |  21 -
> >>>> tests/logsv/logtest.h   |   1 +
> >>>&g

Re: [devel] [PATCH 1 of 1] log: fix issue with priority of messages adding to mailbox in the server[1396]

[Canh Truong]

Hi Mahesh,

Thanks for your comments. I will send new version after Lennart comments.
I have checked your idea about multiple thread test case. The idea may be same 
with patch that I sent it before.

Regards,
Canh.

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, June 21, 2016 11:47 AM
To: Canh Truong; vu.m.ngu...@dektech.com.au; lennart.l...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] log: fix issue with priority of messages adding to 
mailbox in the server[1396]

Hi Canh,

It will be good to send V2 patch with Lennart comments and adding new test 
cases.

-AVM
On 6/21/2016 9:46 AM, A V Mahesh wrote:
> Hi Canh,
>
> Some how we were not able to open your attachment , so  my self 
> written
>
> a multi threaded test case ( attached `thread_LogInitializeFinalize.c`
> ) and reviewed/tested it is working fine.
>
> ACK  from me with following :
>
> - Please add such as attached  multi threaded test case to logtest, 
> before pushing
>
> - add # before ticket number in commit message  #1396
>
> -AVM
>
>
> On 6/14/2016 2:47 PM, Canh Truong wrote:
>> Hi Mahesh,
>>
>> I have created new test case for multiple threads. Please help check 
>> new patch in attachment.
>>
>> Thanks,
>> Canh.
>>
>> -Original Message-
>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>> Sent: Tuesday, June 14, 2016 11:03 AM
>> To: Canh Van Truong; vu.m.ngu...@dektech.com.au; 
>> lennart.l...@ericsson.com
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] log: fix issue with priority of messages 
>> adding to mailbox in the server[1396]
>>
>> Hi Canh Van Truong,
>>
>> I hope this patch will work for multiple threads doing
>> saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() 
>> concurrently in a single process and reaches lga_use_count = 0 , 
>> againg restarting
>> saLogInitialize() , saLogStreamOpen_2()  and
>> saLogFinalize()
>> without process exist.
>>
>> If so let us have a  test case like for multiple threads doing
>> saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() 
>> concurrently
>>
>> -AVM
>>
>>
>> On 6/13/2016 12:37 PM, Canh Van Truong wrote:
>>>osaf/libs/agents/saf/lga/lga_api.c |   3 ++-
>>>osaf/libs/agents/saf/lga/lga_util.c |  21 -
>>>tests/logsv/logtest.h   |   1 +
>>>tests/logsv/tet_saLogStreamOpen_2.c |  29
>>> +
>>>4 files changed, 44 insertions(+), 10 deletions(-)
>>>
>>>
>>> Sometimes, Log service can handle LGSV_INITIALIZE_REQ before handle 
>>> LGSV_LGS_EVT_LGA_DOWN, although LGSV_LGS_EVT_LGA_DOWN was sent first 
>>> whenever
>>> finalize() is call for last client. Because lgs can not distinguish 
>>> MDS address between new connection (initializing new client) and old 
>>> connection (finalizing last client before). This patch fixes to keep 
>>> MDS connection when last client finalized, and re-use it when next
>> initialize() called.
>>> diff --git a/osaf/libs/agents/saf/lga/lga_api.c
>>> b/osaf/libs/agents/saf/lga/lga_api.c
>>> --- a/osaf/libs/agents/saf/lga/lga_api.c
>>> +++ b/osaf/libs/agents/saf/lga/lga_api.c
>>> @@ -41,7 +41,8 @@
>>>/* The main controle block */
>>>lga_cb_t lga_cb = {
>>>.cb_lock = PTHREAD_MUTEX_INITIALIZER,
>>> -.lgs_state = LGS_START
>>> +.lgs_state = LGS_START,
>>> +.mds_hdl = 0
>>>};
>>>   static bool is_well_know_stream(const char* dn) diff --git 
>>> a/osaf/libs/agents/saf/lga/lga_util.c
>>> b/osaf/libs/agents/saf/lga/lga_util.c
>>> --- a/osaf/libs/agents/saf/lga/lga_util.c
>>> +++ b/osaf/libs/agents/saf/lga/lga_util.c
>>> @@ -308,21 +308,17 @@ unsigned int lga_startup(lga_cb_t *cb)
>>>osaf_mutex_lock_ordie(_lock);
>>>   TRACE_ENTER2("lga_use_count: %u", lga_use_count);
>>> -if (lga_use_count > 0) {
>>> -/* Already created, just increment the use_count */
>>> -lga_use_count++;
>>> -goto done;
>>> -} else {
>>> +
>>> +if (cb->mds_hdl == 0) {
>>>if ((rc = ncs_agents_startup()) != NCSCC_RC_SUCCESS) {
>>>TRACE("ncs_agents_startup FAILED");
>>>goto done;
>>>}
>>>   if ((rc = lga_create()) != NCSCC_RC_SUCCESS) {

Re: [devel] [PATCH 1 of 1] log: fix issue with priority of messages adding to mailbox in the server[1396]

[Canh Truong]

Hi Mahesh,

I have created new test case for multiple threads. Please help check new
patch in attachment.

Thanks,
Canh. 

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, June 14, 2016 11:03 AM
To: Canh Van Truong; vu.m.ngu...@dektech.com.au; lennart.l...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] log: fix issue with priority of messages adding
to mailbox in the server[1396]

Hi Canh Van Truong,

I hope this patch will work for multiple threads doing
saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() concurrently in
a single process and reaches lga_use_count = 0 , againg restarting
saLogInitialize() , saLogStreamOpen_2()  and
saLogFinalize()
without process exist.

If so let us have a  test case like for multiple threads doing
saLogInitialize() , saLogStreamOpen_2()  and saLogFinalize() concurrently

-AVM


On 6/13/2016 12:37 PM, Canh Van Truong wrote:
>   osaf/libs/agents/saf/lga/lga_api.c  |   3 ++-
>   osaf/libs/agents/saf/lga/lga_util.c |  21 -
>   tests/logsv/logtest.h   |   1 +
>   tests/logsv/tet_saLogStreamOpen_2.c |  29 +
>   4 files changed, 44 insertions(+), 10 deletions(-)
>
>
> Sometimes, Log service can handle LGSV_INITIALIZE_REQ before handle 
> LGSV_LGS_EVT_LGA_DOWN, although LGSV_LGS_EVT_LGA_DOWN was sent first 
> whenever
> finalize() is call for last client. Because lgs can not distinguish 
> MDS address between new connection (initializing new client) and old 
> connection (finalizing last client before). This patch fixes to keep 
> MDS connection when last client finalized, and re-use it when next
initialize() called.
>
> diff --git a/osaf/libs/agents/saf/lga/lga_api.c 
> b/osaf/libs/agents/saf/lga/lga_api.c
> --- a/osaf/libs/agents/saf/lga/lga_api.c
> +++ b/osaf/libs/agents/saf/lga/lga_api.c
> @@ -41,7 +41,8 @@
>   /* The main controle block */
>   lga_cb_t lga_cb = {
>   .cb_lock = PTHREAD_MUTEX_INITIALIZER,
> - .lgs_state = LGS_START
> + .lgs_state = LGS_START,
> + .mds_hdl = 0
>   };
>   
>   static bool is_well_know_stream(const char* dn) diff --git 
> a/osaf/libs/agents/saf/lga/lga_util.c 
> b/osaf/libs/agents/saf/lga/lga_util.c
> --- a/osaf/libs/agents/saf/lga/lga_util.c
> +++ b/osaf/libs/agents/saf/lga/lga_util.c
> @@ -308,21 +308,17 @@ unsigned int lga_startup(lga_cb_t *cb)
>   osaf_mutex_lock_ordie(_lock);
>   
>   TRACE_ENTER2("lga_use_count: %u", lga_use_count);
> - if (lga_use_count > 0) {
> - /* Already created, just increment the use_count */
> - lga_use_count++;
> - goto done;
> - } else {
> +
> + if (cb->mds_hdl == 0) {
>   if ((rc = ncs_agents_startup()) != NCSCC_RC_SUCCESS) {
>   TRACE("ncs_agents_startup FAILED");
>   goto done;
>   }
>   
>   if ((rc = lga_create()) != NCSCC_RC_SUCCESS) {
> + cb->mds_hdl = 0;
>   ncs_agents_shutdown();
>   goto done;
> - } else {
> - lga_use_count = 1;
>   }
>   
>   /* Agent has successfully been started including
communication @@ 
> -331,6 +327,9 @@ unsigned int lga_startup(lga_cb_t *cb)
>   set_lga_state(LGA_NORMAL);
>   }
>   
> + /* Increase the use_count */
> + lga_use_count++;
> +
>done:
>   osaf_mutex_unlock_ordie(_lock);
>   
> @@ -361,8 +360,12 @@ unsigned int lga_shutdown_after_last_cli
>   /* Users still exist, just decrement the use count */
>   lga_use_count--;
>   } else if (lga_use_count == 1) {
> - lga_destroy();
> - rc = ncs_agents_shutdown();
> + /*
> +  * Disable MDS_UNINSTALL and ncs agent shutdown to keep MDS
connection.
> +  * Fix ticket 1396. Msg NCSMDS_DOWN and Initialize are out
of order in Mbx.
> +  */
> + /* lga_destroy(); */
> + /* rc = ncs_agents_shutdown(); */
>   lga_use_count = 0;
>   }
>   
> diff --git a/tests/logsv/logtest.h b/tests/logsv/logtest.h
> --- a/tests/logsv/logtest.h
> +++ b/tests/logsv/logtest.h
> @@ -27,6 +27,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   #include 
> diff --git a/tests/logsv/tet_saLogStreamOpen_2.c 
> b/tests/logsv/tet_saLogStreamOpen_2.c
> --- a/tests/logsv/tet_saLogStreamOpen_2.c
> +++ b/tests/logsv/tet_saLogStreamOpen_2.c
> @@ -704,6 +704,34 @@ done:
>   }
>   }
>   
> +/*
> + * Ticket 1396
> + * Verify that saLogInitialize() then saLogFinalize() multiple time 
> +OK  */ void saLogMultipleInitialize(void) {
> +SaLogStreamHandleT logStreamHandle1;
> +int count = 100;
> +SaAisErrorT rc = SA_AIS_OK;
> +
> +while (count--) {
> +rc = saLogInitialize(, ,
);
> +if (rc != SA_AIS_OK)
> +  

[devel] [PATCH 0 of 1] Review Request for log: fix trouble when the number app streams reachs limitation [#1446]

[Canh Truong]

Summary: log: fix trouble when the number app streams reachs limitation [#1446]
Review request for Trac Ticket(s): #1446
Peer Reviewer(s): Lennart, Anders W, Mathi, Vu
Pull request to: Lenart
Affected branch(es): 4.6, 4.7, default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 7214b787efa1088e407c89b016d0d16f30254c1a
Author: Canh Truong <canh.v.tru...@dektech.com.au>
Date:   Wed, 16 Mar 2016 10:31:24 +0700

log: fix trouble when the number app streams reachs limitation [#1446]

If number of app stream has reached the limitation, logsv get failed to 
add
this stream to stream array in ccbApplyCallback even though immsv 
creates
object successfully. This patch help check the limitation of app stream 
and
return the error to abort creating new app stream and new object.


Complete diffstat:
--
 osaf/services/saf/logsv/lgs/lgs_evt.cc|   6 ++
 osaf/services/saf/logsv/lgs/lgs_imm.cc|   7 ++-
 osaf/services/saf/logsv/lgs/lgs_stream.cc |  12 
 osaf/services/saf/logsv/lgs/lgs_stream.h  |   1 +
 tests/logsv/tet_LogOiOps.c|  74 
++
 tests/logsv/tet_saLogStreamOpen_2.c   |  72 

 6 files changed, 171 insertions(+), 1 deletions(-)


Testing Commands:
-
There are two new test cases to test solution of issue.
Run following commands to test:

logtest 2 52
logtest 5 28


Testing, Expected Results:
--
All test cases passed


Conditions of Submission:
-
 Get ack from peer reviewers


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications wit

[devel] [PATCH 1 of 1] log: fix trouble when the number app streams reachs limitation [#1446]

[Canh Truong]

 osaf/services/saf/logsv/lgs/lgs_evt.cc|   6 ++
 osaf/services/saf/logsv/lgs/lgs_imm.cc|   7 ++-
 osaf/services/saf/logsv/lgs/lgs_stream.cc |  12 +
 osaf/services/saf/logsv/lgs/lgs_stream.h  |   1 +
 tests/logsv/tet_LogOiOps.c|  74 +++
 tests/logsv/tet_saLogStreamOpen_2.c   |  72 ++
 6 files changed, 171 insertions(+), 1 deletions(-)


If number of app stream has reached the limitation, logsv get failed to add this
stream to stream array in ccbApplyCallback even though immsv creates object
successfully. This patch help check the limitation of app stream and return the
error to abort creating new app stream and new object.

diff --git a/osaf/services/saf/logsv/lgs/lgs_evt.cc 
b/osaf/services/saf/logsv/lgs/lgs_evt.cc
--- a/osaf/services/saf/logsv/lgs/lgs_evt.cc
+++ b/osaf/services/saf/logsv/lgs/lgs_evt.cc
@@ -1036,6 +1036,12 @@ static uint32_t proc_stream_open_msg(lgs
}
}
 
+   if (check_max_stream()) {
+   TRACE("The number of stream out of limitation");
+   ais_rv = SA_AIS_ERR_NO_RESOURCES;
+   goto snd_rsp;
+   }
+
/* Create the stream: 
 *  - Check parameters
 *  - Create the stream in the stream "data base"
diff --git a/osaf/services/saf/logsv/lgs/lgs_imm.cc 
b/osaf/services/saf/logsv/lgs/lgs_imm.cc
--- a/osaf/services/saf/logsv/lgs/lgs_imm.cc
+++ b/osaf/services/saf/logsv/lgs/lgs_imm.cc
@@ -1631,7 +1631,12 @@ static SaAisErrorT stream_ccb_completed_
SaAisErrorT rc = SA_AIS_ERR_BAD_OPERATION;
 
TRACE_ENTER2("CCB ID %llu", opdata->ccbId);
-   rc = check_attr_validity(immOiHandle, opdata);
+   if (!check_max_stream()) {
+   rc = check_attr_validity(immOiHandle, opdata);
+   } else {
+   report_oi_error(immOiHandle, opdata->ccbId,
+   "Number of stream out of limitation");
+   }
TRACE_LEAVE2("%u", rc);
return rc;
 }
diff --git a/osaf/services/saf/logsv/lgs/lgs_stream.cc 
b/osaf/services/saf/logsv/lgs/lgs_stream.cc
--- a/osaf/services/saf/logsv/lgs/lgs_stream.cc
+++ b/osaf/services/saf/logsv/lgs/lgs_stream.cc
@@ -1576,3 +1576,15 @@ int log_stream_config_change(bool create
TRACE_LEAVE();
return rc;
 }
+
+/*
+ * Check if number of stream out of LOG_MAX_APPLICATION_STREAMS
+ *
+ * @return
+ */
+bool check_max_stream()
+{
+   TRACE("  Current number of streams: %u", numb_of_streams);
+   return (numb_of_streams < stream_array_size ? false:true);
+}
+
diff --git a/osaf/services/saf/logsv/lgs/lgs_stream.h 
b/osaf/services/saf/logsv/lgs/lgs_stream.h
--- a/osaf/services/saf/logsv/lgs/lgs_stream.h
+++ b/osaf/services/saf/logsv/lgs/lgs_stream.h
@@ -124,6 +124,7 @@ extern log_stream_t *log_stream_get_by_n
 extern log_stream_t *log_stream_getnext_by_name(const char *name);
 extern void log_stream_print(log_stream_t *stream);
 extern log_stream_t *log_stream_get_by_id(uint32_t id);
+extern bool check_max_stream();
 void log_free_stream_resources(log_stream_t *stream);
 
 #endif
diff --git a/tests/logsv/tet_LogOiOps.c b/tests/logsv/tet_LogOiOps.c
--- a/tests/logsv/tet_LogOiOps.c
+++ b/tests/logsv/tet_LogOiOps.c
@@ -3495,6 +3495,78 @@ restore_notif:
rc = system(command);
 }
 
+
+/*
+ * Add test case for ticket #1446
+ * Verify that invalid Object if number of app streams has reached the 
limitation
+ *
+ */
+void verStrLimit(void)
+{
+   SaAisErrorT rc;
+   char command[1000];
+   uint32_t curAppCount, maxAppStream = 64;
+   uint32_t *tmp_to = 
+   int num = 0;
+   FILE *fp = NULL;
+   char curAppCount_c[10];
+
+   /* Get current max app stream values of attributes */
+   rc = get_attr_value(, "logMaxApplicationStreams",
+   (void**)_to, NULL);
+   if (rc != -1) {
+   maxAppStream = *tmp_to;
+   }
+
+   /*  Get current app stream */
+   sprintf(command,"(immfind -c SaLogStreamConfig && immfind -c 
SaLogStream) | wc -l");
+   fp = popen(command, "r");
+
+   while (fgets(curAppCount_c, sizeof(curAppCount_c) - 1, fp) != NULL) {};
+   pclose(fp);
+   /* Convert chars to number */
+   curAppCount = atoi(curAppCount_c) - 3;
+
+   for (num = curAppCount; num < maxAppStream; num++) {
+   /* Create configurable app stream */
+   sprintf(command,"immcfg -c SaLogStreamConfig  
safLgStrCfg=test%d"
+   " -a saLogStreamPathName=."
+   " -a saLogStreamFileName=test%d",
+   num, num);
+   rc = system(command);
+   if (WEXITSTATUS(rc)) {
+   /* Fail to perform the command. Report test case failed 
*/
+   fprintf(stderr, "Failed to perform command = %s\n", 
command);
+

[devel] [PATCH 0 of 1] Review Request for log: fix info represents by millisecond token is not correct [#1619]

[Canh Truong]

Summary: log: fix info represents by millisecond token is not correct [#1619]
Review request for Trac Ticket(s): #1619
Peer Reviewer(s): Lennart, Anders W, Mathi, Vu
Pull request to: Lennart
Affected branch(es): 4.7, default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset ba42ccf646021ea8b705b451431999d6fe4d77d7
Author: Canh Truong <canh.v.tru...@dektech.com.au>
Date:   Tue, 16 Feb 2016 15:24:54 +0700

log: fix info represents by millisecond token is not correct [#1619]

The milisecond token (@Ck, @Nk) does not reflect correctly. It is not
milisecond in the log record as expectation. This patch fixes the issue.


Complete diffstat:
--
 osaf/services/saf/logsv/lgs/lgs_fmt.cc |  12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)


Testing Commands:
-
 There is no new test cases added. To test this patch, please do following 
steps:

 1) Change log file format configure for system stream and Notification stream:
immcfg -a saLogStreamLogFileFormat='@Cr @Ch:@Cn:@Cs @Cm/@Cd/@CY @Ck @Sv 
@Sl @Cb' safLgStrCfg=saLogSystem,safApp=safLogService
immcfg -a saLogStreamLogFileFormat='@Cr @Ct @Nt @Ne6 @No30 @Ng30 @Nk 
"@Cb"' safLgStrCfg=saLogNotification,safApp=safLogService

 2) Write 20 log records continuously to System and Notification log streams:
for i in {1..20}; do saflogger -y "Test ticket 1619 - $i"; saflogger -n 
"Test ticket 1619 - $i"; done

 3) Check milisecond token display in System and Notification log file.
 

Testing, Expected Results:
--
 Three digits show in milisecond token increased continuously.


Conditions of Submission:
-
 Get ack from peer reviewers.


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Site24x7 APM Insight: