[jira] [Updated] (TS-1031) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions
[ https://issues.apache.org/jira/browse/TS-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1031: Attachment: (was: ts-1031.diff) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions --- Key: TS-1031 URL: https://issues.apache.org/jira/browse/TS-1031 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: weijin Priority: Minor reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions. put your patch here for review :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1031) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions
[ https://issues.apache.org/jira/browse/TS-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1031: Attachment: ts-1031.diff reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions --- Key: TS-1031 URL: https://issues.apache.org/jira/browse/TS-1031 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: weijin Priority: Minor Attachments: ts-1031.diff reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions. put your patch here for review :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1031) reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions
[ https://issues.apache.org/jira/browse/TS-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159343#comment-13159343 ] Alan M. Carroll commented on TS-1031: - This is something of a hack. Longer term what would be better is to separate IO closure with re-allocation. If we used something like Ptr (from lib/ts/Ptr.h) to reference count and not put the VC back on the free list until the last reference clears, then this would be far less of a problem. It is plausible that everything crash has happened after a VC was free'd rather than just closed. The one issue would be cross thread freeing, although that should not be a problem unless there is a consistent drift of VCs to a single thread, although it might be that VCs are really freed when the thread local free list grows too large in which case this is just not maximally efficient. reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions --- Key: TS-1031 URL: https://issues.apache.org/jira/browse/TS-1031 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: weijin Priority: Minor Attachments: ts-1031.diff reduce lock in netHandler and reduce the possiblity of acquiring expire server sessions. put your patch here for review :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1035: - Attachment: UnixEventProcessor.patch EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159777#comment-13159777 ] Leif Hedstrom commented on TS-1035: --- Perhaps time to either make this limit records.config'urable, or bigger? What do you think ? EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159802#comment-13159802 ] Brian Geffon commented on TS-1035: -- I think records.configurable would be preferred; however, after manually raising the MAX_EVENT_THREADS and testing it works fine when running traffic_server directly but there are other bugs surfacing. In LocalManager.cc:1089 real_proxy_options has a hard coded length of 2048 (while this should probably use ARG_MAX which on linux is usually 120KB+). Because it's such a small limit with a large number of ports it will be unable to fully generate the -A list of file descriptors. I'm still looking around and trying to fully determine what it's going to take to get it working with traffic_manager. EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
