-
1. Re: Monitoring new connections to a topic
adrian.brock Jul 9, 2007 4:54 AM (in response to chris05atm)The interceptor is the way to go.
The call you want to intercept is subscribe(). -
2. Re: Monitoring new connections to a topic
chris05atm Jul 9, 2007 5:44 PM (in response to chris05atm)The subscribe interceptor method was actually my first attempt. I am afraid my first message was not detailed enough in its description.
Using subscribe() my Interceptor will broadcast a message to the topic whenever a client connects. The problem is I guess the message is broadcast before the connecting client starts receiving messages. Every other connected client receives the broadcasted message except the client that caused the subscribe() method to fire.
With a durable connection the connecting client receives the message but on a non-durable connection... the timing seems slightly off and therefore the message is missed by the connecting client.
I am thinking about just adding a timer delay or something but that seems rather hackish. Is there a better means for broadcasting a message and ensuring that connecting client receives the message? Some later method to hook into perhaps?
You've been lots of help! -
3. Re: Monitoring new connections to a topic
adrian.brock Jul 10, 2007 9:20 AM (in response to chris05atm)"chris05atm" wrote:
Using subscribe() my Interceptor will broadcast a message to the topic whenever a client connects. The problem is I guess the message is broadcast before the connecting client starts receiving messages. Every other connected client receives the broadcasted message except the client that caused the subscribe() method to fire.
Ok, then why don't you intercept receive()? i.e. on the clients first request
to receive a message.
subscribe() just means they created the subscription (receiver/subscriber), not they
did receive() in the jms api.
But even then you don't know if it will actually be receiving.
You'd need to know whether the client has also done setEnabled(true)
i.e. whether it invoked connection.start()
You'd also have to trap unsubscribe() and connectionClosing()
to tidyup whatever state you use to remember that you already did
the broadcast on the first receive().
On the generic timing issue, you just do the broadcast AFTER the invocation
to the server.
public void subscribe(...) throws JMSException
{
super.subscribe(...);
// Here we know the subscription was successful
} -
4. Re: Monitoring new connections to a topic
chris05atm Jul 13, 2007 2:47 PM (in response to chris05atm)Just wanted to say thanks for the help. I ended up getting this to work with your comments.
Just a heads up to others: I had a message selector set that was blocking my responses. Once the selector was disabled everything flowed just fine. Still not sure why the message selector fails to allow my response through (it is a byte for byte copy of another JMS message) while the same selector works for a different server using the same JMS messages. Another mystery I'll have to track down.
Thanks again!