Service Virtualization

  • 1.  Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 03, 2017 10:59 AM

    Hello All,

     

    Any one can help, we are using IBM MQ native to send two responses for one service over reply queue. Both responses are going on same time but second response should go after 30 seconds. We are giving think time spec for second response but still it is not delaying. Any suggestions, I ahve used all old post as well but no luck.

     

    Any suggestion as it is very urgent. Please

     

    Thanks..

     

    Shivam Garg



  • 2.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Broadcom Employee
    Posted Jul 03, 2017 11:04 AM

    Is your VSE running as a service? As the system account rather than a user account? The reason I ask is that I've seen that specific configuration ignore think times.



  • 3.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 03, 2017 10:33 PM

    Morning Rick..

    My VSE is running over linux server, We have system account details with help of which we can login into box through SSH Tactia and can stop , start and restart VSE. So I think it is running as VSE what do you think what it can be as I am not sure weather it is running as VSE or not. But I explained I have control over the box where this VSE is running.

     

    Also for SOAP services, this think time spec is giving results but why not in IBM MQ, do we need to do some other thing here?

     

    PLease advise.

     

    Thanks..



  • 4.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 04, 2017 12:44 PM

    Which DevTest version are you running? In versions prior to DevTest 10.1 there was an issue with ignored think times when a VS was deployed or redeployed. Bouncing the VSE fixed this issue. With DevTest 10.1 this issue was fixed.



  • 5.  Re: Response is not getting delayed even after giving think time spec values as 5000
    Best Answer

    Posted Jul 04, 2017 12:58 PM

    Are you using the old 'IBM MQ Series' protocol?  If so, then you need to take an additional step to enable delayed responses.  Open the VSM, then the 'Respond' step, and check the 'Shared Sessions' checkbox on the left.  Note that this only works if your application does not use temporary response queues.



  • 6.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 05, 2017 02:28 AM

    Hello Keving,

     

    Yes I tried the same way as you suggested and it is working fine. Can you elaborate why we should check this check boxes? Also when we enabled check box then we are not able to see complete details in Console in Inspection view. Previously we were able to see both responses and detail related to all steps in console now only two detals coming , one is related to aynque queue and second names as Unknown.

     

    Do you have idea about this? or is it expected?

     

    Thank you so much.

     

    Shivam



  • 7.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 05, 2017 02:13 PM

    > Can you elaborate why we should check this check boxes? 

     

    The old 'IBM MQ Series' protocol was not originally written with delayed responses in mind, so the feature has limitations that require manual consideration.  Sending delayed responses requires 'Shared Sessions' to be enabled, but we can't just enable that by default.  Notably, the way 'Shared Sessions' works is not compatible with temporary response queues or a replyTo queue that otherwise changes from request to request. 

     

    The only way to fix these limitations was to rework it from scratch, which we did in DevTest 8.0 with the 'IBM MQ Native' protocol.

     

    > Also when we enabled check box then we are not able to see complete details in Console in Inspection view.

     

    Delaying the response isn't really compatible with the way the inspection view currently gathers its data.  If a response is delayed then it's sent at some point in the future, in the background while the VS execution moves on to other steps.  The events from actually sending that response are emitted during another step's execution, or possibly during no step's execution.  This is a problem for the inspection view, which is based around grouping events under their respective steps.

     

    Again, the new 'IBM MQ Native' protocol is able to handle it a little better.  But it can't remove the fundamental problem that we don't know some things about the response message until actually going through a send operation that can happen at some arbitrary point in the future.



  • 8.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 08, 2017 09:06 AM

    Evening Kevin..

     

    Thanks again for your help. But I would like to bring in notice that this thing did not work during last night load testing. Not able to understand where is the issue? When we are checking in Console in Inspection View we are seeing delay in responses but when project is checking at front end , they are seeing that both responses coming at same time.

     

    Also previously they were using code 16.3 version during which they were able to see delay in responses at front end but since they moved their code to 17.1 version, they are able to see both responses on same time , no delay.

     

    Is it Lisa issue or their side code issue? We are getting confused and not able to made decision ? Project side blaming Lisa which is not correct , I am sure.

     

    What is your thought and opinion around this, please?

     

    Cheers..

     

    Shivam Garg



  • 9.  Re: Response is not getting delayed even after giving think time spec values as 5000

    Posted Jul 08, 2017 09:52 AM

    Sorry Kevin, Please ignore my previous note. This concept was working fine and testing got successful. There was some confusion so that is cleared now.

     

    Thanks you so much for your help.

     

    Cheers..

    Shivam Garg