Hi Nagu,
changing/deleting saAmfCompNumMaxInstantiateWithoutDelay and then change
saAmfNumMaxInstantiateWithoutDelay, saAmfCompNumMaxInstantiateWithoutDelay
is not changed, do you mean not changed in IMM?
Looking at the amfnd traces the saAmfNumMaxInstantiateWithoutDelay is used
instead of
osaf/services/saf/amf/amfd/svctypecstypes.cc | 31 ++-
1 files changed, 29 insertions(+), 2 deletions(-)
AMF allows to create a SaAmfSvcTypeCSTypes object although the SaAmfCSType
object referred to does not exist.
Fix by looking up the SaAmfCSType DN in the
osaf/services/saf/amf/amfd/ctcstype.cc| 24
osaf/services/saf/amf/amfd/imm.cc | 7 ++--
osaf/services/saf/amf/amfd/include/util.h | 1 +
osaf/services/saf/amf/amfd/util.cc| 45 +++
4 files changed, 74 insertions(+), 3
diff --git a/osaf/services/saf/amf/amfd/si.cc b/osaf/services/saf/amf/amfd/si.cc
--- a/osaf/services/saf/amf/amfd/si.cc
+++ b/osaf/services/saf/amf/amfd/si.cc
@@ -874,13 +874,16 @@ static void si_admin_op_cb(SaImmOiHandle
* return an error.
*/
if
Reviewed, but not tested.
Ack from me.
One comment not related to the ticket.
Looking at the code after this change, while loop can be improved, and save
some time in execution. while(1) can be replaced with while(callback), then
if (callback) { and the false branch are not needed.
With this
While I agree that this code semms more compicated than it needs be,
I think in practice the optimization would not never happen.
Th dispatch functions should only be called as a result of poll triggering
on a selection object related to the dispatch.
I dont see how poll would get triggered if
osaf/services/saf/immsv/immnd/ImmModel.cc | 40 +++---
1 files changed, 30 insertions(+), 10 deletions(-)
The IMMND logs database size at certain threshold levels. The log severity
for these mesages was set to WArning as early as 5000 objects. The warning
severity
Summary: IMM: Reduce log severity database size messages [#866]
Review request for Trac Ticket(s): #866
Peer Reviewer(s): Neel; Zoran
Pull request to:
Affected branch(es): 4.3; 4.4; 4.5; default(4.6)
Development branch:
Impacted area Impact y/n
Ack with minor comment inline
Thanks,
Hans
-Original Message-
From: Nagendra Kumar [mailto:nagendr...@oracle.com]
Sent: den 8 september 2014 09:45
To: Hans Feldt; Hans Nordebäck; Praveen Malviya
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [devel] [PATCH 1 of 1] amfd:
Ack
/Hans
-Original Message-
From: Anders Bjornerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: den 5 september 2014 16:32
To: reddy.neelaka...@oracle.com; Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: [devel] [PATCH 2 of 2]
On every 10 objects, the same message will be written twice to the log.
Ack when the comment is fixed.
Best regards,
Zoran
-Original Message-
From: Anders Björnerstedt
Sent: den 8 september 2014 11:28
To: reddy.neelaka...@oracle.com; Zoran Milinkovic
Cc:
Yes thanks.
I will introduce an 'else' branch before pushing.
/AndersBj
Zoran Milinkovic wrote:
On every 10 objects, the same message will be written twice to the log.
Ack when the comment is fixed.
Best regards,
Zoran
-Original Message-
From: Anders Björnerstedt
Sent: den
After thinking a bit about Zoran's comment I think Neels patch is ok as it is.
The current patch fixes the problem reported by the ticket and it does not
introduce any new problem.
The optimization/simplification issue Zoran points to has always been there,
should be tiny in its
effect and
In 2PBE case safImmService is the admin owner for object
opensafImm=opensafImm,safApp=safImmService. By default when 2PBE is
coming up safImmService is set as adminowner for object
opensafImm=opensafImm,safApp=safImmService . The same requirement is not
there for 1PBE. No, change in the
Hi AndersBj,
For every 1 objects:
Sep 8 19:46:44.996095 osafimmnd [20971:ImmModel.cc:7471] IN Number of
objects in IMM is:1
Sep 8 19:46:44.996101 osafimmnd [20971:ImmModel.cc:7476] TR Number of
objects in IMM is:1
For every 10
Sep 8 19:47:35.927542 osafimmnd
I also have to ask *why* does this application or test think it needs private
admin-ownership of this imm service object ?
Exactly what is it trying to do with
'opensafImm=opensafImm,safApp=safImmService' ?
/AndersBj
-Original Message-
From: Neelakanta Reddy
Whatever it is you are trying to do, I can still say that instead of a brutal
adminOwnerClear,
To force the immsv out of admin-ownersip on these object ... followed by an
adminOWnerSet to your
private (and arbitrary) admin-owner-name, you should instead set your
admin-owner to the SAME name
I have two doubts, please see inline.
Thanks,
Praveen
On 08-Sep-14 1:05 PM, Hans Feldt wrote:
osaf/services/saf/amf/amfd/ctcstype.cc| 24
osaf/services/saf/amf/amfd/imm.cc | 7 ++--
osaf/services/saf/amf/amfd/include/util.h | 1 +
osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc | 112 +++
1 files changed, 89 insertions(+), 23 deletions(-)
smfd handle all possible return codes from the SI_SWAP admin operation.
diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc
Summary: smfd: better handling of admin op SI_SWAP return codes
Review request for Trac Ticket(s): 940
Peer Reviewer(s): Anders Widell
Pull request to:
Affected branch(es): 4.3 4.4 4.5 default
Development branch: default
Impacted area Impact y/n
20 matches
Mail list logo
