I'm using Colloquy Version 2.4.3 (6011) to connect to ZNC ZNC 1.7.x-git-481-2cb6599 IPv6: yes, SSL: yes, DNS: threads, charset: yes running on Lubuntu 15.10 wily.
Every time I open Colloquy and connect to ZNC again, I get the exact same 16 lines from route_replies:
<*route_replies> This module hit a timeout which is probably a connectivity issue.
<*route_replies> However, if you can provide steps to reproduce this issue, please do report a bug.
<*route_replies> To disable this message, do "/msg *route_replies silent yes"
<*route_replies> Last request: MODE #gaygeeks-asl b
<*route_replies> Expected replies:
<*route_replies> 482 (last)
<*route_replies> 346
<*route_replies> 347 (last)
<*route_replies> 367
<*route_replies> 368 (last)
<*route_replies> 348
<*route_replies> 349 (last)
<*route_replies> 467 (last)
<*route_replies> 472 (last)
<*route_replies> 501 (last)
<*route_replies> 502 (last)
<*route_replies> Last request: MODE #gaygeeks-asl b refers to the channel on freenode.
I'm not sure when this started exactly—On occasions when I get errors from route_replies, I usually read over the errors and then ignore them as a "connectivity issue," but I eventually noticed this one was repeating.
I'm also not sure what other information would be helpful :x
I'm using Colloquy `Version 2.4.3 (6011)` to connect to ZNC `ZNC 1.7.x-git-481-2cb6599 IPv6: yes, SSL: yes, DNS: threads, charset: yes` running on Lubuntu `15.10 wily`.
**Every** time I open Colloquy and connect to ZNC again, I get the exact same 16 lines from route_replies:
```
<*route_replies> This module hit a timeout which is probably a connectivity issue.
<*route_replies> However, if you can provide steps to reproduce this issue, please do report a bug.
<*route_replies> To disable this message, do "/msg *route_replies silent yes"
<*route_replies> Last request: MODE #gaygeeks-asl b
<*route_replies> Expected replies:
<*route_replies> 482 (last)
<*route_replies> 346
<*route_replies> 347 (last)
<*route_replies> 367
<*route_replies> 368 (last)
<*route_replies> 348
<*route_replies> 349 (last)
<*route_replies> 467 (last)
<*route_replies> 472 (last)
<*route_replies> 501 (last)
<*route_replies> 502 (last)
```
> `<*route_replies> Last request: MODE #gaygeeks-asl b` refers to the channel on freenode.
I'm not sure when this started exactly—On occasions when I get errors from route_replies, I usually read over the errors and then ignore them as a "connectivity issue," but I eventually noticed this one was repeating.
I'm also not sure what other information would be helpful :x
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/28338595-route_replies-consistent-timeout-on-last-request-mode-gaygeeks-asl-b?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:117481780 -->
Eh, that pastebin contains the answer, "what IRC server returns in response to MODE". How exactly ZNC sends *route_replies message to client, is not so interesting.
But it looks like the channel's banlist is big enough, so that returning its mode takes more than 1 minute. The log is full of 367, and 368 which finishes this list isn't sent yet, while the timeout triggers.
Eh, that pastebin contains the answer, "what IRC server returns in response to MODE". How exactly ZNC sends `*route_replies` message to client, is not so interesting.
But it looks like the channel's banlist is big enough, so that returning its mode takes more than 1 minute. The log is full of 367, and 368 which finishes this list isn't sent yet, while the timeout triggers.
<!-- github-comment-id:157644160 -->
This has become much less consistent since I first posted it. Seems the problem is caused by something other than ZNC.
This has become much less consistent since I first posted it. Seems the problem is caused by something other than ZNC.
<!-- github-comment-id:160178324 -->
I've explained above what happens...
Not sure why now it happens less often. Either banlist got smaller, or it just gets sent to client faster.
In any case, this needs to be fixed.
I've explained above what happens...
Not sure why now it happens less often. Either banlist got smaller, or it just gets sent to client faster.
In any case, this needs to be fixed.
<!-- github-comment-id:160191723 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I'm using Colloquy
Version 2.4.3 (6011)to connect to ZNCZNC 1.7.x-git-481-2cb6599 IPv6: yes, SSL: yes, DNS: threads, charset: yesrunning on Lubuntu15.10 wily.Every time I open Colloquy and connect to ZNC again, I get the exact same 16 lines from route_replies:
I'm not sure when this started exactly—On occasions when I get errors from route_replies, I usually read over the errors and then ignore them as a "connectivity issue," but I eventually noticed this one was repeating.
I'm also not sure what other information would be helpful :x
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
znc -Dwith actual replies which server sent would be helpfulThis http://pastebin.com/m7BbgiMx is the end of
znc -D > znc.logtrimmed from……to just after I got the error from *route_replies and I stopped it:
I don't know what's relevant, so I'm sorry if this is an annoyingly huge dump. I have even more if I've trimmed out too much :P
This time it was #gaygeeks, not #gaygeeks-asl, so now I'm not sure how frequently I get one or the other…
Eh, that pastebin contains the answer, "what IRC server returns in response to MODE". How exactly ZNC sends
*route_repliesmessage to client, is not so interesting.But it looks like the channel's banlist is big enough, so that returning its mode takes more than 1 minute. The log is full of 367, and 368 which finishes this list isn't sent yet, while the timeout triggers.
This has become much less consistent since I first posted it. Seems the problem is caused by something other than ZNC.
I've explained above what happens...
Not sure why now it happens less often. Either banlist got smaller, or it just gets sent to client faster.
In any case, this needs to be fixed.