Timeouts problem in long-polling mode:

[ghost]

Hello,

I have timeouts problem in in long-polling mode (closing session after timeout):

None of push_stream_subscriber_connection_ttl and push_stream_message_ttl initiate server session closing after timeout.

So , questions: 1) Do I need to break session periodically? 2) Is push_stream_subscriber_connection_ttl and push_stream_message_ttl right directive for setting session slosing timeouts or you have another for this?

Best regards, Eugene Istomin

[wandenberg]

Hi Eugene,

Could you send me your configuration file and what are you doing? With that I can reproduce your "problem".

The push_stream_subscriber_connection_ttl is used for memory cleanup purposes, not for session timeout controls. If you set, for example, push_stream_subscriber_connection_ttl 15m, the subscriber will be disconnected in any time between 15 and19:59 minutes after it connects. This happens because the check interval will be 15 minutes divided by 3 plus 1 second (5:01) and in the worst case when subscriber connect 1 second before check occurs it will wait more 3 checks to be disconnected.

I will use your problem to see if I can do this in a better way.

I am waiting your informations.

Regards, Wandenberg

On Fri, Sep 23, 2011 at 5:57 AM, evis < reply@reply.github.com>wrote:

Hello,

I have timeouts problem in in long-polling mode (closing session after timeout):

None of push_stream_subscriber_connection_ttl and push_stream_message_ttl initiate server session closing after timeout.

So , questions: 1) Do I need to break session periodically? 2) Is push_stream_subscriber_connection_ttl and push_stream_message_ttl right directive for setting session slosing timeouts or you have another for this?

Best regards, Eugene Istomin

Reply to this email directly or view it on GitHub: https://github.com/wandenberg/nginx-push-stream-module/issues/5

[rewlad]

We have an application with long-polling. Until now long-polling is implemented as tiny apache 1.3 module with scoreboard, sleep(), kill(). Consuming a process per waiting connection was simple-to-code but not effective. Now we are migrating to nginx.

According to my exploration:

• streaming is promising tech, but not yet well supported by all browsers; so we need to keep long-polling;
• having connection just opened for any period of time looks not reliable; it would be better to have some periodical (~1m) feedback from server to browser, that everything is OK;
• XMLHTTPRequest.abort() does not work well; So the solution is periodical: server closes connection with OK response, then browser re-opens connection and waits. Fix me, if my exploration is wrong, and fears аrе unreasonable.

We just followed Your default instructions to build-run-test nginx-push-stream-module. ... server { listen 5080; ... location ~ /sub/(.*) { push_stream_subscriber long-polling; set $push_stream_channels_path $1; } ... curl -s -v 'http://localhost:5080/sub/my_channel_1.b1' curl will just block. And setting push_stream_ping_message_interval seems not affecting long-polling mode too. What is the way to control timeout?

--==Yours, Sergei Kirjanov==--

[wandenberg]

Hi,

thank you for trying this module.

The long-polling support use some headers to work, Last-Modified-Time and ETag when server send messages to subscriber, and, If-Modified-Since and If-None-Match when subscriber make a request to the server (you may use event-id if needs more control like in Event Source protocol).

To work in this way nothing is sent to subscriber until has a message to send, the push_stream_ping_message_interval was designed to work on streaming connections.

If you plan to use only long-polling connections I suggest you to set push_stream_subscriber_connection_ttl to 1m, for example, and the server will disconnect your subscriber in at most 1:30 m (yes, the disconnect is not exactly to avoid high cpu consuming, I will try to do that in a better way like I said on last email).

About browser support for streaming I suppose they all work if you use "forever iframe" technique. We have an example of that on misc folder, which is in use at http://www.nginxpushstream.com/chat.html . I was tested on Chrome, IE (7-9), Firefox and Safari.

Thanks for your message, it helps find a small bug and see I really have to improve the documentation adding more examples.

Get the last updates before continue testing, please.

If you have any other doubt or suggestion feel free to send another message.

Regards, Wanden

On Sat, Sep 24, 2011 at 7:43 AM, rewlad < reply@reply.github.com>wrote:

We have an application with long-polling. Until now long-polling is implemented as tiny apache 1.3 module with scoreboard, sleep(), kill(). Consuming a process per waiting connection was simple-to-code but not effective. Now we are migrating to nginx.

According to my exploration:

• streaming is promising tech, but not yet well supported by all browsers; so we need to keep long-polling;
• having connection just opened for any period of time looks not reliable; it would be better to have some periodical (~1m) feedback from server to browser, that everything is OK;
• XMLHTTPRequest.abort() does not work well; So the solution is periodical: server closes connection with OK response, then browser re-opens connection and waits. Fix me, if my exploration is wrong, and fears r unreasonable.

We just followed Your default instructions to build-run-test nginx-push-stream-module. ... server { listen 5080; ... location ~ /sub/(.*) { push_stream_subscriber long-polling; set $push_stream_channels_path $1; } ... curl -s -v 'http://localhost:5080/sub/my_channel_1.b1' curl will just block. And setting push_stream_ping_message_interval seems not affecting long-polling mode too. What is the way to control timeout?

--==Yours, Sergei Kirjanov==--

Reply to this email directly or view it on GitHub:

https://github.com/wandenberg/nginx-push-stream-module/issues/5#issuecomment-2185849

[wandenberg]

Hi Eugene and Sergei,

may I close this issue?

Regards, Wanden

[rewlad]

Yes;

Thank You! :-)

2011/9/30 Wandenberg Peixoto reply@reply.github.com:

Hi Eugene and Sergei,

may I close this issue?

Regards, Wanden

Reply to this email directly or view it on GitHub: https://github.com/wandenberg/nginx-push-stream-module/issues/5#issuecomment-2253014

--==Yours, Sergei Kirjanov==--

[wandenberg]

Just as an update, on version 0.3.1 disconnect timeout was refactored and now it occurs on exact time.