1 thought I had looking through the patterns is using an aggregator. Even though there is only 1 message going out. Then, I could passivate the AggregatorCollection. Then add a correclationId to the outgoing message. Now I would expect the new message that was created by the Python service to hav ethat correlationId.
Note, the return message is not a respose. it is just a message that states the change request was processed. I need this seperation because there is a specific CR that can take 24 hours to complete. So then, when a new message is returned that has my correclationId, within the alloted timeframe, we are complete, otherwise the aggreggator can have a TTL then send a new message to the DLC. Does this sound correct? On Mon, Sep 15, 2008 at 10:36 PM, James Strachan <[EMAIL PROTECTED]>wrote: > 2008/9/15 Mick Knutson <[EMAIL PROTECTED]>: > > I would like to get some design help on a situation I need to address. > > > > I have a Manager that sends a ChangeRequest message to a Python server. > This > > CR could take an hour to perform. But I want to implement a timeout on > the > > CR. So after I send out this CR message, how do I create an alert message > in > > 1.1 hours to another processor? > > You could try setting a 1 hour time to live on the message; then if > the message is not processed within an hour the message will be sent > to a DLQ which you could subscribe to and notify another processor. > > Though with this approach if a server consumes the message but just > takes 2 hours to process it, you'd not get a notification of it taking > too long. > > So maybe you should do the following for each message that is going to > be processed... > > * create a timer (say with Quartz) with details of the current message > * consume the message by a processor and send a completion message to > the JMSReplyTo destination when it has been completed (preferably in a > JMS transaction so its atomic) > * consume the completion message and delete the timer for that message > correlationID > * on the timer firing, send a message to the other processor that the > message was not processed in time > > This does seem an interesting pattern we could maybe implement in Camel... > http://activemq.apache.org/camel/enterprise-integration-patterns.html > > There's no obvious pattern yet in the EIP book - but there may be in > Gregors next book which is gonna be more conversational. Essentially > we could do with a kinda 'timed message acknowledgement' pattern; > where if a success message is not received before the timer fires, we > send a fail message somewhere. > > Another approach BTW is to use BPEL to wrap up this process. > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com
