date:20190326

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

2019-03-26 Thread Lennart Lund

Hi Canh,

You are right about that configuration streams except the "well known" ones can 
be deleted but if the stream configuration object exist and numOpeners = 0 
there is an inconsistency that must be considered as "out of synch" that 
requires a restart.

Regards
Lennart

From: Canh Van Truong 
Sent: den 26 mars 2019 10:17
To: Lennart Lund ; Vu Minh Nguyen 

Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Thanks Lennart,

Please my comments.

Regards
Canh
From: Lennart Lund mailto:lennart.l...@ericsson.com>>
Sent: Tuesday, March 26, 2019 3:41 PM
To: Canh Van Truong 
mailto:canh.v.tru...@dektech.com.au>>; Vu Minh 
Nguyen mailto:vu.m.ngu...@dektech.com.au>>
Cc: 
opensaf-devel@lists.sourceforge.net;
 Lennart Lund mailto:lennart.l...@ericsson.com>>
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Hi Canh,

I don't really understand what you suggest and how this will keep standby and 
active in sync. However, there are two things I would like to mention:

  1.  It is not only the "well known streams" if you by this means the alarm, 
notification and system streams that must never have 0 openers. This applies to 
all streams having a configuration object in the IMM model.
[Canh] 1/ Create configuration app stream with configuration object in IMM. 
Numopener =1
immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp5 -a saLogStreamPathName=. -a 
saLogStreamFileName=TestApp5

2/ Delete cfg stream: Numopeners =0, log file is closed, ...
immcfg -d  safLgStrCfg=TestApp5


  1.  If standby gets checkpoint data where something wrong can be detected, 
for example leading to numOpeners = 0 for a stream where this shall never 
happen, then standby and active is "out of synch". The "normal" behavior is 
then to exit the standby process in order to be restarted which will trig a 
"cold synch". Note that normally the whole node is restarted in such a case but 
it is possible to just restart the log server process. Check how this is 
handled in other places where an "out of synch" restart is done.
[Canh] Yes. It should be restarted the standby node. I am testing it.

Regards
Lennart

From: Canh Van Truong 
mailto:canh.v.tru...@dektech.com.au>>
Sent: den 25 mars 2019 04:50
To: Lennart Lund mailto:lennart.l...@ericsson.com>>; 
Vu Minh Nguyen mailto:vu.m.ngu...@dektech.com.au>>
Cc: 
opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Thanks all,

With the case that causes the osaflogd crash (the "numOpeners" of "well know 
stream" is 0), I suggest solution is that when the standby process the 
checkpoint of open stream, it should always check if the ("numOpeners" ckpt 
from active) less than ("numOpeners" of standby + 1), The "numOpeners" should 
not use the value that ckpt from active. It should be ("numOpeners" of standby 
+ 1).  Because there is one or more than one streams that client has not 
removed these streams to its owned list on standby while these streams already 
removed on active node.   Is it ok?

@Lennart:  Yes, the numOpeners of "well know streams" should never become 0 as 
you said. But some unexpected case as I mention in previous email it may become 
0 due to ckpt problem.
Only "well know streams" should not become 0. Other configuration streams (app 
cfg stream) can till be 0 in case no client own this stream  and the user 
deletes the stream in IMM data base and it will call the callback to delete 
stream in lgd(e.g. immcfg -d ...)

@aVu: As your mention the case, although the "numOpeners" in standby is less 
than one with active node, but the stream has not associated with the client by 
"lgs_client_stream_add()"in standby node.  When the active node reboot or split 
and the standby node is up to active, the client is down and will not close 
stream because "stream_list_root" list does not have that stream. So if my 
thinking is correct, that case won't cause the issue happen ?
There is already a log ER if ckpt fail "LOG_ER("%s: MBCSV send FAILED rc=%u.", 
__FUNCTION__, rc);"

Thanks
Canh

