View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000974 | unreal | ircd | public | 2003-05-11 16:45 | 2003-11-20 19:43 |
| Reporter | DiStuRbEd | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2-beta16 | ||||
| Summary | 0000974: Exceeded Max Sendq Problem with /who queries | ||||
| Description | anytime you do a broad /who or a /who +flag and broad mask, users will be disconnected for exceeding max sendq. | ||||
| Steps To Reproduce | just type /who or /who -h *jj* | ||||
| 3rd party modules | |||||
|
|
You can set the max send queue in class::sendq. It's there to prevent flooding, you can set it very high if you want.. just don't be surprised if you die when 200 clones start mass /who'ing or something. |
|
|
simply increasing the sendq isn't the solution. This was not a problem in previous versions of unreal at the same sendq level. |
|
|
> simply increasing the sendq isn't the solution. Why not? > This was not a problem in previous versions of unreal at the same sendq level. Maybe you just got more users? ;p |
|
|
no, we have the same amount of users. same amount of servers. so, something is differnt ;) |
|
|
hmm, I got disconnecting for exceeding max sendq when I did /stats G with beta16. |
|
|
i suspect any long list in beta16 will cause this same error. |
|
|
I still don't hear an actual bug here... sendq limit is just being enforced (which exists at almost any ircd). If you find it set too low, increase it. I usually have it set pretty high [like >1Mb] for an oper block. |
|
|
Even at 1MB this still occurs. As i said, this did not happen in previous versions of Unreal. It's a minor thing, but i can see where it could be a big problem when it's really needed. Thanks for your help |
|
|
This is not a bug, it is Unreal working as it was designed. And saying it didn't happen in previous versions is wrong. I just caused the exact same thing to occur in b13, 14, and 15. It is NOT a bug, it is how it is supposed to work. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-05-11 16:45 | DiStuRbEd | New Issue | |
| 2003-05-11 17:45 | syzop | Status | new => resolved |
| 2003-05-11 17:45 | syzop | Resolution | open => fixed |
| 2003-05-11 17:45 | syzop | Assigned To | => syzop |
| 2003-05-11 17:45 | syzop | Note Added: 0002750 | |
| 2003-05-11 19:48 | DiStuRbEd | Status | resolved => feedback |
| 2003-05-11 19:48 | DiStuRbEd | Resolution | fixed => reopened |
| 2003-05-11 19:48 | DiStuRbEd | Note Added: 0002753 | |
| 2003-05-11 20:47 | syzop | Note Added: 0002754 | |
| 2003-05-11 21:00 | DiStuRbEd | Note Added: 0002755 | |
| 2003-05-11 21:08 | Joolz | Note Added: 0002756 | |
| 2003-05-11 21:12 | DiStuRbEd | Note Added: 0002758 | |
| 2003-05-11 21:20 | syzop | Note Added: 0002759 | |
| 2003-05-11 21:33 | DiStuRbEd | Note Added: 0002760 | |
| 2003-05-11 22:00 |
|
Status | feedback => resolved |
| 2003-05-11 22:00 |
|
Resolution | reopened => no change required |
| 2003-05-11 22:00 |
|
Assigned To | syzop => codemastr |
| 2003-05-11 22:00 |
|
Note Added: 0002761 | |
| 2003-11-20 19:43 | syzop | Status | resolved => closed |
