Forum Discussion

vodka1983's avatar
vodka1983
Occasional Contributor
9 years ago

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 parametize/itterate a different value, keeps sending the original request.

 

impact:

you have to make one JMS request at a time. cant setup cycle through a parameter. IF you want to make a new JMS request, you have to make a new soap request. Its unpractical. 

 

root cause :

Test consists of a JMS soap request with a String to a MOM que. 

the que works, sends a message. However, after you send it, if you try sending a DIFFERENT message, it will still send the original CACHED message. It took a while to figure out what was the source of the problem while testing MOM and finally figured it out it was coming from SOAPUI.

 

I read server logs and client side soapui logs and I think i see a problem. When running soap testcase it cannot delete temporary files after finishing up. Hense the "cached" request. 

 

My structure of the test is to itterate through groovy about 40-50 vars from a CSV file. It works as long as I create an identical request, brand new soap request, using mom endpoints. The JMS has parameters that are fed through a setup script. Bear in mind for Jenkins its unreasonable to have to create a new request every time you run a test. I have researched a solution and I can probably code up a setup/teardown that in groovy creates a test step and deletes after the run but I really dont want to resort to that.

 

I have tried 5.2.1 2.0 and 1.3 versions. Also tried redoing my Hermes JMS config as well, clearing cache manually (though /apps/local storage/ temp ....)

 

I have not seen a single post about this problem.

  • nmrao's avatar
    nmrao
    Champion Level 3
    9 years ago
    • 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?
    • vodka1983's avatar
      vodka1983
      Occasional Contributor
      9 years ago

      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.

       

       

       

      • nmrao's avatar
        nmrao
        Champion Level 3
        9 years ago
        Can you show how your sample endpoint looks like?