JSLEE Discussions
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Load test on CGIN RA with CS1 protocol
Forum Index » Rhino SLEE Discussions
Author Message
maol


Joined: 02/06/2010 03:19:42
Messages: 34
Offline

In the Abandon-Before-CAN scenario, send the abandon after some delay, e.g.:

ERB-Abandon (DELAY 5000)
------------------->

I dont' understand why I should sent ERB-Abandon message with DELAY 5000? From function test's point view I want to test the case when ERB(Abanond) appers before response from DB, so I supose the ERB message should be sent ASAP, without any delay.

Set the Abandon-Before-CAN as the preferred scenario using the set-preferred-scenario command.

I have 4 simulated IN call types (Continue, Release, Reconnect, PlayAnnouncement) and each call type has about 5 scenarios (Abandon, NoAnswer, Busy etc). All 20 scenarios are initiated by IDP (call type is determined by the different field values in IDP). If I set one of them as prefered scenario then the load generator will generate sessions using that scenario. It means that all my test will be generated using this one prefered test scenario - I want to initiate dialogs using different scenarios, not by one specified scenario each time.
If I have loaded 20 scenarios, which scenario will be used if preferred scenario will failed?
matt


Joined: 22/12/2008 11:20:39
Messages: 93
Offline

I dont' understand why I should sent ERB-Abandon message with DELAY 5000? From function test's point view I want to test the case when ERB(Abanond) appers before response from DB, so I supose the ERB message should be sent ASAP, without any delay.


Sure, to specifically test that case, you'd be better off with no delay or a short delay. This was a suggestion for setting up the simulator to be able to respond either way, depending on the tardiness of the response from the other side.

I want to initiate dialogs using different scenarios, not by one specified scenario each time.


Yes, currently the 2 options for load generation are either round robin among the initiating scenarios, or initiating a single scenario.

In a future release we intent to add more flexibility to both the scenario weightings (how often each scenario is initiated), and scenario preference (which scenarios take precedence over others).

If I have loaded 20 scenarios, which scenario will be used if preferred scenario will failed?


Any one of the scenarios which has matched the message flow up to that point. There is no defined order for which is chosen first.

Clearly, the ability to set an order would address this limitation.
maol


Joined: 02/06/2010 03:19:42
Messages: 34
Offline

This is the destinated test case which I want to run and test by the CGIN simulator:

Due to race condition ('ERB(oAbandon)' or 'response from DB' first) I have designed second call flow "Alternative" where CAN and CUE message apears first in network (before sending ERB (oAbanond)) - in that case we don't send ERB (oAbandon) anymore, because it is not needed:

