On 7/19/06, Kuppe <[EMAIL PROTECTED]> wrote:
Wow, very powerful feature!! First question, how do you suggest that advisory messages can help with the following? > I currently have many clients registering for client specific market data > updates from a market data server. The market data server keeps a list of > currently registered clients vs. symbols and sends the relevant updates to > a > topic registered by the client (there may be more than one client > interested > in the same market data - eg. two users in the same company).
So advisory messages broadcast changes to consumers (e.g. create/close consumers) on any topics or queues. Also you can query the current state of the system (e.g. current consumers) via JMX - so you kinda have a way in default ActiveMQ of knowing what clients are looking at what symbols (assuming 1 topic per symbol etc)
Do you suggest including the encoded market data registration in the name of the topic or is it possible to include some business related information in the advisory messages? It would be really cool if i could restart my business service and recover business level registration information from some state maintained in the bus!
Am not sure how the business related information hooks into the consumer information; it might be worth creating your own facade on top of ActiveMQ's JMX or advisory messages (or both) to join the advisory message/MBean state with any business related information. e.g. joining the clientID/username to the details of their business stuff etc
I suppose in the simplest form, i could create a consumer of the ActiveMQ.Advisory.NoConsumer.Topic.xxxxx for the market data update topic, and simply deregister the subscription at a business level when receiving messages in this consumer.
That sounds perfect. A common requirement in market data type stuff is to do 'interactive feeds' (terminology changes from place to place) - where basically you monitor the JMS consumers - when folks subscribe to a new topic that the feed is not publishing, you subscribe to the feed so that it will be published on the JMS bus. Similarly when no consumers are using a particular topic, you can trim your subscriptions on the feed. (As a bit of background, the reason for this is often a combination of network bandwidth (don't send prices around for stuff that noone is interested in) and cost (sometimes feed suppliers charge per symbol or for certain kinds of prices on certain exchanges etc - so keeping the feed subscription list down saves $$$). The one thing to be a little careful of is that advisory messages are kinda events, typically tranisent notifications of things changing. On startup you often need to look at the current snapshot (so JMX). So on startup of your InteractiveFeedThingy you'd look at the current consumers available in JMX, then process any advisory messages going forward - so both JMX and advisory messages are probably required. It might make sense to add a helper library for modelling the connections, producers, consumers and destinations available on a running system - kinda like a real time POJO model of these things hiding the details of the JMX code and the advisory messages, so your tool can just use that . I'm sure some UI tooling could use these kinds of real time POJOs for visualising the network etc -- James ------- http://radio.weblogs.com/0112098/
