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
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
>
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
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
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
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
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
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
;
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)
-
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
22 matches
Mail list logo