From: Lennart Lund mailto:lennart.l...@ericsson.com>>
Sent: Friday, March 22, 2019 7:40 PM
To: Vu Minh Nguyen 
mailto:vu.m.ngu...@dektech.com.au>>; Canh Van 
Truong mailto:canh.v.tru...@dektech.com.au>>
Cc: 
opensaf-devel@lists.sourceforge.net;
 Lennart Lund mailto:lennart.l...@ericsson.com>>
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Hi Canh,

Just a small comment.
For "Well known streams" it shall never be possible that numOpeners becomes 0 
since the log service itself is one of the "openers" (the first opener) and 
that "opener" is never closed. This also applies for any configuration stream 
(well known streams are also configur

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

2019-03-26 Thread Canh Van Truong

Thanks Lennart,

 

Please my comments.

 

Regards

Canh

From: Lennart Lund  
Sent: Tuesday, March 26, 2019 3:41 PM
To: Canh Van Truong ; Vu Minh Nguyen

Cc: opensaf-devel@lists.sourceforge.net; Lennart Lund

Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has
numOpeners = 0 [#3018]

 

Hi Canh,

 

I don't really understand what you suggest and how this will keep standby
and active in sync. However, there are two things I would like to mention:

1.  It is not only the "well known streams" if you by this means the
alarm, notification and system streams that must never have 0 openers. This
applies to all streams having a configuration object in the IMM model.

[Canh] 1/ Create configuration app stream with configuration object in IMM.
Numopener =1

immcfg -c SaLogStreamConfig  safLgStrCfg=TestApp5 -a saLogStreamPathName=.
-a saLogStreamFileName=TestApp5

 

2/ Delete cfg stream: Numopeners =0, log file is closed, .

immcfg -d  safLgStrCfg=TestApp5

 

2.  If standby gets checkpoint data where something wrong can be
detected, for example leading to numOpeners = 0 for a stream where this
shall never happen, then standby and active is "out of synch". The "normal"
behavior is then to exit the standby process in order to be restarted which
will trig a "cold synch". Note that normally the whole node is restarted in
such a case but it is possible to just restart the log server process. Check
how this is handled in other places where an "out of synch" restart is done.

[Canh] Yes. It should be restarted the standby node. I am testing it.

 

Regards

Lennart

 

From: Canh Van Truong mailto:canh.v.tru...@dektech.com.au> > 
Sent: den 25 mars 2019 04:50
To: Lennart Lund mailto:lennart.l...@ericsson.com> >; Vu Minh Nguyen
mailto:vu.m.ngu...@dektech.com.au> >
Cc: opensaf-devel@lists.sourceforge.net
 
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has
numOpeners = 0 [#3018]

 

Thanks all,

 

With the case that causes the osaflogd crash (the "numOpeners" of "well know
stream" is 0), I suggest solution is that when the standby process the
checkpoint of open stream, it should always check if the ("numOpeners" ckpt
from active) less than ("numOpeners" of standby + 1), The "numOpeners"
should not use the value that ckpt from active. It should be ("numOpeners"
of standby + 1).  Because there is one or more than one streams that client
has not removed these streams to its owned list on standby while these
streams already removed on active node.   Is it ok?

 

@Lennart:  Yes, the numOpeners of "well know streams" should never become 0
as you said. But some unexpected case as I mention in previous email it may
become 0 due to ckpt problem. 

Only "well know streams" should not become 0. Other configuration streams
(app cfg stream) can till be 0 in case no client own this stream  and the
user deletes the stream in IMM data base and it will call the callback to
delete stream in lgd(e.g. immcfg -d .)

 

@aVu: As your mention the case, although the "numOpeners" in standby is less
than one with active node, but the stream has not associated with the client
by "lgs_client_stream_add()"in standby node.  When the active node reboot or
split and the standby node is up to active, the client is down and will not
close stream because "stream_list_root" list does not have that stream. So
if my thinking is correct, that case won't cause the issue happen ?

There is already a log ER if ckpt fail "LOG_ER("%s: MBCSV send FAILED
rc=%u.", __FUNCTION__, rc);"

 

Thanks

Canh

 

From: Lennart Lund mailto:lennart.l...@ericsson.com> > 
Sent: Friday, March 22, 2019 7:40 PM
To: Vu Minh Nguyen mailto:vu.m.ngu...@dektech.com.au> >; Canh Van Truong
mailto:canh.v.tru...@dektech.com.au> >
Cc: opensaf-devel@lists.sourceforge.net
 ; Lennart Lund
mailto:lennart.l...@ericsson.com> >
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has
numOpeners = 0 [#3018]

 

Hi Canh,

 

Just a small comment.

For "Well known streams" it shall never be possible that numOpeners becomes
0 since the log service itself is one of the "openers" (the first opener)
and that "opener" is never closed. This also applies for any configuration
stream (well known streams are also configuration streams).

 

Regards

Lennart

 

From: Vu Minh Nguyen mailto:vu.m.ngu...@dektech.com.au> > 
Sent: den 22 mars 2019 09:30
To: Canh Van Truong mailto:canh.v.tru...@dektech.com.au> >; Lennart Lund
mailto:lennart.l...@ericsson.com> >
Cc: opensaf-devel@lists.sourceforge.net
 
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has
numOpeners = 0 [#3018]

 

Hi Canh,

 

Thanks for your good finding.

 

There is other possibility that well-known streams can be deleted as well.
Looking at below code, proc_stream_open_msg().

 

rc = lgs_mds_msg_send(cb, &msg, &evt->fr_dest, &evt->mds_ctxt,

Re: [devel] [PATCH 1/1] osaf: ensure an error is returned if takeover_request fails [#3023]

2019-03-26 Thread Hans Nordebäck

ack, review only/Thanks HansN

-Original Message-
From: Gary Lee  
Sent: den 26 mars 2019 02:05
To: Minh Hon Chau ; Hans Nordebäck 

Cc: opensaf-devel@lists.sourceforge.net; Gary Lee 
Subject: [PATCH 1/1] osaf: ensure an error is returned if takeover_request 
fails [#3023]

if we cannot read the result of a takeover_request, ensure we return an error
---
 src/osaf/consensus/consensus.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/osaf/consensus/consensus.cc b/src/osaf/consensus/consensus.cc 
index cf307b3..480f7d2 100644
--- a/src/osaf/consensus/consensus.cc
+++ b/src/osaf/consensus/consensus.cc
@@ -433,6 +433,8 @@ SaAisErrorT Consensus::CreateTakeoverRequest(const 
std::string& current_owner,
  return rc;
   }
 
+  // in case takeover request cannot be read  rc = 
+ SA_AIS_ERR_FAILED_OPERATION;
   // wait up to max_takeover_retry seconds for request to be answered
   retries = 0;
   while (retries < max_takeover_retry_) {
--
2.7.4



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

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

2019-03-26 Thread Lennart Lund

Hi Canh,

I don't really understand what you suggest and how this will keep standby and 
active in sync. However, there are two things I would like to mention:

  1.  It is not only the "well known streams" if you by this means the alarm, 
notification and system streams that must never have 0 openers. This applies to 
all streams having a configuration object in the IMM model.
  2.  If standby gets checkpoint data where something wrong can be detected, 
for example leading to numOpeners = 0 for a stream where this shall never 
happen, then standby and active is "out of synch". The "normal" behavior is 
then to exit the standby process in order to be restarted which will trig a 
"cold synch". Note that normally the whole node is restarted in such a case but 
it is possible to just restart the log server process. Check how this is 
handled in other places where an "out of synch" restart is done.

Regards
Lennart

From: Canh Van Truong 
Sent: den 25 mars 2019 04:50
To: Lennart Lund ; Vu Minh Nguyen 

Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Thanks all,

With the case that causes the osaflogd crash (the "numOpeners" of "well know 
stream" is 0), I suggest solution is that when the standby process the 
checkpoint of open stream, it should always check if the ("numOpeners" ckpt 
from active) less than ("numOpeners" of standby + 1), The "numOpeners" should 
not use the value that ckpt from active. It should be ("numOpeners" of standby 
+ 1).  Because there is one or more than one streams that client has not 
removed these streams to its owned list on standby while these streams already 
removed on active node.   Is it ok?

@Lennart:  Yes, the numOpeners of "well know streams" should never become 0 as 
you said. But some unexpected case as I mention in previous email it may become 
0 due to ckpt problem.
Only "well know streams" should not become 0. Other configuration streams (app 
cfg stream) can till be 0 in case no client own this stream  and the user 
deletes the stream in IMM data base and it will call the callback to delete 
stream in lgd(e.g. immcfg -d ...)

@aVu: As your mention the case, although the "numOpeners" in standby is less 
than one with active node, but the stream has not associated with the client by 
"lgs_client_stream_add()"in standby node.  When the active node reboot or split 
and the standby node is up to active, the client is down and will not close 
stream because "stream_list_root" list does not have that stream. So if my 
thinking is correct, that case won't cause the issue happen ?
There is already a log ER if ckpt fail "LOG_ER("%s: MBCSV send FAILED rc=%u.", 
__FUNCTION__, rc);"

Thanks
Canh

From: Lennart Lund mailto:lennart.l...@ericsson.com>>
Sent: Friday, March 22, 2019 7:40 PM
To: Vu Minh Nguyen 
mailto:vu.m.ngu...@dektech.com.au>>; Canh Van 
Truong mailto:canh.v.tru...@dektech.com.au>>
Cc: 
opensaf-devel@lists.sourceforge.net;
 Lennart Lund mailto:lennart.l...@ericsson.com>>
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Hi Canh,

Just a small comment.
For "Well known streams" it shall never be possible that numOpeners becomes 0 
since the log service itself is one of the "openers" (the first opener) and 
that "opener" is never closed. This also applies for any configuration stream 
(well known streams are also configuration streams).

Regards
Lennart

From: Vu Minh Nguyen 
mailto:vu.m.ngu...@dektech.com.au>>
Sent: den 22 mars 2019 09:30
To: Canh Van Truong 
mailto:canh.v.tru...@dektech.com.au>>; Lennart 
Lund mailto:lennart.l...@ericsson.com>>
Cc: 
opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] log: logd crash due to well known stream has 
numOpeners = 0 [#3018]

Hi Canh,

Thanks for your good finding.

There is other possibility that well-known streams can be deleted as well. 
Looking at below code, proc_stream_open_msg().

rc = lgs_mds_msg_send(cb, &msg, &evt->fr_dest, &evt->mds_ctxt,
MDS_SEND_PRIORITY_HIGH);

  // Checkpoint the opened stream
if (ais_rv == SA_AIS_OK) {
lgs_ckpt_stream_open(logStream, open_sync_param->client_id);
}

If the active node is rebooted or is split from the peer after sending OK reply 
to log agent *and* before forwarding the update to standby node,
the numberOpeners value at standby will be less than one comparing with the 
actual total number of connections toward that stream.

I think, we should log Warning or Error in case checkpoint data gets failed and 
never close well-known streams even the numberOpenners is zero(0).

Regards, Vu

From: Canh Van Truong 
mailto:canh.v.tru...@dektech.com.au>>
Sent: Friday, March 22, 2019 12:01 PM
To: 'Vu Minh Nguyen' 
mailto:vu.m.ngu...@dektech.com.au>>; 
lennart.l...@ericsson.com
Cc: 
opensaf-devel@lists.s

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

Re: [devel] [PATCH 1/1] osaf: ensure an error is returned if takeover_request fails [#3023]

Re: [devel] [PATCH 1/1] log: logd crash due to well known stream has numOpeners = 0 [#3018]

4 matches

Site Navigation

Mail list logo

Footer information