Hey Juha,
> Hi,
>
> I think in the future it will be more straight-forward from
> the client's
> point of view if all the metrics from the server use the same topic
> channel, and leave it up to the client to set a proper
> message selector if
> they're only interested in receiving a specific set of
> messages from JMS.
I can agree if we have a way to clearly specify to a client which property
we set in the messages, so the client can create a proper message selector
for its needs.
At the beginning I thought adding a topic "monitor" under it "metrics",
"beancache", under "beancache" topics "resizer", "passivation", "overager",
"activation", etc. (anyway I'm not sure if JMS or spyderMQ support topics
nesting, so I messaged everything under beancache topic).
Using jndiView (or better the admin module) one can clearly subscribe to the
interested topics it sees.
What do you think ?
For a client is easier to subscribe to a specific topic, instead of
searching somewhere for the right selector, isn't it ?
> All we need to do is to agree to set a message property that
> identifies
> the source of the message, such as msg.setProperty("SOURCE", "Cache");
I have in mind a JBossJMSMonitoring interface with only public final static
in it, so that the client can know which properties we set in messages, what
do you think ? (lots of constants, anyway, and difficult to mantain...)
> This will allow a coarse grained filtering in the spyder based on the
> source component in the server. More fine grained filtering
> can also be
> added depending on what kind of properties you want to add to your
> messages (for example, receive a message only when the cache
> size reaches
> a certain limit).
Agree, but I thought that coarse grained filtering (ie metrics - cache)
would have better implemented as different topic, while fine grained
filtering with selectors.
Anyway it's easy to change everything.
Better yet, collect in the admin GUI all properties of all messages and give
clients a GUI way to select only specific properties, and so filter
messages; but from API point of view ?
I'm fairly new to JMS, so consider all the above as newby's comments :)
Simon
