If we are to apply it to more than the latest branch then we must declare it as
a defect.
We don't want to keep the ticket state signaling clean.
In general you don't want enhancements on old releases because every change of
behavior has risk associated with it.
By only doing enhancements on the latest branch we keep the number of
"surprises" down on the older branches.
So instead of starting to have exception on enhancements handling, we need to
declare it as a defect to be applied on the latest 3 branches.
Long DNs was introduced in 4.5-
/AndersBj
From: elunlen [mailto:[email protected]]
Sent: den 17 augusti 2015 12:52
To: [opensaf:tickets]
Subject: [opensaf:tickets] Re: #1452 LOG: Use root name when searching for
stream objects
Maybe this an enhancement but what is the problem to apply this change to all
active branches anyway it's the most practical thing to do regardless of any
changes of handling long DNs that may be done in the future. This will not
change any behavior of the log service except that it maybe will start a little
bit faster and use less resources.
/Lennart
From: Anders Bjornerstedt [mailto:[email protected]]
Sent: den 17 augusti 2015 12:10
To: [opensaf:tickets]
Subject: [opensaf:tickets] Re: #1452 LOG: Use root name when searching for
stream objects
Possibly yes.
You could look at it this way.
Every application is free to perform unnecessarily inefficient searches.
A global search actually causes the local IMMND to copy the entire database.
In this case the LOg subtree probably contains less than 10 objects.
In general yes optimizations are enhancements and not defects.
Now we have the situation that we in OpenSAF 4.5 introduced support for
long DNs and this
is enabled by a config attribute in the immsv.
So suddenly what used to be simply a gross inefficiency in LOGSv has now
also become a problem for
users that want to deploy with long DNs but still want the LOG service
configured.
There exists no other suitale solutiion as I see it.
There was talk of filtering but an implicit filter does not work since
it implicitly changes the semantics of a search.
An explicit filter would be possible since then the application at least
is saying that I am prepared to receive
a partial result for the query. This works if the appliaction somehow
knows that all objects with logn DNs are not
relevant for it. In general that is a dangerous assumption.
But adding an explicit filter to the immsv is also an enhancement and
quite frankly more work than the fix
for the LOGsv to just scope its search appropriately to its own root object.
/AndersBj
On 08/17/2015 11:17 AM, Mathi Naickan wrote:
I guess we are not going round and round but probably just another
iteration on this topic! ;-)
I think this is not about any particular IMM user, Note that there are
more services that are performing this kind of 'searching from root'
thing.
The next question is what happens to the applications that have been
performing such search?
* Mathi.
________________________________
[tickets:#1452]<http://sourceforge.net/p/opensaf/tickets/1452/>http://sourceforge.net/p/opensaf/tickets/1452/
http://sourceforge.net/p/opensaf/tickets/1452/ LOG:
Use root name when searching for stream objects
Status: review
Milestone: 4.7-Tentative
Created: Fri Aug 14, 2015 12:34 PM UTC by elunlen
Last Updated: Mon Aug 17, 2015 07:47 AM UTC
Owner: elunlen
At startup the log server searches for stream configuration objects.
The search is done with no root object defined (NULL pointer for
rootName in parameter). Search root should be "safApp=safLogService".
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1452/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
________________________________
[tickets:#1452]<http://sourceforge.net/p/opensaf/tickets/1452/>http://sourceforge.net/p/opensaf/tickets/1452/
LOG: Use root name when searching for stream objects
Status: review
Milestone: 4.7-Tentative
Created: Fri Aug 14, 2015 12:34 PM UTC by elunlen
Last Updated: Mon Aug 17, 2015 09:17 AM UTC
Owner: elunlen
At startup the log server searches for stream configuration objects. The search
is done with no root object defined (NULL pointer for rootName in parameter).
Search root should be "safApp=safLogService".
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1452/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
________________________________
[tickets:#1452]<http://sourceforge.net/p/opensaf/tickets/1452/> LOG: Use root
name when searching for stream objects
Status: review
Milestone: 4.7-Tentative
Created: Fri Aug 14, 2015 12:34 PM UTC by elunlen
Last Updated: Mon Aug 17, 2015 09:17 AM UTC
Owner: elunlen
At startup the log server searches for stream configuration objects. The search
is done with no root object defined (NULL pointer for rootName in parameter).
Search root should be "safApp=safLogService".
________________________________
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opensaf/tickets/1452/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
---
** [tickets:#1452] LOG: Use root name when searching for stream objects**
**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Fri Aug 14, 2015 12:34 PM UTC by elunlen
**Last Updated:** Mon Aug 17, 2015 09:17 AM UTC
**Owner:** elunlen
At startup the log server searches for stream configuration objects. The search
is done with no root object defined (NULL pointer for rootName in parameter).
Search root should be "safApp=safLogService".
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
