![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
The TIBCO Adapter SDK allows flexible, platform-independent multithreading. This section discusses the following aspects of multithreaded adapters:A thoughtful multithreaded design may help a custom adapter achieve a greater level of concurrency and performance in terms of latency.
Consider carefully whether the custom adapter requires multiple threads. Threads result in a more complex programming logic and are therefore more error-prone and more difficult to debug. In addition, a multithreaded SDK-based adapter consumes more resources than a single-threaded one on a single-CPU machine.
− For custom adapter that uses blocking synchronous methods, is deployed on multi-CPU platform, or both.To fully exploit a multiprocessor system, the custom adapter running on it should also be multithreaded.Multithreading is useful for a server that takes one request at a time, and then spends most of its time blocking on I/O. In this case, the server would have unacceptable performance running as a single-threaded application. With a pool of threads, each thread can work on one request and several requests can be handled simultaneously, making use of otherwise idle processor cycles.Processing resources may not be the only factor hindering adapter performance. The interface supported by the target application can also be a bottleneck that eliminates any benefit resulting from multithreading the adapter. Multithreading cannot address performance issues caused by system resource bottlenecks.While TIBCO Messaging delivers messages in the order sent to the adapter on a single transport, a multithreaded adapter may not process the messages in the order received.
All C++ custom adapters that implement multithreading must set the multithread behavior in C++ SDK by calling the MAppProperties::setMultiThreaded().It is recommended to make an adapter multithreaded using the TIBCO Adapter SDK MDispatcher class. The different constructors for MDispatcher allow you to associate each instance with either an MApp application manager or with an MApp and an MSession.Custom adapters can create an instance of MDispatcher to spawn a thread that dispatches events for a given session. The MDispatcher class can be used with both MRvSession and MJmsSession.Creating a multithreaded adapter is typically a matter of determining which session requires additional threads and constructing the appropriate MDispatcher objects.
In addition to the new MDispatcher class, the following classes can be used in a multithreaded fashion:
• MClassRegistry is thread safe and thread aware. As a result, you can serialize and deserialize across threads.
• MTrace is thread safe and thread aware. You can therefore perform tracing across threads.
• The SDK may need to handle events that are not attached to any explicit MSession, for example, TIBCO Hawk messages or internal events. These events must be handled through the main MApp event manger with the MApp::nextEvent() call.If MApp::start() is called with no arguments or with Mtrue, the SDK handles these events automatically. The correct synchronized shutdown behavior of a multithreaded adapter depends on dispatching these events. If an adapter fails to ensure that MApp::nextEvent() is called during shutdown, the behavior of the SDK is undefined.If all the dispatchers you created are associated with one session (and therefore with a single event queue), the multithreading adapter program proceeds as follows:
1. Thread 1 picks the first item of the queue and executes the onEvent() method.
2. When the next thread, thread 2, becomes available, it picks the second item and executes the onEvent() method.
3. When the next thread, again thread 2, becomes available, it picks the third item and executes the onEvent() method.Figure 21 Multithreading for Single Event Queue
• Associate the MDispatcher with MApp. This gives each session equal weight when a thread becomes available.
• You can also use a combination approach, that is, associate some MDispatchers with MApp, then create additional dispatchers and associated it with a session that has priority over all other sessions.
1. When setting up the MAppProperties instance for the adapter, call MAppProperties::setMultiThreaded(); to turn on multi-threading.You can turn multi-threading off by calling MAppProperties::setMultiThreaded (MFalse).The C++ SDK is single-threaded by default and will only behave correctly for multithreaded custom adapters that make this call. The following example fragment from mt_rpc shows how the call is made as part of main().
appProperties.set( MAppProperties::APPCONFIGURL, "/tibco/private/adapter/examples/mt_rpc/mt_rpc_client");
2.
}
The custom adapter must also handle inter-thread communication and any locking concerns explicitly.The mt_pubsub demonstrates how to write a multithreaded adapter using MDispatcher. Each time an instance of MDispatcher is created, a new thread is spawned to dispatch incoming events on the relevant MSession. The additional threads allow the subscriber to remain responsive facing lengthy operations.
1. In the onInitialization() method, create instances of MDispatcher, as follows. The dispatchers are associated with a session.
2. In onTermination(), you must stop all the dispatchers created earlier.
// stop all the dispatchers that were created during //onInitialization
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |