Yes Oracle Fusion Middleware Online Documentation Library

Administrating Multi-Server Domains With Oracle CEP Native Clustering 7-11 6. Stop the server you just started. See Section 7.5, Starting and Stopping an Oracle CEP Server in a Multi-Server Domain . 7. Copy the .msasig.dat file you created in step 5 to the other servers. For example: prompt cd d:\oracle_cep\user_projects\domains\mydomain\server1 prompt cp .msasig.dat ..\server2 prompt cp .msasig.dat ..\server3 8. If you plan to use Oracle CEP Visualizer with the servers in this domain, see Section 10.5.3, How to Configure SSL in a Multi-Server Domain for Oracle CEP Visualizer . 9. Start all servers in your multi-server domain. See Section 7.5, Starting and Stopping an Oracle CEP Server in a Multi-Server Domain .

7.4 Using the Multi-Server Domain APIs to Manage Group Membership Changes

In an active-active system, applications are deployed homogeneously across several servers and are actively executing. There are cases, however, when these homogeneously-deployed applications need to elect a primary one as the coordinator or leader. In this case, events that result from the coordinator application are kept and passed on to the next component in the EPN; the results of secondary servers are dropped. However, if the coordinator fails, then one of the secondary servers must be elected as the new coordinator. To enable this in an application, the adapter or event bean, generally in the role of an event sink, must implement the com.bea.wlevs.ede.api.cluster.GroupMembershipListener interface which allows the event sinks to listen for multi-server domain group membership changes. At runtime, Oracle CEP automatically invokes the onMembershipChange callback method whenever membership changes occur. The signature of the callback method is as follows: onMembershipChangeServer localIdentity, Configuration groupConfiguration; In the implementation of the onMembershipChange callback method, the event sink uses the Server object localIdentity to verify if it is the leader. This can be done be comparing localIdentity with the result of Configuration.getCoordinator run on the second parameter, groupConfiguration. This parameter also allows a server to know what the current members of the group are by executing Configuration.getMembers. In order to only keep events if it is a coordinator, the event sink must get a new Server identity every time membership in the group changes. Group membership changes occur if, for example, another server within the group fails and is no longer the coordinator. A similar interface com.bea.wlevs.ede.api.cluster.DomainMembershipListener exists for listening to membership changes to the domain as a whole, rather than just changes to the group.