# How discourse stays online (Message Bus, Faye, Long Polling)
**URL:** https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238
**Category:** Development
**Created:** [February 16, 2013, 8:20pm UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238 "2013-02-16T20:20:50Z")
**Posts on this page:** 6
**Page:** 2
### Author:  [@eggie5](https://meta.discourse.org/u/eggie5)
#### Post date: [January 27, 2015, 2:04am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/22 "2015-01-27T02:04:08Z")
Yeah, the whole backend is powered by message\_bus. The android/ios client long-polls. Not sure if this is the best use of message\_bus, but It works w/o the added complexity of web sockets. The major win is that it fits in our existing rails stack. The only disadvantage i’ve come across so far is that I can’t find an elegant way to support the typing indicator.
[http://www.eggie5.com/58-real-time-messenging-w-ruby-ios-android](http://www.eggie5.com/58-real-time-messenging-w-ruby-ios-android)
---
### Author:  [@mumf83](https://meta.discourse.org/u/mumf83)
#### Post date: [July 20, 2015, 11:32am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/23 "2015-07-20T11:32:40Z")
@sam I see this works with Thin. What about Unicorn, I’ve read that Thin is excellent (best supported) with Long-Polling, is this why you only support Thin when using Long-Polling with your message\_bus gem?
Please correct me if I’m wrong but looking at the code Long-Polling seems to be enabled if Thin is running?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 20, 2015, 11:34am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/24 "2015-07-20T11:34:12Z")
It works fine with unicorn, in fact we host all our sites on unicorn.
unicorn, passenger and puma all support rack hijack. This means message\_bus can pull sockets out of the normal lifecycle and release the connections back to unicorn while keeping the socket open.
---
### Author:  [@mumf83](https://meta.discourse.org/u/mumf83)
#### Post date: [July 20, 2015, 11:40am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/25 "2015-07-20T11:40:49Z")
That’s great to know. Thank you. Will read up on rack hijack.
---
### Author:  [@swilgosz](https://meta.discourse.org/u/swilgosz)
#### Post date: [December 31, 2021, 8:09am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/26 "2021-12-31T08:09:41Z")
@sam From what I got by reading the README and this thread, `message_bus` seems to be a pure notification system (sth like a Pusher alternative)
Am I correct by saying, it’s not designed for implementing event sourcing in a distributed systems?
All examples here are rather related to short-term messaging catch-up, but it’s not possible to restore old app state from the events stream, due to the truncation mechanism. Is there anything I missed?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [January 4, 2022, 10:52am UTC](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/27 "2022-01-04T10:52:40Z")
> [@swilgosz](#):
>
> All examples here are rather related to short-term messaging catch-up, but it’s not possible to restore old app state from the events stream, due to the truncation mechanism.
Technically you could kick retention up and use PG as a backend. That said holding a transaction log forever certainly has costs. Rebuilding a DB from 10 years of transactions, though feasible is probably not something you would be doing.
[Previous page](https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238.md?page=1)