Really need some help on this one, anyone? I've seen another post where someone is asking a similar question http://www.nabble.com/Trying-to-understand-servicemix-message-routing-an d-fault-tolerance-tf1439178.html#a3885123question
but no answer to that either :-( -----Original Message----- From: Sufyan Arif [mailto:[EMAIL PROTECTED] Sent: 10 August 2006 17:44 To: [email protected] Subject: Using NMR to delay sending the message Hi, Let me begin by explaining my scenario. I have a message flow within servicemix where 1) An EIP router receives a MortgageApplication message and passes it to my MortgageApplicationRouter component. 2) The MortgageApplicationRouter gets the message and separates it into the payload and some metadata. A new normalized message with the payload and metadata attached is created. MortgageApplicationRouter sends the MortgageApplication message with metadata to the exchange. 3) The new message is picked up by my MortgageApplicationDelivery component and based on the metadata will try to deliver the MortgageApplication. My questions center around the role of MortgageApplicationDelivery component. Part of the metadata defines how many attempts should be made to deliver the MortgageApplication and what the wait period between retries should be. Q1) Would it be a performance problem if I keep putting the message back into the NMR and let it loop around the MortgageApplicationDelivery component until the timeout to resend the message expires? Q2) Is there another way of gracefully delaying the delivery of the message. Is it safe to sleep within the MortgageApplicationDelivery component or would that cause threading/blocking issues within servicemix? Q3) Does SM create a pool of service components or is there only ever one instance of a service component as defined in servicemix.xml. What I mean by this is that if I did make the thread sleep within MortgageApplicationDelivery then would all subsequent messages have to wait until the sleep expires? Many thanks Sufyan This transmission is confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender immediately. Any opinions or advice contained in this e-mail are those of the individual sender except where they are stated to be the views of RDF Group plc. All messages passing through this gateway are virus scanned.
