ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » help !!! control & timeout with aggregate node

Post new topic  Reply to topic
 help !!! control & timeout with aggregate node « View previous topic :: View next topic » 
Author Message
genestep
PostPosted: Tue May 28, 2002 10:03 am    Post subject: help !!! control & timeout with aggregate node Reply with quote

Apprentice

Joined: 16 Apr 2002
Posts: 43
Location: France

Hi,

Do you know about problem of synchronisation between control message & reply messages in aggregate node.
Explanation :
I have message 1 which send a request to a distant server
I have message 2 just to trigg the time out (so i use a simple new messageflow with just a message copy in a compute node with addings for timeout message description.
Result :
message 1 go to unknown immediatly & message 2 go to timeout after timeout delay.

Is it possible that message 1 arrives before control message and so the reply is never complete.
Did you know about an ESQL function to implement a temporisation in timeout message flow

thanks for your help

Philippe
Back to top
View user's profile Send private message
zpat
PostPosted: Tue May 28, 2002 11:45 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Make sure to preserve the Local Environment on the control message if you process it with a Compute node.

Set the UNKNOWN MESSAGE TIMEOUT on the AggregateReply properties to a value long enough to receive the control message. Until you get the control message, any other replies are considered unknown.
Back to top
View user's profile Send private message
devans
PostPosted: Wed May 29, 2002 12:17 am    Post subject: Reply with quote

Apprentice

Joined: 18 Mar 2002
Posts: 43

The control message is there so that the AggregateControl node (who knows when the timeout should be happening) can inform the AggregateReply node of this information (who will subsequently process the timeout). If the control message doesn't arrive, then messages are still recognised as valid replies, but your timeouts won't happen (because the AggregateReply node doesn't know when they're meant to happen because the AggregateControl node hasn't told him).

I don't understand what you mean by message 1 & 2. Are these two messages which branch off from an AggregateControl node, or two messages which are on a queue and get passed to the AggregateControl node?

If your message 1 is going to the unknown terminal, then you have probably either
* Not copied the MsgId of the request into the CorrelId of the reply, or
* Put the request message to a queue outside of MQ syncpoint (check that the Transaction value on your MQOutput node is not NO)

Your message 2 is probably going to the timeout because message 1 was not recognised as the valid reply that it was.
Back to top
View user's profile Send private message
genestep
PostPosted: Wed May 29, 2002 5:40 am    Post subject: Reply with quote

Apprentice

Joined: 16 Apr 2002
Posts: 43
Location: France

Sorry, I made a mistake with my trace files. With the unknown delay parameter, i succeed to "synchronize" timeout & control.

Just a last question.


Is it Normal in out terminal of Aggregate Reply and after the first message flow, i always send empty message like belove.

response is the name of the folder for request message 1 :
When i receive a real answer, BLOB is replaced by my XML message


************************************************************************************
(
(0x1000000)Properties = (
(0x3000000)MessageSet = NULL
(0x3000000)MessageType = NULL
(0x3000000)MessageFormat = NULL
(0x3000000)Encoding = NULL
(0x3000000)CodedCharSetId = NULL
(0x3000000)Transactional = UNKNOWN
(0x3000000)Persistence = UNKNOWN
(0x3000000)CreationTime = NULL
(0x3000000)ExpirationTime = NULL
(0x3000000)Priority = NULL
(0x3000000)ReplyIdentifier = NULL
(0x3000000)ReplyProtocol = NULL
(0x3000000)Topic = NULL
)
(0x1000000)ComIbmAggregateReplyBody = (
(0x1000000)response = (
(0x1000000)Properties = (
(0x3000000)MessageSet = ''
(0x3000000)MessageType = ''
(0x3000000)MessageFormat = ''
(0x3000000)Encoding = 273
(0x3000000)CodedCharSetId = 819
(0x3000000)Transactional = FALSE
(0x3000000)Persistence = FALSE
(0x3000000)CreationTime = GMTTIMESTAMP '2002-05-28 15:30:11.680'
(0x3000000)ExpirationTime = -1
(0x3000000)Priority = 0
(0x3000000)ReplyIdentifier = X'414d5120514c414457303120202020200714f33c22100600'
(0x3000000)ReplyProtocol = NULL
(0x3000000)Topic = NULL
)
(0x1000000)MQMD = (
(0x3000000)SourceQueue = ''
(0x3000000)Transactional = FALSE
(0x3000000)Encoding = 273
(0x3000000)CodedCharSetId = 819
(0x3000000)Format = 'MQSTR '
(0x3000000)Version = 2
(0x3000000)Report = 0
(0x3000000)MsgType = 2
(0x3000000)Expiry = -1
(0x3000000)Feedback = 0
(0x3000000)Priority = 0
(0x3000000)Persistence = 0
(0x3000000)MsgId = X'414d5120514c414457303120202020200714f33c22000600'
(0x3000000)CorrelId = X'414d5120514c414457303120202020200714f33c22100600'
(0x3000000)BackoutCount = 0
(0x3000000)ReplyToQ = ' '
(0x3000000)ReplyToQMgr = 'QLADW01 '
(0x3000000)UserIdentifier = 'MUSR_MQADMIN'
(0x3000000)AccountingToken = X'160105150000002c22d9716c4af82abf7df76d1c04000000000000000000000b'
(0x3000000)ApplIdentityData = ' '
(0x3000000)PutApplType = 28
(0x3000000)PutApplName = 'MQSeries Client for Java '
(0x3000000)PutDate = DATE '2002-05-28'
(0x3000000)PutTime = GMTTIME '15:30:11.680'
(0x3000000)ApplOriginData = ' '
(0x3000000)GroupId = X'000000000000000000000000000000000000000000000000'
(0x3000000)MsgSeqNumber = 1
(0x3000000)Offset = 0
(0x3000000)MsgFlags = 0
(0x3000000)OriginalLength = -1
)
(0x1000000)BLOB = (
(0x3000000)UnknownParserName = 'MQSTR'
(0x3000000)BLOB = X'3c3f786d6c207665727.....26f6f743e'
)
)
)
)

Thx in advance

Philippe
Back to top
View user's profile Send private message
devans
PostPosted: Wed May 29, 2002 7:13 am    Post subject: Reply with quote

Apprentice

Joined: 18 Mar 2002
Posts: 43

I'm not sure I understand the question.

If you are wondering why you are getting BLOB instead of XML, then it is because you haven't associated the message with the correct message domain. In the MQInput node which receives the reply, set the domain to "XML".
Back to top
View user's profile Send private message
genestep
PostPosted: Wed May 29, 2002 12:26 pm    Post subject: Reply with quote

Apprentice

Joined: 16 Apr 2002
Posts: 43
Location: France

Sorry if i'm not clear !!!

My problem is i always have reponse in aggregate reply (in timeout, or out terminal) without any message in entry. IF i stop and restart my broker the trace files behind the aggregate reply node continue to grow with empty answer (like precedent example), and i don't receive any message in entry.

Is is possible that i have inconsistance in database record and so wrong functionement. If it is, how to clear properly the database (clear baggregate table in broker database ...)

Thx

Philippe
Back to top
View user's profile Send private message
devans
PostPosted: Thu May 30, 2002 2:08 am    Post subject: Reply with quote

Apprentice

Joined: 18 Mar 2002
Posts: 43

I think I understand what you're asking. You have a fan-out with two branches - one called "response" and one called "entry". In your aggregated reply message (which comes from the 'out' or 'timeout' terminal) you have the "response" message. but you never see the "entry". You have a trace node before the AggregateReply node which shows your "entry" reply arriving, but it disappears after that.

If this is the case, then it is possible that the "entry" reply is considered to be an "unknown" message by the AggregateReply node and is sent out of the 'unknown' terminal. If you don't have that connected to anything, then the message will seem to disappear. The most likely reason for it being "unknown" is that you haven't copied the MsgId into the CorrelId before sending the reply.

While developing aggregation flows, it is possible to leave database records orphaned in the BAGGREGATE table. These will be cleared up when you delete the broker. In a production system when you know your message flows are correct, you will not have any orphaned records in the table.
Back to top
View user's profile Send private message
genestep
PostPosted: Thu May 30, 2002 10:35 am    Post subject: Reply with quote

Apprentice

Joined: 16 Apr 2002
Posts: 43
Location: France

It works !!!!!!!!!!
thanks for your help
All my problems comes from orphelin timeout line in baggregate table in broker database. I think during development, i made mistakes and so the aggregate system didn't finish correctly

Thx

Philippe
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » help !!! control & timeout with aggregate node
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.