Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@ivanuschak commented on this pull request.
> @@ -1843,13 +1843,17 @@ inline static int handle_io(struct fd_map *fm, short events, int idx)
* handle_io might decide to del. the new connection =>
* must be in the list */
tcpconn_listadd(tcp_conn_lst, con, c_next, c_prev);
- t = get_ticks_raw();
- con->timeout = t + S_TO_TICKS(TCP_CHILD_TIMEOUT);
- /* re-activate the timer */
- con->timer.f = tcpconn_read_timeout;
- local_timer_reinit(&con->timer);
- local_timer_add(&tcp_reader_ltimer, &con->timer,
- S_TO_TICKS(TCP_CHILD_TIMEOUT), t);
+ if(con->rcv.proto_reserved2 && con->type == PROTO_WSS) {
+ //not setting up timers for haproxy WSS connections
Please pay attention at this particular change - from line 1846 to line 1856.
The purpose of this change is to keep the WSS connection connected. When testing this haproxy change without this particular piece of change (from line 1846 to line 1856) we observed that kamailio was dropping WSS connection by timer, and this drop looked strange, because it happened in about 5-7 seconds after the connection was established. One of the requirement for haproxy was to keep TLS/WSS connection established during all the dialog and not to drop it without any important reason. I tried to find how to make it not to be dropped by timer, but found the only way is to not to set the timer up for WSS. Also the drop cause is still not cleat for me.
I don't think this is a good solution, but I was not able to find a better one. I would appreciate if you check this change attentively. If needed I can provide with the logs where kamailio drops WSS connection.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.