Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-21 Thread A V Mahesh
Hi HansN, >> any how GA is tagged. Sorry I mean RC2 tagged -AVM On 9/21/2016 12:41 PM, A V Mahesh wrote: > Hi HansN, > > I just tested with uniform buffer sizes in all nodes and sending > messages with normal phase the results looks OK, > even after hitting the TIPC_ERR_OVERLOAD. > > So my

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-21 Thread A V Mahesh
Hi HansN, On 9/20/2016 4:17 PM, Hans Nordebäck wrote: > Hi Mahesh, > > I think only logging is needed as proposed in the patch, as some services are > already handling dropped messages. This logging will help in > trouble shooting. Keeping TIPC_DEST_DROPPABLE to true will only make TIPC to >

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-20 Thread Hans Nordebäck
Hi Mahesh, I think only logging is needed as proposed in the patch, as some services are already handling dropped messages. This logging will help in trouble shooting. Keeping TIPC_DEST_DROPPABLE to true will only make TIPC to silently drop messages, the original problem persists and needs

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-20 Thread A V Mahesh
HI Anders Widell / HansN, On 9/16/2016 2:03 PM, Anders Widell wrote: > The idea was to just log reception of error info messages, for > trouble-shooting purposes. After multiple attempts, i manged to simulate TIPC_ERR_OVERLOAD error.After TIPC_ERR_OVERLOAD error is hit the cluster going

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-16 Thread Anders Widell
I don't think we need (or even should) inform the sender when MDS receives an error information message from TIPC. Note that these error information messages are received asynchronously, when the sender has already received an OK return code from the MDS send call. The idea was to just log

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-15 Thread A V Mahesh
Hi HansN, I managed to create TIPC_ERRINFO/TIPC_RETDATA error cases ( not TIPC_ERR_OVERLOAD error ) with normal messages and It is observed that TIPC_DEST_DROPPABLE set to true even error TIPC_ERRINFO is NOT notified ( it means TIPC_ERR_OVERLOAD ) , if TIPC_DEST_DROPPABLE set to false

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-08 Thread A V Mahesh
Hi HansN, So far I was not successful in creating TIPC_ERR_OVERLOAD case , so I am planing to rebuilding `tipc.ko` with less OVERLOAD_LIMIT_BASE value of tipc. Currently I am working on priority open tickets on the 5.1.RC1 milestone, I will get back to you soon. -AVM On 9/8/2016 2:02 PM, Hans

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-09-08 Thread Hans Nordebäck
Hi Mahesh, Any updates on this? /Thanks HansN -Original Message- From: A V Mahesh [mailto:mahesh.va...@oracle.com] Sent: den 1 september 2016 07:55 To: Hans Nordebäck Cc: opensaf-devel@lists.sourceforge.net; Anders Widell ;

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-31 Thread Hans Nordebäck
Hi Mahesh, I have not tested this, but the following should work: - Set BSRsock TIPC_IMPORTANCE to TIPC_LOW_IMPORTANCE - set socket receive buffer to a small value: optval = "small socket recieive buffer size" , 5000 ? setsockopt(tipc_cb.BSRsock, SOL_SOCKET, SO_RCVBUF, , optlen) -

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-31 Thread A V Mahesh
Hi HansN, Sorry for the delay. I will test it and get back to you soon. -AVM On 8/31/2016 4:29 PM, Hans Nordebäck wrote: > Hi Mahesh, > Any updates on this? > > /Regards HansN > > -Original Message- > From: Anders Widell > Sent: den 25 augusti 2016 13:11 > To: A V Mahesh

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-25 Thread Anders Widell
Hi! This is what the TIPC user documentation says about TIPC_DEST_DROPPABLE: "This option governs the handling of messages sent by the socket if the message cannot be delivered to its destination, either because the receiver is congested or because the specified receiver does not exist. If

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-25 Thread A V Mahesh
Hi HansN, On 8/23/2016 5:22 PM, Hans Nordebäck wrote: > Hi Mahesh, > > Yes, this is my understanding too, if TIPC_DROPPABLE = true tipc may drop > messages silently, at receive sock buffer full condition, but do not return > any ancillary message. > If TIPC_DROPPABLE = false tipc may drop

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread Hans Nordebäck
Hi Mahesh, Yes, this is my understanding too, if TIPC_DROPPABLE = true tipc may drop messages silently, at receive sock buffer full condition, but do not return any ancillary message. If TIPC_DROPPABLE = false tipc may drop message but will send an ancillary message to inform about

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread A V Mahesh
Hi HansN, It seems I am missing some thing , please allow me to under stand If I currently understand you observation : With current Opensaf code ( this #1957 patch NOT applied ) , by default TIPC_DROPPABLE=true ,while running Opensaf with that binary when TIPC_ERR_OVERLOAD occurring, TIPC

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread Hans Nordebäck
Hi Mahesh, Please see response below with [HansN] /Thanks HansN -Original Message- From: A V Mahesh [mailto:mahesh.va...@oracle.com] Sent: den 23 augusti 2016 08:25 To: Hans Nordebäck ; Anders Widell ; mathi.naic...@oracle.com

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread Anders Widell
Hi! I don't think the sender would need to unconditionally abort() down in the MDS layer when it gets back an undelivered message from TIPC. We have the message loss callback in MDS, which can be used by the receiver to detect lost messages. The receiver can take an appropriate action when it

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread A V Mahesh
Hi HansN Please see response below with [AVM] -AVM On 8/23/2016 11:41 AM, Hans Nordebäck wrote: > Hi Mahesh, > > please see comments below. > > /Thanks HansN > > > On 08/23/2016 07:21 AM, A V Mahesh wrote: >> Hi HansN, >> >> Let us fist discuss the error handling and abort, then we can come >>

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-23 Thread Hans Nordebäck
Hi Mahesh, please see comments below. /Thanks HansN On 08/23/2016 07:21 AM, A V Mahesh wrote: > Hi HansN, > > Let us fist discuss the error handling and abort, then we can come > back to > interpretation of TIPC currently does permit OR does not permit an > application to send > a

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-22 Thread A V Mahesh
Hi HansN, Let us fist discuss the error handling and abort, then we can come back to interpretation of TIPC currently does permit OR does not permit an application to send a multicast message with the "destination droppable" setting disabled. Let us disable TIPC_DEST_DROPPABLE, so that TIPC

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-19 Thread A V Mahesh
Ok I need some time to re-check the TIPC code , will back to you soon. -AVM On 8/19/2016 1:46 PM, Hans Nordebäck wrote: > Hi Mahesh, > > there is a problem that TIPC may silently drop messages at overload > situations, as MDS uses the SOCK_RDM option. > > At least it has to be logged when

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-19 Thread Hans Nordebäck
Hi Mahesh, there is a problem that TIPC may silently drop messages at overload situations, as MDS uses the SOCK_RDM option. At least it has to be logged when messages are dropped. It is allowed in TIPC to set TIPC_DROPPABLE=false and also use multicast. The concern may be that the send buffer

Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]

2016-08-18 Thread A V Mahesh
Hi HansN, It seem you missed to see below : On 8/12/2016 9:11 AM, A V Mahesh wrote: > Hi HansN, > > We were having ticket for this raised by Hans Feldt > `https://sourceforge.net/p/opensaf/tickets/634/` > > at that time i have give my analysis base the MDS code at that time as > below please