Attach a very first draft, it only comes from the need of handling CLM API
error code in thread in AMFD, 2 patches:
- ais_executor.diff: abstract executor as a helper to run AIS api. First
attempt will run AIS call as in host thread. If this call is denied (due to
TRY_AGAIN/TIMEOUT), next retry of this call will be executed in executor thread
- clm_executor.diff: This patch removes the way that AMFD currently is using
CLM API, and applies ais_executor, so that AMFD won't have to handle
TRY_AGAIN/TIMEOUT in AMFD's additional thread.
New way of using Clm via ais executor likely as below:
+ cb->clmExecutor.run(new CsaClmInitialize_4());
+ cb->clmExecutor.run(new CsaClmSelectionObjectGet());
+ cb->clmExecutor.run(new CsaClmClusterTrack_4());
There're still many things to be added and discussed to generalize the solution
for all services. I guess at this phase, one of many things is the interface
that how actual SAF services use dedicated threads
Attachments:
-
[ais_executor.diff](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/06f8bcbb/f547/attachment/ais_executor.diff)
(5.3 kB; text/x-patch)
-
[clm_executor.diff](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/06f8bcbb/f547/attachment/clm_executor.diff)
(15.6 kB; text/x-patch)
---
** [tickets:#1609] Introduce dedicated AIS handler threads**
**Status:** unassigned
**Milestone:** future
**Created:** Tue Nov 24, 2015 09:03 AM UTC by Anders Widell
**Last Updated:** Wed May 04, 2016 05:38 PM UTC
**Owner:** nobody
This is a generic cleanup ticket for introducing one or several dedicated AIS
handler threads in the OpenSAF services. The most urgent need is for the IMM
API calls, but a similar approach can be used for other AIS services as and
when needed.
The problem we are trying to solve is that sometimes, IMM API calls can be
blocked for a very long time (up to several minutes). The reason why IMM is
blocked is normally an ongoing sync, but there could be other reasons why an
AIS call (not only IMM) could be blocked:
* If we have circular dependencies between the OpenSAF services, and the
service we are depending on has not yet started
* The LOG service can be blocked due to a slow or unresponsive external disk or
NFS server
* The OpenSAF service we are trying to access is temporarily out of service
For IMM, we can motivate introduction of up to three separate IMM handler
threads:
* One thread acting as an IMM OI and / or applier. Note that this thread may
also need to have its own IMM OM handle.
* One thread for IMM OM CCB operations.
* One thread for IMM OM read / search operations. These operations are normally
fast though, since they should not be blocked by a sync, so we may not need a
separate thread for them. But as mentioned above, they may be blocked for other
reasons
The handler threads should exclusively own their AIS handle(s) and have their
own poll + dispatch loops. Communication between the main thread and the
handler thread should typically be done through a mailbox.
Refer e.g. to tickets [#1531] and [#1527] for issues related to this
enhancement, that have been identified in the LOG service. Similar cleanup is
needed in other OpenSAF services as well.
---
Sent from sourceforge.net because [email protected] 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.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
