- **status**: review --> fixed
- **Comment**:

Long description is added in the pushed code.

changeset:   5149:e3aaf51b69f4
tag:         tip
user:        Zoran Milinkovic <zoran.milinko...@ericsson.com>
date:        Tue Apr 15 11:12:31 2014 +0200
summary:     IMM: release inactive search handles [#47]



---

** [tickets:#47] IMM: Auto relase of lingering search handles**

**Status:** fixed
**Milestone:** 4.5.FC
**Created:** Wed May 08, 2013 07:43 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Apr 01, 2014 08:58 AM UTC
**Owner:** Zoran Milinkovic

Migrated from:
http://devel.opensaf.org/ticket/3107



Tickets #3036 #2977 introduced a sanity limit on the number
of coexisting search hadnles per om-handle.

The main reason behind that enhancement was to catch application
resource leaks (of search handles); provide a clear error
indication instead of unpredictable system degradation; and forcing
the application to deal with the problem instead of having immsv
maintainers perpetually involved in locating application resource
leaks.

There is however a problem.
It turns out that there are applications that "legitimately" need
to allocate thousands of coexisting searches handles under one
om-handle and the introduced limit is not backwards compatible for
such applications.

Although such applications could in principle set the

    IMMA_MAX_OPEN_SEARCHES_PER_HANDLE

environment variable to a correspondingly high value, that
would have to be done in an upgrade step associated with the
application, before upgrading to OpensAF 4.3. This assumes that
the application maintainers are communicating with the people
doing the upgrade, which can not be guaranteed.
So in our deployment, the limit mechanism of #2977 and #3036 will
be disabled.

An alternative mechanism, is for the server to unilaterally
de-allocate lingering search handles, if the number of handles
exceed the configurable limit AND some handles have been inactive
beyond some time limit. The time limit would be on the order of 10
minutes. The time limit should not need to be configurable since
the application that has a problem can raise the number of allowed
handles.

The application trying to use a search handle that has been
de-allocated in the server would get BAD_HANDLE.
This is of course also not strictly backwards compatible in
terms of resource behavior, but it should be much lower in
risk of interfering with legitimate use, or incorrect use that
would be problematic to expose during an upgrade.



---

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.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

Reply via email to