Service Virtualization

  • 1.  Restarting a VSE: what happens to my requests?

    Posted Aug 08, 2017 10:25 AM

    I have a question what happens to requests  when a VSE is restarted. What happens to the active sessions,

    so to the requests that were being handled by virtual services? I am specifically interested in HTTP virtual services.

    And what happens to the requests that were queued? I understand that there is some kind of queueing under the hood to make sure that requests that could not be handles yet are processed later.

     

    So when the VSE comes up again does it continue processing the requests it was handling when the server was restarted (so pick up all sessions that were running earlier)?

    Does it process the requests that were queued by the under the hood queueing mechanism?

     

    I understand that all requests arriving during the restart of the VSE can be considered lost. 

     

    Thank you, Izaak



  • 2.  Re: Restarting a VSE: what happens to my requests?

    Posted Aug 10, 2017 04:38 PM

    As per my understanding, as soon as you will restart, all the requests being processed will be lost and won't be processing any request while restarting. 



  • 3.  Re: Restarting a VSE: what happens to my requests?

    Posted Aug 11, 2017 04:54 AM

    Do you know what happens to the requests that were queued? From CA I once heart that a VSE will queue requests when the load exceeds 10 transactions per second.  So when I restart will all these requests be lost also?

     

    Van: monika_mehta

    Verzonden: donderdag 10 augustus 2017 22:39

    Aan: Izaak de Hullu <Izaak.de.Hullu@systemation.nl>

    Onderwerp: Re:  - Re: Restarting a VSE: what happens to my requests?

     

    CA Communities <https://communities.ca.com/?et=watches.email.thread>

     

     

    Re: Restarting a VSE: what happens to my requests?

     

    reply from Monika Mehta<https://communities.ca.com/people/monika_mehta?et=watches.email.thread> in DevTest Community - View the full discussion<https://communities.ca.com/message/241998913-re-restarting-a-vse-what-happens-to-my-requests?commentID=241998913&et=watches.email.thread#comment-241998913>



  • 4.  Re: Restarting a VSE: what happens to my requests?

    Posted Aug 11, 2017 12:10 PM

    I guess so because when you will restart the server, it will gonna wipe off all the requests. 



  • 5.  Re: Restarting a VSE: what happens to my requests?

    Posted Aug 14, 2017 09:16 AM

    Like Monika says, if you stop a virtual service, you lose everything.

    Regardless of what DevTest does under the hood to support performance and Think Time features, the virtual service is thread-based. When you stop a service, a close connection signal is sent to running threads. Therefore, when you stop / re-start the service, there is no prior consumer thread on which to send a response.   

    To go a step further....

    Assume that you have two services listening on the same port but having two different base paths.

    /r1/example/{custId}

    /r1/example/{custId}/{personId}

    Assume that a request is sent that technically satisfies both base paths.

    /r1/example/12345/abcd/getSomeData

    The incoming request is actually sent to both services.

    The first service that processes and sends the response is the winner. The second service's response is not sent. 

    This is a common mistake when teams run multiple services on the same endpoint port. It becomes confusing because sometimes you might get the response you were looking for and other times not.



  • 6.  Re: Restarting a VSE: what happens to my requests?

    Posted Aug 14, 2017 09:25 AM

    Ok, that is clear and sounds reasonable when the threads are gone everything is gone. No I was more referring to the use of some kind of messaging system (RabbitMQ or ActiveMQ) for queueing the requests so they might be available after a restart.



  • 7.  Re: Restarting a VSE: what happens to my requests?
    Best Answer

    Posted Aug 14, 2017 11:08 AM

    I see the issues and challenges you are facing. But, what thread would the service respond on when the service restarts? DevTest's design follows the HTTP spec and HTTP 1.1 is not an asynchronous protocol. Once the thread between the consumer and the service closes, there is no thread on which to send a reply. It seems to me that changing the threading model on the server-side to hold threads open would be a spec violation and create potential resource issues on the server.

    The HTTP 2 spec has a concept of unsolicited server responses, but DevTest does not yet support HTTP 2. This spec might provide support of a concept to enable responses after the fact.