Now, I set first test scenario as prefered scenario and this is the result of test executions:
> run-session CS1-ContinueAction_Abandon
Send --> OpenRequest to endpoint2
Send --> InitialDPRequest to endpoint2
Send --> Delimiter to endpoint2
Recv <-- OpenAccept from endpoint2
Recv <-- RequestReportBCSMEventRequest from endpoint2
Recv <-- Delimiter from endpoint2
Send --> EventReportBCSMRequest to endpoint2
Send --> Close to endpoint2
Outcome of "CS1-ContinueAction_Abandon" session: Matched scenario definition "CS1-ContinueAction_Abandon"
> run-session CS1-ContinueAction_Abandon
Send --> OpenRequest to endpoint2
Send --> InitialDPRequest to endpoint2
Send --> Delimiter to endpoint2
Recv <-- OpenAccept from endpoint2
Recv <-- RequestReportBCSMEventRequest from endpoint2
Recv <-- Delimiter from endpoint2
Recv <-- CancelRequest from endpoint2
Recv <-- ContinueRequest from endpoint2
Recv <-- Close from endpoint2
Outcome of "CS1-ContinueAction_Abandon" session: Matched scenario definition "CS1-ContinueAction_Abandon_Alternative"
> run-session CS1-ContinueAction_Abandon
Send --> OpenRequest to endpoint2
Send --> InitialDPRequest to endpoint2
Send --> Delimiter to endpoint2
Recv <-- OpenAccept from endpoint2
Recv <-- RequestReportBCSMEventRequest from endpoint2
Recv <-- Delimiter from endpoint2
Send --> EventReportBCSMRequest to endpoint2
Recv <-- CancelRequest from endpoint2
Recv <-- ContinueRequest from endpoint2
Recv <-- Close from endpoint2
Send --> Close to endpoint2
Outcome of "CS1-ContinueAction_Abandon" session: Session was not matched. SEND_ERROR: Failed to send protocol message
Non-match at message: Close
Underlying error: com.opencloud.tools.scenario.simulator.protocol.ProtocolAdaptorException: Failed to send protocol message
> run-session CS1-ContinueAction_Abandon
Send --> OpenRequest to endpoint2
Send --> InitialDPRequest to endpoint2
Send --> Delimiter to endpoint2
Recv <-- OpenAccept from endpoint2
Recv <-- RequestReportBCSMEventRequest from endpoint2
Recv <-- Delimiter from endpoint2
Send --> EventReportBCSMRequest to endpoint2
Send --> Close to endpoint2
10:39:20,296 WARN : Received TC-END while dialog in invalid state: idle
10:39:20,296 WARN : Unable to send TC-U-ABORT(ABRT_source.dialogue_service_provider) on dialog [dialogID=8]
Outcome of "CS1-ContinueAction_Abandon" session: Matched scenario definition "CS1-ContinueAction_Abandon"

1) First execution: Finished as designeted first test case flow 'ERB (oAbanond) before 'response from DB'' - OK
2) Second execution: Finished as alternative test case flow ''response from DB' first, no ERB needed' - OK
3,4) two different errors - why?
matt


Joined: 22/12/2008 11:20:39
Messages: 93
Offline

Hi,

Your test runs nicely illustrate the four ways that this race condition (between the EventReportBCSMRequest and the CancelRequest) can pan out.

In scenario 1, the EventReportBCSMRequest and Close are sent soon enough such that the dialog state can be cleaned up on both sides of the dialog, so that we receive no further activity on the dialog.

Scenario 2 is the reverse, where the Cancel/Continue/Close are received soon enough to clean up our local dialog state, so that we close the dialog and finish the session cleanly.

In scenario 3, both sets of messages get generated soon enough such that they're both visible to the simulator. The incoming messages arrive soon enough to encounter an active dialog, but after our local timeout has occurred: i.e. we're building and sending southbound messages while the incoming messages are travelling northbound. In this particular case, the simulator has selected the 'CS1-ContinueAction_Abandon' scenario due to the timeout expiring. It successfully sends the EventReportBCSMRequest, then fails to send the next message (the Close), because the TCAP dialog has ended, following the incoming close.

Could the simulator handle scenario 3 better? Yes. In this case the simulator considered the down-calls (the successful EventReportBCSMRequest and failed Close) to be network side effects, which didn't match any scenario. In this case it would be more useful to consider that the outgoing EventReportBCSMRequest and Close *didn't happen*, since they didn't travel across the network. It could then continue matching the messages that definitely *did happen* (the incoming messages), and match the alternative scenario (CS1-ContinueAction_Abandon_Alternative).

Scenario 4 executes just like the scenario 1, except that the incoming messages (wrapped in a TC-END) are already on their way before our outgoing messages can clean up state on the other side. So we received those incoming messages when it's too late. The WARN messages are confined to the TCAP stack, which is just saying that it's received messages on a dialog which can't accept them, in accordance with the TCAP spec.

Could we handle scenario 4 better? The handling of the messages and the scenario matching behaviour looks correct, but the warning level messages are needlessly disconcerting. It could be more useful to record and expose these as stats, rather that printing warnings.

I'll raise these ideas internally, which will hopefully lead to cleaner behaviour when testing race conditions like these.
 
Forum Index » Rhino SLEE Discussions
Go to:   
Powered by JForum 2.1.8 © JForum Team