What would be cool is if you could do last-image on a per-message-group basis within a common channel.
This "last-image" mechanism seems useful only when the the channel names correspond 1-to-1 with the entity whose state you need to know. It seems this implicity requires that a client know what channels exist up front. In the stock quote analogy, the client has to learn of an IPO through some other mechanism to know what channel to go to. I have a similar problem to the original poster's problem, but in my situation the content of my message identifies the id of an entity and another part of the content provides that entity's new state. The client doesn't know what entities exist up front. The channel itself may be communicating entity lifecycle events including new entity creations. Or suppose in the stock quote example, that IPOs happen by simply publishing a ticker/price message for a previously unknown ticker to a "stock-quotes" channel. I've never thought about it before, but how does activemq scale regarding proliferation of channels? How wide can you go before you say "too many". If the number of entities in question is small, you could dynamically route messages on the stock-quotes channel to price only messages on the stock-quote.ticker channel. But at some point having a crapload of channels has to cause problems. Suppose I'm the eBay and I'm publishing auction_item/action_status events. I doubt I could have a channel per auction item. James.Strachan wrote: > > See Last Image Caching which uses non-persistent topic subscriptions > but allows you to provide the 'last image' first before any further > updates... > http://activemq.apache.org/subscription-recovery-policy.html > -- View this message in context: http://www.nabble.com/EI-Pattern-question-tp16315358s22882p16466998.html Sent from the Camel - Users mailing list archive at Nabble.com.
