Hello All,
Can some one help me in understanding around this issue?
Issue: We have stubbed one MQ service but during testing , testing team found that they are getting responses or traffic from Lisa even after MQ service is down in Lisa server.
I am not able to understand is it Lisa issue or some thing else. Quick reply is much appreciated.
Thanks..
Shivam Garg
Hi Shivam,
If you have multiple VSE's running check if the MQ service is running in any other VSE and stop it.
Thanks,
Sai
Hello Sai,
Thanks for quick reply. We have checked and this service is running only in one VSE and no other instances are there on any other VSE.
Any thing else we can check to sort this issue as this is impacting testing, please.
Thanks..
Shivam
Answers to some of the following might help the team respond:
Which version of DevTest?
Which version of MQ?
Can you describe a little about what the virtual service does.
For example, is the request reply sequence 1 to 1 or 1 to many?
For a request, are you writing to multiple response queues?
Are you using queues, reply to queues, etc.?
Are these long running services where the replies have long wait / think times? (i.e., response think is 5 minutes)
What is the scope of your connection and queue assets (Model, Global, Step, etc.)?
Are you stopping the MQ service or just stopping the VSE?
If logging is in INFO mode, open / tail the VSE.log file.
If you shut the VSE down, look for the time slice of the message showing your VSE shutting down:
2017-03-13 13:58:24,978Z (09:58) [LISA Environment Shutdown Hook : com.itko.lisa.coordinator.VirtualServiceEnvironmentImpl$1@4d2a1da3] INFO com.itko.lisa.net.ServerRequestHandler - Scheduling removal of tcp://<yourVSEServer>:2013/VSE
2017-03-13 13:58:24,978Z (09:58) [LISA Environment Shutdown Hook : com.itko.lisa.coordinator.VirtualServiceEnvironmentImpl$1@4d2a1da3] INFO com.itko.lisa.net.ServerRequestHandler - removed tcp://<yourVSEServer>:2013/VSE
2017-03-13 13:58:24,978Z (09:58) [Thread-7] INFO com.itko.lisa.net.ActiveMQFactory - Closing AMQ connections
Maybe more interesting... Do you have any log output after the above VSE messages? You should not in the majority of situations.
If you only shut your service down, look for these types of displays in the vse.log:
2017-03-14 12:41:21,257Z (08:41) [ServiceName [VS_YourService_Run]/1] INFO com.itko.lisa.simulator.SimulatorImpl - Instance (vuser) is finishing up....
2017-03-14 12:41:21,257Z (08:41) [ServiceName [VS_YourService_Run]/1] INFO com.itko.lisa.simulator.SimulatorImpl - Instance (vuser) all done.... running instances: 0 stopping instances: 0
2017-03-14 12:41:21,262Z (08:41) [ServerRequestResponder 2] INFO com.itko.lisa.simulator.SimulatorImpl - Done modifying instances, running: 0 stopping:0
:
2017-03-14 12:41:21,264Z (08:41) [ServerRequestResponder 2] INFO com.itko.lisa.simulator.SimulatorImpl - Done modifying instances, running: 0 stopping:0
:
2017-03-14 12:41:21,267Z (08:41) [ServerRequestResponder 2] INFO com.itko.lisa.net.ServerRequestHandler - Scheduling removal of tcp://<yourServer>:2013/VS_YourService
2017-03-14 12:41:21,267Z (08:41) [ServerRequestResponder 2] INFO com.itko.lisa.net.ServerRequestHandler - removed tcp://<yourServer>:2013/VS_YourService
Then, look at your vse_matches.log. Do you see any output going to the MQs after the VSE shutdown time slice?
-- I do not have an example of an MQ message going on the wire.
Hello Joel,
thanks for you reply. Please get my details below:
Which version of DevTest? – LISA 7.5.2
Which version of MQ? – IBM MQ series in Lisa 7.5.2
Can you describe a little about what the virtual service does. – The Actual flow is SOA- Data broker- Request queue- (Vision +)- Response Queue- Data Broker-SOA
For virtual Service : SOA- Data broker- Request queue- (Ca Lisa)- Response Queue- Data Broker-SOA.
At very first time Lisa will receive request from SOA and then it will give 1st response to SOA through DP(Data Power).
DP will give request with additional tag, Lisa will give corresponding 2nd response. We have enabled Allow duplicate transaction specifications for that.
For example, is the request reply sequence 1 to 1 or 1 to many? 1 to 1.
For a request, are you writing to multiple response queues? – No, we have configured only one response queue
Are you using queues, reply to queues, etc.? yes we have used response queue as reply to queue.
For your reference , Configured MQ details :
host_Name | qas1.service.test.group | false |
channel_Name | INF.CA.LISA.TEST | false |
request_Queue | INF.FDI.01L | false |
response_Queue | O_EARMARK_CARD_PAYMENT_DTLS_GET_INTER.IN | false |
queue_Manager | QAS1 | false |
Are these long running services where the replies have long wait / think times? (i.e., response think is 5 minutes) Configured Think time : 0
What is the scope of your connection and queue assets (Model, Global, Step, etc.)? For virtual Service : SOA- Data broker- Request queue- (Ca Lisa)- Response Queue- Data Broker-SOA.
If logging is in INFO mode, open / tail the VSE.log file. We couldn’t take VSE log file in server console as we are not maintaining the server.
Look for the time slice of the message showing your VSE shutting down:
2017-03-13 13:58:24,978Z (09:58) [LISA Environment Shutdown Hook : com.itko.lisa.coordinator.VirtualServiceEnvironmentImpl$1@4d2a1da3] INFO com.itko.lisa.net.ServerRequestHandler - Scheduling removal of tcp://<yourVSEServer>:2013/VSE 2017-03-13 13:58:24,978Z (09:58) [LISA Environment Shutdown Hook : com.itko.lisa.coordinator.VirtualServiceEnvironmentImpl$1@4d2a1da3] INFO com.itko.lisa.net.ServerRequestHandler - removed tcp://<yourVSEServer>:2013/VSE 2017-03-13 13:58:24,978Z (09:58) [Thread-7] INFO com.itko.lisa.net.ActiveMQFactory - Closing AMQ connections
Maybe more interesting... Do you have any log output after the above VSE messages? You should not in the majority of situations.
Then, look at your vse_matches.log. Do you see any output going to the MQs after the VSE shutdown time slice? ? We are not receiving any hits when the service is down. So we unable to see logs.
Hope this info will help you. Please help in sort out this or give some knowledge.
Thanks..
I know of no reason why this would happen. Since your Think Time is 0, responses should go immediately. That should rule out a response message staying on an internal DevTest response queue after the service is stopped.
This is likely a support ticket question at this point; however, the DevTest version your team is running is out of support now.
Try diagnosing this way:
1) Stop the service
2) Ask an MQ Admin if they see a DevTest connection on the queue manager (how many connections do they see)
3) Start the service
4) Ask an MQ Admin if they see a DevTest connection on the Queue Manager (how many connections do they see)
5) Stop the service
6) Ask the MQ Admin if they see a DevTest connection on the Queue Manager (may take a few seconds) (how many connections do they see)
Ideally, the connections should go from 0 and back down to 0. If other connections are open, I would try to find what they might be. If no connections, I don't see how DevTest could be sending data after the service is stopped since no connection exists.
If you can get a server Admin to provide you with a copy of the log files it might be helpful.
The concept of assets was introduced circa DevTest 7.5. When I asked the question of Scope, I was referring to the Connection Assets that sit underneath Project Config. I presume you are not using these in your instance. If you are using these assets to manage the connection and queues, you will see information that looks something like this. If you are using the assets, review and set the Scope to "Model", redeploy, and try the test shutdown again to see if you get a different result.
Thanks again Joel.
We will check and try that what you have suggested.
And I am totally agree with you that this version is out of scope, but as in our organization we are using this version and we are going to upgrade it to 9.5.2 in next couple of months, so we have extended support agreement around this old version(as I am aware).
But that for your info. We will try that.
Thanks..
Shivam Garg
I know of no reason why this would happen. Since your Think Time is 0, responses should go immediately. That should rule out a response message staying on an internal DevTest response queue after the service is stopped.
This is likely a support ticket question at this point; however, the DevTest version your team is running is out of support now.
Try diagnosing this way:
1) Stop the service
2) Ask an MQ Admin if they see a DevTest connection on the queue manager (how many connections do they see)
3) Start the service
4) Ask an MQ Admin if they see a DevTest connection on the Queue Manager (how many connections do they see)
5) Stop the service
6) Ask the MQ Admin if they see a DevTest connection on the Queue Manager (may take a few seconds) (how many connections do they see)
Ideally, the connections should go from 0 and back down to 0. If other connections are open, I would try to find what they might be. If no connections, I don't see how DevTest could be sending data after the service is stopped since no connection exists.
If you can get a server Admin to provide you with a copy of the log files it might be helpful.
The concept of assets was introduced circa DevTest 7.5. When I asked the question of Scope, I was referring to the Connection Assets that sit underneath Project Config. I presume you are not using these in your instance. If you are using these assets to manage the connection and queues, you will see information that looks something like this. If you are using the assets, review and set the Scope to "Model", redeploy, and try the test shutdown again to see if you get a different result.