bug: cached JMS request
I spent a lot of time already tracing and trying to resolve this bug. issue: JMS message that is sent via soap request is somehow cached in temporary files and if you happen to change/try to parame...
Forum Discussion
- Are you doing data driven tests?
- What are the test steps involved in your test case?
- Which jms vendor are you using?
- Are you sending plain text over jms? Is it request reply true?
- I was not clear on - How do you come to know it is not sending fresh message? Have you tried stopping the consumer and tried to browse your queue and noticed duplicate message?
judging by the questions asked, as i was afraid, perhaps I wasn't clear on the issue.
1) yes but the issue will exist even if I change parameters manually.
2) JMS>DB quiery>> verify groovy script.
3) IBM websphereMQ
4) mom queue takes plain text
5) i have server logs. tailing logs as i send.
extended:
to make it more clear, this has nothing to do with groovy script, the issue is with the JMS soap request. If you make a "fresh" brand new soap request, you can use a new text string for a REQUEST, you can even use scripts to parse parameters (itterate over a array of parameters that is) and it works as intended. once.
after you use it once, within a few minutes, it becomes stuck. it will ONLY send the first text/sms that you have sent when you pressed send for the first time on that soap jms request. if you go and change the message in the request of the jms soap request, it will STILL send the original message (like literally delete and type a new string). I found this issue by tailing the logs on the server and i was expect message X but for some reason all was coming in was message Y, no matter what i put in the request and the original message was changed a while back as i was testing different scenarios. When i delete the request or make a new one and change the text/sms it will work for a period of time and stop. For the sake of Jenkins, I have to make it work without adding new request every time.
- Can you show how your sample endpoint looks like?
jms://WMQ_dev::queue_QMOM.XCOM.RQ.blah.ALL::queue_QMOM.blah.RS.XCOM.ALL
once again everything works no problem except for request getting cached and resend from temp cache. sometimes it will work correctly several times in a row till it "locks" up and you have to make a new soap step,
- Ok. Can you try with below endpoint and see if that is persistant?
jms://WMQ_dev::queue_QMOM.XCOM.RQ.blah.ALL::queue_
