[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-658: -- Fix Version/s: (was: 7.0.0) 7.1.0 > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: A > Fix For: 7.1.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-658: --- Fix Version/s: (was: 6.1.0) 7.0.0 > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: A > Fix For: 7.0.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 6.0.0) 6.1.0 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: 6.1.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-658: -- Assignee: Alan M. Carroll (was: Phil Sorber) HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: 5.2.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-658: -- Fix Version/s: (was: 5.2.0) sometime HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: sometime It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-658: --- Fix Version/s: (was: sometime) 5.3.0 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Fix For: 5.3.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Assignee: Phil Sorber HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Phil Sorber Labels: A Fix For: 5.1.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 6.0.0) 5.1.0 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Labels: A Fix For: 5.1.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Component/s: HTTP Fix Version/s: (was: 3.3.4) 3.5.0 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 3.5.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 3.3.1) 3.3.4 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Fix For: 3.3.4 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 3.1.2) 3.2.0 HTTP SM holds the cache write lock for too long --- Key: TS-658 URL: https://issues.apache.org/jira/browse/TS-658 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Fix For: 3.2.0 It seems we open the cache for write very early on in the HTTP SM, which can have very bad effect on performance if the object is not cacheable. It's not totally clear as to why this is done this way, but we should examine this for v3.1, and try to minimize how long we hold the lock. It's possible this is related to read_while_writer, but then it should be modified IMO. -- 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
