You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Sufyan Arif <SA...@rdfgroup.com> on 2006/08/10 18:44:27 UTC
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.
Re: Using NMR to delay sending the message
Posted by Guillaume Nodet <gn...@gmail.com>.
ServiceMix does not have any feature wrt message redelivery.
The threading model for components is the same than for servlets.
The same instance of the component will be used to service all
messages but this happen concurrently: the component will
be used by several threads at the same time, hence it needs
to be thread safe. Note that this is only true for components
that implement the MessageExchangeListener interface, else
it is up to the component to poll exchanges and process them
in any way they want.
So, it should be safe to sleep a thread. However, this may lead
to dealocks if the thread pool is exhausted.
The easiest way is to use the sendSync method on the delivery channel
which can be used with a timeout. If the exchange has not been processed
within the given delay, the exchange status will be marked as ERROR.
A better way would be to use send and use a timer to redeliver the exchange
at
a later time, but this may lead to duplicate messages being delivered.
There' s no easy way to delay processing of a given exchange using the NMR,
but
this could be handled by a component if necessary.
On 8/10/06, Sufyan Arif <SA...@rdfgroup.com> wrote:
>
> 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.
>
>
>
--
Cheers,
Guillaume Nodet
RE: Using NMR to delay sending the message
Posted by Sufyan Arif <SA...@rdfgroup.com>.
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:SArif@rdfgroup.com]
Sent: 10 August 2006 17:44
To: servicemix-users@geronimo.apache.org
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.