Hi Neel,
I am reviewing #25 and #957 and I just have an initial comment about
immutils.
Both patches update immutils (I actually dont remember the reason why
#35 needed to update immutils but it
must be due to reasons of convenience in the implementation of #35).
The problem is that immutils.[h
Hi AndersBj,
The immutil is updated in #35 because a new utill API
immutil_saImmOiAdminOperationResult_o2 is added.
Which is used as a part of #35.
While pushing the patch, samples/immsv/immutils/ will be updated with
new added API.
/Neel.
On Wednesday 13 August 2014 01:31 PM, Anders Bjorners
For each patch you should edit the opensaf immutils, then copy it over the
samples immutils.
That way you will correct also the omission introduced earlier.
Bottom line is that the two samples versions should be identical.
There could at some point be a reason for having some samples functionali
Anders Björnerstedt wrote:
> Bottom line is that the two samples versions should be identical.
>
Sigh
that should have been "the two immutils versions"...
/AndersBj
--
___
O
Hi Mahesh,
>>- A single multicast message can accommodate max of MDS_DIRECT_BUF_MAXSIZE
>> (2^16).
The above limit can be removed, because IMM can send the event with grater than
(2^16) size.
After running multiple regression test and do a failover the following is
observed:
The testca
Why is the finalizesync message so big?
I think that is a concern if we have a mw that broadcasts big blobs without any
upper limit.
As a fix now MDS could instead of failing the broadcast send when the message
if greater than 2^16, revert to the old multi-unicast.
Thanks,
Hans
> -Origina
Hi Hans,
The filayzesync message contains adminownerhandles(not yet finalized)
with their objects, implementers and classnames.
If the cluster is running for long time(or more number of
classes/implementers/adminowners), then there is possibility of the
finalyzesync message may cross (2^16).
On 8/13/2014 3:30 PM, Hans Feldt wrote:
> Why is the finalizesync message so big?
>
> I think that is a concern if we have a mw that broadcasts big blobs without
> any upper limit.
I to have the same opinion.
>
> As a fix now MDS could instead of failing the broadcast send when the message
The potential size of the finalizeSync message is nothing new.
It has always been like this.
So I dont understand why this comes up now?
Either the test is new.
Or there must be som *change* in MDS in 4.5 that has made the broadcast
handling of large messages
more restrictive on size!
AndersBj
Hi,
Yes, I think this can be pushed now. We can take up further comments
subsequently.
Mathi.
- minh.c...@dektech.com.au wrote:
> Hi all,
>
> Do we have any comments on the latest patch? If not, can we push it
> for
> 4.5 FC?
> I have a small patch that Lennart recommended to add the tes
Such a fix is ok, as long as there is no risk of a subsequent broadcast
*overtaking*
a previous multi-unicast when received at some/any node.
/AndersBj
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: den 13 augusti 2014 12:11
To: Hans Feldt; Neelakanta Reddy
tests/logsv/tet_LogOiOps.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
Fix incorrect testing of saLogStreamMaxFileSize.
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
@@ -450,7 +450,7
osaf/libs/saf/include/saLog.h |8 +-
osaf/services/saf/logsv/lgs/lgs_imm.c | 806 +++-
osaf/services/saf/logsv/lgs/lgs_util.c |2 +-
3 files changed, 667 insertions(+), 149 deletions(-)
Fix incorrect existing validation and add missing validation
wh
Summary: Fix validity check for IMM create/modify stream
Review request for Trac Ticket(s): #448
Peer Reviewer(s): mathi.naic...@oracle.com
Pull request to: <>
Affected branch(es): 4.3, 4.4, 4.5 (devel)
Development branch: <>
Impacted area Impact y/n
tests/logsv/tet_LogOiOps.c | 798 -
1 files changed, 795 insertions(+), 3 deletions(-)
Add new test suite for testing validation of attributes when creating or
modifying
stream configuration object
diff --git a/tests/logsv/tet_LogOiOps.c b/tests/log
I think we can push this and continue reviewing / testing after it has
been pushed. Right now I have two review comments:
1)
I think there is an integer underflow bug in the code below:
+ size_t length_to_copy;
+ void *p;
+
Hi Neel,
Ack on #957 witth the following comment:
In immutil.h there is a duplicate declaration of the old immutils call:
extern SaAisErrorT immutil_saImmOmCcbObjectCreate_2(SaImmCcbHandleT
immCcbHandle,
const SaImmClassNameT
className,
Hi Neel,
Good work.
Ack from me on this patch with just the following comment.
If you have time ...
We use four spaces (not tab) as indentation in ImmModel.cc
There are even some accidental indentation changes, where there is no change
except a change of indentation. Such as line 10973 in th
> -Original Message-
> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
> Sent: den 1 augusti 2014 17:57
> To: Hans Feldt; Anders Björnerstedt; ramesh.bet...@oracle.com;
> mahesh.va...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 3 of 3] immnd: ad
Ack from me.
/AndersBj
-Original Message-
From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com]
Sent: den 7 augusti 2014 10:35
To: Hans Feldt; Anders Widell; Anders Björnerstedt
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 2 of 3] imm: tune imm macros according to md
20 matches
Mail list logo
