Closed kamil-michalak closed 12 years ago
Think I'm having a similar issue,
When using push_stream_store_messages and specifying a backtrack number (.b10) I keep getting the same set of messages even though the etag and timestamp are being sent to the server.
Using the pushstream.js in long polling mode, almost identical to your examples except for the push_stream_store_messages entry in the nginx configuration.
Without the push_stream_store_messages entry the client doesn't get all messages sent to the channel (even with .b10) if other clients send messages within a second of each other. It seems to lose/drop the first few messages and only return the last one in the queue.
Hi,
the backtrack only makes sense on stream mode, or on the first get to the server when using longpolling. probably I will drop the support of backtrack with longpolling on next version to avoid this problems and misunderstanding. when using longpolling use the secondsAgo attribute.
Karolo, if you don't set the push_stream_store_messages to on, you will not be able to get old messages.
It'd be handy to be able to use backtrack with longpolling - could we just set it to use the backtrack parameter only on the first long-polling request? Otherwise it's impossible to combine long-polling and stream wrappers when you need backtrack support - if the stream wrappers fail, long-polling will get stuck in a loop.
Try this demo http://www.nginxpushstream.com/chat_longpolling.html and set room to example.b10 (backtrack=10) and you can see error in log box. There are a lots of hits send to server ;)