Apama 10.3 | Apama Documentation | Developing Apama Applications | Developing EPL Plug-ins | EPL Plug-ins in C and C++ Written Prior to 10.0 | Advanced plug-in functionality in C++ and C | Working with blocking behavior in C++ plug-ins
Working with blocking behavior in C++ plug-ins
When the behavior of a C++ plug-in is that it never blocks or does not usually block you can declare the plug-in to be non-blocking. Even if one or more methods defined in a plug-in might block, you can declare the plug-in to be non-blocking and override the non-blocking designation for just the methods that might block. The benefit of declaring a plug-in to be non-blocking is that the correlator refrains from creating unneeded processing threads.
By default, the correlator assumes that any plug-in method or handler it calls might block for an arbitrary amount of time. Consequently, the correlator creates additional threads to continue processing other contexts. If the plug-in method/handler does not block, these extra threads represent an expense that could be avoided.
Declaring a plug-in as non-blocking
To declare a plug-in as non-blocking, define an AP_PLUGIN_GET_CAPABILITIES_FUNCTION_NAME function that returns AP_CAPABILITIES_NON_BLOCKING. See the AP_PluginCommon.h header file in the include directory of your Apama installation directory for the definition of AP_PLUGIN_GET_CAPABILITIES_FUNCTION_NAME. The correlator calls this function before it calls the plug-in's init() function. The return value is an AP_Capabilities object that contains a bit-wise OR of capabilities, as defined in the AP_PluginCommon.h header file.
When you declare a plug-in to be non-blocking the correlator lets plug-in methods and any plug-in event handlers process to completion without spawning new threads.
You must ensure that a plug-in declared to be non-blocking does not block. If a non-blocking plug-in does block it can cause a correlator deadlock. To avoid this, for each plug-in method that might block, be sure to override the non-blocking designation. For example, consider a method that accesses a local cache. Normally, this method would not block. However, if the method uses a remote process when the needed object is not in the local cache then the method might block. You must override the non-blocking designation for a method such as this one.
Overriding the non-blocking designation for particular methods
A plug-in that you declare as non-blocking can have one or more methods that might block. In each method that might block, you must call the pluginMethodBlocking() function on either an AP_Context object or an AP_CorrelatorInterface object. The signature for the pluginMethodBlocking() function is as follows for each type of object:
void pluginMethodBlocking();
Calling pluginMethodBlocking() is idempotent. A call to pluginMethodBlocking() informs the correlator that the containing method might block and that the correlator should start additional threads to compensate.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.