Hi,
Currently we have 2 Oracle adapters of the same name on two different machines connecting to the same broker. To the broker the two adapters act as one logically.
However, we encountered problems when the two adapters published a record from the notification table twice when it should only be once. Through the adapter debug printout from the two adapters, we discovered that both adapters processed the same record when by right only 1 of the adapter should process the record. This happens also for the subscribing adapters. When a document arrives, both of the adapters actually processed the same document and inserted into the database twice.
Can somebody please help? Where did we configure the adapters wrongly?
Thanks.
Gavin
The wM document has described this for adapter load balance as following and will solve your problem. Please note that not all adapters automatically have sharedEventOrdering property in the adapters.cfg file. If not there, you need manually add it into the adapters.cfg file.
Load Balancing Adapters:
Creating adapters on multiple machines, with the exact same name (and the same Client Group) connecting to the same broker, provides load balancing and failover capabilities. If for some reason one of the machines goes down, the other machine still has the adapter running. To achieve parallel processing of events by all the machines one has to ensure that the sharedEventOrdering property in the adapters.cfg file is set to none.
If configured as described above, the events are dispatched between the adapters in a round robin way. This is a very useful feature for implementing true adapter failover by hosting different instances in different machines as it does provide extended multiprocessing for heavy tasks (using sharedEventOrdering None).
Being able to distribute an adapter on different machines and have them run as one logical adapter is handy to guarantee “availability” and performance through multi-processing is a very good feature.
Note : You have to check that “State Sharing” is set to “Enabled” under “Manager/Clients/Sessions/” (that would correspond to “shared true” parameter in adapters.cfg but it doesn’t seem to be modifiable).
Many adapters have this parameter set to true by default.
This will not work. You basically have two instances of the same adapter, and these two instances will not be aware of each other. There’s no coordination between the two with regards to the notification. Both instances will think they own the buffer table and trigger, and will run CREATE and DROP statements when necessary. And both will go after the data in the buffer table, leading to potentially duplicate notifications.
There are some scenarios were configuring multiple identical database adapters is allowed:
- you have no notifications configured
- you have a failover scenario where you insure through the failover scripts that only one of the two is running at any time
- on the same host, using the “# of processes” settings in the Adapter Configuration tool.
If you do the later, then they will be run in a way so that only one of the instances handles the notifications.
Hi,
Thanks for the reply. I have found out from the adapter debug output that actually the adapters took the documents from the client queue in the correct sequence (Because I set the Broker Document Ordering to Publisher), but their processing time was erratic, resulting in sometimes adapter 1 finishing the integration first and sometimes adpater 2 finishing first.
I do not know whether there is a way to configure the two adapters in such a way that 1 adapter will wait for the other adpater to finish processing the integration before starting on its own.
Does anybody have any idea on this?
Regards,
Tet Cheng
Is there any relation between the “sharedEventOrdering” property in the adapters.cfg file and the “State Sharing” under “Manager/Clients/Sessions/” ?? I did not find any relation.
How do we write the failover scripts? Are these dependant on the machine or are they dependant on the adapter services/process?
Would appreciate any light on this …