- **status**: unassigned --> wontfix
- **assigned_to**: Nagendra Kumar
- **Milestone**: future --> 5.1.FC
- **Comment**:
Closing it as it doesn't look a need for now.
---
** [tickets:#357] AMF node director prioritizes incoming messages wrong**
**Status:** wontfix
**Milestone:** 5.1.FC
**Created:** Fri May 31, 2013 03:21 AM UTC by Nagendra Kumar
**Last Updated:** Fri Aug 07, 2015 09:31 AM UTC
**Owner:** Nagendra Kumar
Migrated from http://devel.opensaf.org/ticket/1692
Found this analyzing the code trying to resolve issues from testing with a
large AMF model, again many SIs assigned to one SU.
New assignments coming from the AMF director has the same message priority as
responses from a local AMF application. The problem is the responses have hard
real time requirements. They are supervised by the AMF node director. Callback
timeout, health check timeout etc.
I therefore think the responses should have higher prio than messages from the
AMF director.
The question is if all AMF director messages should have lower prio or just
some?
Changed 2 years ago by marioa ¶
Double-check that miss-behaving app can not cut-off communication between AvD
and AvND; meaning that hopefully Ava lib will detect and reject
messages/responses from App if there is no pared invocation request.
/Mario
Changed 2 years ago by hafe ¶
This is related to
http://list.opensaf.org/pipermail/devel/2011-January/013900.html
An idea, how about lowering the MDS prio of the incoming SUSI-ASSIGN message in
AMFND instead of increasing the MDS prio of all AVA messages?
That is targeting this particular use case without interfering with existing
logic. It will leave timers at a higher prio than all AVA messages but making
sure AVA responses are handled before new assignments.
In theory other AMFND incoming messages from AMFD can result in the same
problem (false timeouts). For example dynamically adding a new SU with many
components). But let's take one problem at a time.
Thanks,
Hans
On 01/12/2011 12:00 PM, OpenSAF Trac wrote:
Changed 2 years ago by erannjn ¶
Tested AVND_EVT_AVD_INFO_SU_SI_ASSIGN_MSG with low priority and it works, no
restarts, no core dumps, etc.
To me this change make sense. But off course, component could in theory
overload AVND with normal prio messages, halting processing of incoming
assignments. Still I think this is the "most" correct priority handling in
order to avoid component restart that could trigger node reboot.
I will send a patch for review.
/Niclas
Hans Feldt wrote:
Changed 2 years ago by hafe ¶
■status changed from new to closed
■resolution set to fixed
opensaf-staging:
changeset: 1915:170e943cfb10
tag: tip
user: Niclas Johansson <niclas.c.johansson@…>
date: Tue Feb 08 15:06:49 2011 +0100
summary: avsv: low priority for incoming assignments (#1692)
Changed 2 years ago by erannjn ¶
■status changed from closed to reopened
■resolution fixed deleted
changeset reversed:
changeset: 1919:e3592b9ddcdc
tag: tip
user: Niclas Johansson <niclas.c.johansson@…>
date: Fri Feb 18 10:52:02 2011 +0100
summary: Reverse changeset 1915 (ticket #1692)
The message seq numbering is not working correctly as normal prio
messages will be handled before low prio messages, even if low prio
messages were sent before. This is off course obvious and the reason for
using/changing priority, but we never thought of the message sequence
consequences. In the long run I think we need to consider how the
message sequence/transaction ID handling should be working, but in the
short run I see no other option then reversing the changeset 1915.
Feb 18 06:13:13 SC-2-1 osafamfnd[23029]: Message id mismatch! Received id: 8
Feb 18 06:13:13 SC-2-1 osafamfnd[23029]: avnd_evt_avd_set_leds_evh,Message Id
mismatch:10
Feb 18 06:13:13 SC-2-1 osafamfnd[23029]: avnd_evt_avd_info_su_si_assign_evh 241
Message Id mismatch, received msg id = 9
Feb 18 06:13:13 SC-2-1 osafamfnd[23029]: avnd_evt_avd_info_su_si_assign_evh 241
Message Id mismatch, received msg id = 11
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
