| Resin - Failover During String of Non-Voice Elements |
| Categories: Audium 3.2.x |
| Article ID: | 19 |
| Last updated: | November 02, 2006 |
| User Opinions |
100%
0%
(1 vote)
|
|
Thank you for rating this answer.
|
SUMMARY
When using session replication on the Resin Java application server, a failover event occurring during the execution of a string of non-voice elements will cause those non-voice elements to run again on the backup server.
SYMPTOMS
When failover occurs, the backup server will start executing those elements that appear right after the last VoiceXML-producing element (voice or VoiceXML insert element) run by the primary server, even if other non-VoiceXML-producing elements (such as action and decision elements) have already be executed. For example, the following diagram shows some call flow for an application where a voice element is followed by three action elements followed by another voice element.
|
Voice Element 'A' |
|
Action Element 'B' |
|
Action Element 'C' |
|
Voice Element 'D' |
- The caller heard voice element A.
- Action element B was visited and completed.
- Action element C was executing when...
- The primary server went down, precipitating the backup server to take over the call.
The backup server is expected to pick up the call where the primary server left off, however what occurs is that the backup server starts executing the call flow from action element B. Therefore, action elements B and C are all executed twice, once on the primary server and once on the backup server.
This situation would cause problems only if the action or decision elements updated external systems such as databases since the actions would be run twice for a failover session. Actions or decisions that simply perform calculations or do actions such as setting Element or Session Data would not cause problems because these changes affect only the call itself.
RESOLUTION
This is caused by the way Resin handles session replication. Session replication is initiated only when responses are generated to requests. Since action and decision elements execute entirely on the Server side, generating no VoiceXML responses, any activity that these elements perform that affect the session (such as creating Element or Session Data) would not be replicated until the next response is sent (which is done only when the next voice element or VoiceXML insert element is run).
If action and decision elements perform activity involving external systems that would be affected by having them run twice in the case of a failover event, these activities should be managed using transactions (such as by using the Java Transaction API (JTA)).
|
| Visitor Comments |
|
No visitor comments posted. Post a comment
|
| Attachments |
|
No attachments were found.
|
Search the Knowledgebase
Jump to ID
Browse by Category
Print this page
Post a comment