Problem with handling a reply message

This topic has 3 replies, 4 voices, and was last updated 15 years, 1 month ago by Sundeep Kumar.

Creator

Topic
September 25, 2009 at 12:53 pm #51202
Michael Vork
Participant
Hello everybody,

Maybe anyone can help me with a problem I have with cloverleaf.

I am simulating a query connection by running a tcl after an outbound thread receives a QRY^A19 message from an inbound thread. The tcl performs an sql on some database.

After the SQL-read a message is created as follows:

set ackmh [msgcreate -recover -type reply “ADR^A19”]

msgmetaset $ackmh DESTCONN [msgmetaget $mh SOURCECONN] and fill it with

msgset $ackmh $replyMsg, wherein $replyMsg is the content of the new message.

Finally I KILL the original message and CONTINUE the new message

return “{KILL $mh} {CONTINUE $ackmh}

Everything works fine in the testtool. also the reply message is created correctly.

In my configuration I have 2 threads. The inbound thread only sends the message. The outbound thread performs the tcl. Furthermore, in the “route replies” tab of the outbound thread I have configured that ADR_A19 should be sent back to the inbound thread. Unfortunately, I do not receive anything back

What am I missing?

Thnx for your response.
Creator

Topic

Viewing 2 reply threads

Author

Replies
- September 26, 2009 at 2:38 am #69172
  Jim Kosloskey
  Participant
  Michael,
  
  Check your error DB. Do you have a message (or as many as the number of replies you created) with state 101 (I think that is the invalid TrxID State)?
  
  I wanted to do something similar except I did not want the reply going back to the source thread.
  
  It appears the Route Replies Tab does not function the way one would expect.
  
  If the reply passes through the outbound thread (not killed) it appears Cloverleaf gives it a TrxId ‘batch’ something.
  
  The only way I could see that was to turn on the Xlate EO on the Processs configuration in the NetConfig then look very carefully at the log.
  
  I think you need to do something on the inbound thread to handle that TrxId. I did not need to do that because I did not want the reply there so I just killed everything coming into the Inbound thread on the Outbound tab. I don’t recall off the top of my head my exact settings but I can look that up if you like.
  
  For me, I had to go through some hoops to get what I wanted.
  
  In my opinion, the ‘Route Replies’ on an outbound thread does not work as it should.
  
  In my opinion, Cloverleaf ought to just pass the message to the Route Replies handler and not assume it has to go back to the inbound thread.
  
  I recall noting in the log that it looked like everything was being set up as one would expect, then at the last minute the rug is pulled out of the route handling.
  
  I intend to discuss this with someone at the User Conference.
  
  What are your thoughts – do you think it works the way you think it should?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- October 22, 2009 at 2:36 pm #69173
  Bala Pisupati
  Participant
  I have a situation where i need to
  
  send a message to another outbound once i receive an ack. meaning
  
  thread1
  
  >
- October 27, 2009 at 3:16 pm #69174
  Sundeep Kumar
  Participant
  At the point of Receive Reply the original message is is state 14. If you CONTINUE at this point, in 5.5 there is not much that can happen to that message except possibly go to an undefined state, maybe. If you stop and start the thread this message may resume as a new read message on the thread and then follow the Route to state 5 where you want it. I would check and see what happens to the State 14 message when you CONTINUE. In any case, I would be wary of CONTINUE on state 14.
Author

Replies

Viewing 2 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.