Channels only have a RAM overhead so its no biggie having loads. The last image could be anything though - it could be a number of entity messages.
If you are trying to make a kinda distributed entity cache then you probably dont wanna stream the entire DB to a new subscriber :-) so having a single topic for updates to an entity; then loading individual entities on demand is maybe a more suitable approach On 03/04/2008, bwtaylor <[EMAIL PROTECTED]> wrote: > > 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. > > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
