[rabbitmq-discuss] RabbitMQ+STOMP: how to trigger events upon connect/subscribe to stomp destinations?

[Willi Richert]

Am Donnerstag, 17. Juni 2010 13:47:32 schrieb Marek Majkowski:
> Just out of interest, can I ask is there any particular reason why
> RabbitMQ+STOMP
> might be better for you than MorbidQ?

MorbidQ works well for very small installations. Its web page says that for 
production you would rather want to rely on e.g. rabbitmq.  
http://www.morbidq.com 

It indeed seems that I will switch back to MorbidQ if this point is not easily 
solvable (and returning back if I have more in-depth knowledge of rabbitmq and 
its plugin system).

> 
> > When a user surfs on some web page, it connects to Orbited via stomp and
> > subscribes to a secret destination where it listens for updates. At the
> > point when the browser subscribes, my RestQ listener signaled all the
> > other browsers visiting the same page that a new user arrived (via STOMP
> > messges).
> 
> What I understand:
> 
> [browser] ---(http)---> [RestQ--->MorbidQ] ---(stomp)---> [orbited]
> ---(http)---> [browsers]
> 
> > What is the preferred way for this in RabbitMQ. Is there some similar
> > restful service?
> 
> We do have an attempt to create some sort of restful interface for rabbitmq
>    http://hg.rabbitmq.com/rabbitmq-jsonrpc-channel/
> but it's experimental and _not_ supported.
> 
> On the other hand I can't see a reason why you just won't publish a
> stomp message
> from your normal web server. Something like:
> 
> [browser] ---(http)---> [your-web-server] ---(stomp)---> [orbited]
> ---(http)---> [browsers]

The point is that if a user closes its browser, the javascript on that page 
(if the user is visiting my site) has no change to signal any away messages 
(like STOMP's unsubscribe). The only sure way to handle that is within the 
broker.


Regards,
wr