[jira] [Created] (TS-1872) More robust compiler detection
Igor Galić created TS-1872: -- Summary: More robust compiler detection Key: TS-1872 URL: https://issues.apache.org/jira/browse/TS-1872 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Igor Galić Right now our build detects compilers based on their name, especially if this name is just cc that's not very helpful. Following this discussion: http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201305.mbox/%3c38a46ac3-3fbb-479f-b7b6-c4b9e9882...@me.com%3E I'm adding this http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_compiler_vendor.m4;hb=HEAD autoconf check. -- 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] [Commented] (TS-1872) More robust compiler detection
[ https://issues.apache.org/jira/browse/TS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648250#comment-13648250 ] ASF subversion and git services commented on TS-1872: - Commit c400c88485c748b1d811d98336df668eb83169be in branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c400c88 ] TS-1872 More robust compiler detection we add autoconf-archive's ax_compiler_vendor to more robustly detect which compiler we're dealing with. (For varying interpretations of robustness when dealing with autoconf) More robust compiler detection -- Key: TS-1872 URL: https://issues.apache.org/jira/browse/TS-1872 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Igor Galić Right now our build detects compilers based on their name, especially if this name is just cc that's not very helpful. Following this discussion: http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201305.mbox/%3c38a46ac3-3fbb-479f-b7b6-c4b9e9882...@me.com%3E I'm adding this http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_compiler_vendor.m4;hb=HEAD autoconf check. -- 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] [Commented] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648428#comment-13648428 ] Leif Hedstrom commented on TS-1822: --- Have you verified it with some large memory installation? The way this would manifest itself was an out of memory error, when we ran out of the (default) 50k mmap segments. I'd be curious to hear from e.g. Comcast or yahoo what the deal is? Perhaps by chance this setting is related to Comcast's problem where they can't use the large (384GB) RAM for ram-cache? Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: James Peach Fix For: 3.3.3 A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- 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] [Commented] (TS-1832) automatically upgrade HostDB for 3.4
[ https://issues.apache.org/jira/browse/TS-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648434#comment-13648434 ] Leif Hedstrom commented on TS-1832: --- Yes. v3.3.3 should be compatible now with v3.3.1 and earlier. When we release v3.3.3, we have to tell people who are upgrading from v3.3.2 to revert the config changes they made. automatically upgrade HostDB for 3.4 Key: TS-1832 URL: https://issues.apache.org/jira/browse/TS-1832 Project: Traffic Server Issue Type: Bug Components: Core, DNS Reporter: James Peach http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201304.mbox/%3c02b034ee-ae6b-4cde-959a-2bf80c730...@yahoo-inc.com%3e As described by Bryan in the message above, upgrading to the newer HostDB format breaks DNS resolution. We should make sure that users upgrading from stable 3.2 releases never hit this problem. -- 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] [Created] (TS-1873) RAM cache unable to use large memory ?
Leif Hedstrom created TS-1873: - Summary: RAM cache unable to use large memory ? Key: TS-1873 URL: https://issues.apache.org/jira/browse/TS-1873 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom This is anecdotal, and not verified. But supposedly, the RAM cache would not utilize very large amounts of RAM allocated. I'm filing a bug to not forget about this. I'm pondering if this could be related to running out of mmap segments, but, that should manifest itself as a crash (out of memory). TS-1822. -- 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-1873) RAM cache unable to use large memory ?
[ https://issues.apache.org/jira/browse/TS-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1873: -- Fix Version/s: 3.3.4 RAM cache unable to use large memory ? -- Key: TS-1873 URL: https://issues.apache.org/jira/browse/TS-1873 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Fix For: 3.3.4 This is anecdotal, and not verified. But supposedly, the RAM cache would not utilize very large amounts of RAM allocated. I'm filing a bug to not forget about this. I'm pondering if this could be related to running out of mmap segments, but, that should manifest itself as a crash (out of memory). TS-1822. -- 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-1873) RAM cache unable to use large memory ?
[ https://issues.apache.org/jira/browse/TS-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1873: -- Component/s: Cache RAM cache unable to use large memory ? -- Key: TS-1873 URL: https://issues.apache.org/jira/browse/TS-1873 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Fix For: 3.3.4 This is anecdotal, and not verified. But supposedly, the RAM cache would not utilize very large amounts of RAM allocated. I'm filing a bug to not forget about this. I'm pondering if this could be related to running out of mmap segments, but, that should manifest itself as a crash (out of memory). TS-1822. -- 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] [Commented] (TS-1838) Compiler detection is naive and broken
[
https://issues.apache.org/jira/browse/TS-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648472#comment-13648472
]
Leif Hedstrom commented on TS-1838:
---
I think the macro stuff was committed in TS-1872. So we should close this as
resolved (there were other changes in here that improves overall usability
around this).
Compiler detection is naive and broken
--
Key: TS-1838
URL: https://issues.apache.org/jira/browse/TS-1838
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: James Peach
Fix For: 3.3.3
It also doesn't like e.g.
{code}
./configure CC='ccache clang'
{code}
Because, now cc != clang. What's worse, doing e.g.
The case statement is to specific, we should probably wildcard it.
--
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] [Commented] (TS-1838) Compiler detection is naive and broken
[
https://issues.apache.org/jira/browse/TS-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648499#comment-13648499
]
James Peach commented on TS-1838:
-
No, I think my patch is somewhat better, so I'd like to keep this around until
I can publish it and have Igor review it.
Compiler detection is naive and broken
--
Key: TS-1838
URL: https://issues.apache.org/jira/browse/TS-1838
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: James Peach
Fix For: 3.3.3
It also doesn't like e.g.
{code}
./configure CC='ccache clang'
{code}
Because, now cc != clang. What's worse, doing e.g.
The case statement is to specific, we should probably wildcard it.
--
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] [Commented] (TS-1838) Compiler detection is naive and broken
[
https://issues.apache.org/jira/browse/TS-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648509#comment-13648509
]
Leif Hedstrom commented on TS-1838:
---
Can't we just move that to Igor's bug then? Or do we need both bugs ?
Compiler detection is naive and broken
--
Key: TS-1838
URL: https://issues.apache.org/jira/browse/TS-1838
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: James Peach
Fix For: 3.3.3
It also doesn't like e.g.
{code}
./configure CC='ccache clang'
{code}
Because, now cc != clang. What's worse, doing e.g.
The case statement is to specific, we should probably wildcard it.
--
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-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1381: -- Fix Version/s: (was: sometime) 3.5.0 Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Fix For: 3.5.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- 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] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648587#comment-13648587 ] Leif Hedstrom commented on TS-1381: --- Note that is probably a general case for all transforms too, who also depend on the chunked transform. Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Fix For: 3.5.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- 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-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1381: -- Component/s: Performance Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP, Performance Reporter: Leif Hedstrom Fix For: 3.5.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- 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-81) Have one single place to store and lookup remap rules irrespective of type
[ https://issues.apache.org/jira/browse/TS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-81: Labels: A (was: ) Have one single place to store and lookup remap rules irrespective of type -- Key: TS-81 URL: https://issues.apache.org/jira/browse/TS-81 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.0.0a Reporter: Manjesh Nilange Priority: Minor Labels: A Fix For: 3.5.0 Currently, remap rules are stored in different structures and looked up separately based on type (forward, reverse, etc.). It'd be better design and more maintainable to process (store, search) all rules in one structure and then use type to determine action. -- 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-149) Split ram and disk cache hit response times into separate metrics
[ https://issues.apache.org/jira/browse/TS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-149: - Labels: A (was: ) Split ram and disk cache hit response times into separate metrics - Key: TS-149 URL: https://issues.apache.org/jira/browse/TS-149 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: Anirban Priority: Minor Labels: A Fix For: 3.5.0 Split ram and disk cache hit response times into separate metrics Original description by Stephen Bisordi from Yahoo It appears that the response time for ram cache hits and disk cache hits is captured as a single metric (transaction_totaltime.hit_fresh). Would it be possible to split this into two separate metrics, or to add a ram cache hit result code to the log to differentiate between ram and disk hits (similar to Squid's TCP_MEM_HIT)? This change would allow for quicker troubleshooting of certain issues such as poor disk performance. -- 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-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-153: - Labels: A (was: ) Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Priority: Minor Labels: A Fix For: 3.5.0 (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- 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-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-309: - Labels: A (was: ) Report OS Errors in Header -- Key: TS-309 URL: https://issues.apache.org/jira/browse/TS-309 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Labels: A Fix For: 3.5.0 (from yahoo bug 1021194) Original description by Ryan Troll 3 years ago at 2007-01-17 13:20 Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 Scott asked for a way to look at a YTS response and differentiate between a TS error, and an Origin server error. I *think* the general idea is that, whenever the origin server returns an error; we return it to the client. However, if there's a problem contacting the origin server, we should return the appropriate HTTP response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 including 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported and specify what Origin Server triggered the error in the Warning header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 I think we could define our own warn code and use it specify the origin server host (by name and IP): 504 Gateway Timeout Date: Wed, 17 Jan 2007 21:17:25 GMT Warning: 599 l1.ycs.s1s.yahoo.com:80 OS: us.yimg.com [66.218.71.81] But that's just a thought. Maybe mnot has a good suggestion -- he pointed us towards the Warning: header, and may know of good examples of it's use in the real world. Comment 1 by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 There's a pretty cool feature in TS, where it embeds codes into a Via header (if those are turned on) where someone looking at the headers can see whether it was a cache hit, an IMS hit, etc. As it moves through the state machine, it appends characters to the string - and in the reply you get something like [uN l oS f pS eN] which would translate to a user issuing a no-cache pragma, that resulted in an origin server fetch, which was served without error. It's pretty useful, so we might want to consider enabling this. There's a cheat sheet at /dev/traffic/trunk/proxy/http2/README.via chuck -- 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] [Commented] (TS-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648595#comment-13648595 ] Leif Hedstrom commented on TS-309: -- Maybe this is also related to generic handing of X-Cache and Via header, see TS-1571. It feels like a generic API / templating system, to have the system fill in strings ala printf() would be useful. Then we can have default templates for the current Via: syntax, and plugins can use the same templating code to add arbitrary headers with this as well. Report OS Errors in Header -- Key: TS-309 URL: https://issues.apache.org/jira/browse/TS-309 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Labels: A Fix For: 3.5.0 (from yahoo bug 1021194) Original description by Ryan Troll 3 years ago at 2007-01-17 13:20 Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 Scott asked for a way to look at a YTS response and differentiate between a TS error, and an Origin server error. I *think* the general idea is that, whenever the origin server returns an error; we return it to the client. However, if there's a problem contacting the origin server, we should return the appropriate HTTP response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 including 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported and specify what Origin Server triggered the error in the Warning header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 I think we could define our own warn code and use it specify the origin server host (by name and IP): 504 Gateway Timeout Date: Wed, 17 Jan 2007 21:17:25 GMT Warning: 599 l1.ycs.s1s.yahoo.com:80 OS: us.yimg.com [66.218.71.81] But that's just a thought. Maybe mnot has a good suggestion -- he pointed us towards the Warning: header, and may know of good examples of it's use in the real world. Comment 1 by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 There's a pretty cool feature in TS, where it embeds codes into a Via header (if those are turned on) where someone looking at the headers can see whether it was a cache hit, an IMS hit, etc. As it moves through the state machine, it appends characters to the string - and in the reply you get something like [uN l oS f pS eN] which would translate to a user issuing a no-cache pragma, that resulted in an origin server fetch, which was served without error. It's pretty useful, so we might want to consider enabling this. There's a cheat sheet at /dev/traffic/trunk/proxy/http2/README.via chuck -- 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-1571) Steal^Wborrow httpd's mod_cache idea of X-Cache-Detail headers
[ https://issues.apache.org/jira/browse/TS-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1571: -- Labels: A (was: ) Steal^Wborrow httpd's mod_cache idea of X-Cache-Detail headers -- Key: TS-1571 URL: https://issues.apache.org/jira/browse/TS-1571 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Igor Galić Labels: A Fix For: 3.5.0 Starting v2.3.9 httpd's mod_cache implements a feature enabled by [CacheDetailHeader|http://httpd.apache.org/docs/trunk/mod/mod_cache.html#cachedetailheader] - which in nature is very similar to our Via header feature but is easier to read and understand by spelling out why something was cached/missed/revalidated/etc.. in words - so it doesn't need a decoder ring. Given that we already have Via headers feature it should be fairly easy to implement a logic for producing a very similar header our selves. -- 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-1841) Use libloader to share libraries between plugins
[ https://issues.apache.org/jira/browse/TS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1841: Fix Version/s: Doc 3.4 Use libloader to share libraries between plugins Key: TS-1841 URL: https://issues.apache.org/jira/browse/TS-1841 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Igor Galić Fix For: Doc 3.4 Right now we have two plugins with inter-dependent libraries, those are esi and combo_handler. We should split those up and use libloader to load the share dependencies. -- 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] [Commented] (TS-1841) Use libloader to share libraries between plugins
[ https://issues.apache.org/jira/browse/TS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648696#comment-13648696 ] James Peach commented on TS-1841: - Currently, esi and combo_handler share the same code, but link statically. Using libloader would require the admin to do extra configuration to use the plugins, so not sure whether we would want that. Use libloader to share libraries between plugins Key: TS-1841 URL: https://issues.apache.org/jira/browse/TS-1841 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Igor Galić Fix For: Doc 3.4 Right now we have two plugins with inter-dependent libraries, those are esi and combo_handler. We should split those up and use libloader to load the share dependencies. -- 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-1862) build error with --enable-linux-native-aio
[ https://issues.apache.org/jira/browse/TS-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1862: Fix Version/s: 3.3.3 build error with --enable-linux-native-aio -- Key: TS-1862 URL: https://issues.apache.org/jira/browse/TS-1862 Project: Traffic Server Issue Type: Bug Reporter: bettydramit Fix For: 3.3.3 make[2]: Leaving directory `/data/rpmbuild/BUILD/ts-3.3.3/iocore/net' Making all in aio make[2]: Entering directory `/data/rpmbuild/BUILD/ts-3.3.3/iocore/aio' CXXAIO.o CXXInline.o cc1plus: warnings being treated as errors AIO.cc:546: error: unused parameter 'event' AIO.cc:600: error: unused parameter 'fromAPI' AIO.cc:610: error: unused parameter 'fromAPI' AIO.cc:620: error: unused parameter 'fromAPI' AIO.cc:647: error: unused parameter 'fromAPI' make[2]: *** [AIO.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/data/rpmbuild/BUILD/ts-3.3.3/iocore/aio' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/rpmbuild/BUILD/ts-3.3.3/iocore' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.Yz6dqL (%build) -- 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] [Commented] (TS-1824) TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter
[ https://issues.apache.org/jira/browse/TS-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648712#comment-13648712 ] James Peach commented on TS-1824: - The behaviour changed in 1a8dc832c261d28c9fa53e2964b850944f8905b1, February 2011. Removing the out parameter is ABI-compatible and has no impact on the behaviour. We should do this. TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter Key: TS-1824 URL: https://issues.apache.org/jira/browse/TS-1824 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom I think this is a failed refactoring from the past, where TSHttpTxnPushedRespHdrBytesGet() was changed to return the int (bytes), but the input parameter was left. Changing this would break API / ABI compatibilities though :-/. -- 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-1824) TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter
[ https://issues.apache.org/jira/browse/TS-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1824: Fix Version/s: 3.3.3 Assignee: Leif Hedstrom TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter Key: TS-1824 URL: https://issues.apache.org/jira/browse/TS-1824 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 I think this is a failed refactoring from the past, where TSHttpTxnPushedRespHdrBytesGet() was changed to return the int (bytes), but the input parameter was left. Changing this would break API / ABI compatibilities though :-/. -- 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] [Commented] (TS-1867) combo_handler crashes when combine non-200 response from upstream
[ https://issues.apache.org/jira/browse/TS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648724#comment-13648724 ] ASF subversion and git services commented on TS-1867: - Commit 8650d81f725af40bd2143485922cfa34a8eec33a in branch refs/heads/master from [~conanmind] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8650d81 ] TS-1867: combo_handler crashes with non-200 responses combo_handler crashes when combining non-200 response from upstream. combo_handler crashes when combine non-200 response from upstream - Key: TS-1867 URL: https://issues.apache.org/jira/browse/TS-1867 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Conan Wang Attachments: TS-1867.patch I'm sure the crashes appear after TS-1710. TS-1710 start to save non-200 response(header), while in the past the non-200 response was always empty which is the flag for combo_handler to decide whether to produce 400 BAD REQUEST to user. The attached patch adds a member of ResponseData for combo_handler(or other ESI client) to get the status code of upstream response. -- 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-1867) combo_handler crashes when combine non-200 response from upstream
[ https://issues.apache.org/jira/browse/TS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1867: Fix Version/s: 3.3.3 Assignee: James Peach Thanks for the patch! combo_handler crashes when combine non-200 response from upstream - Key: TS-1867 URL: https://issues.apache.org/jira/browse/TS-1867 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Conan Wang Assignee: James Peach Fix For: 3.3.3 Attachments: TS-1867.patch I'm sure the crashes appear after TS-1710. TS-1710 start to save non-200 response(header), while in the past the non-200 response was always empty which is the flag for combo_handler to decide whether to produce 400 BAD REQUEST to user. The attached patch adds a member of ResponseData for combo_handler(or other ESI client) to get the status code of upstream response. -- 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-1871) No Error on Startup if auto_conf Port is Unavailable
[ https://issues.apache.org/jira/browse/TS-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1871: Fix Version/s: 3.3.5 No Error on Startup if auto_conf Port is Unavailable Key: TS-1871 URL: https://issues.apache.org/jira/browse/TS-1871 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Clinton Wolfe Fix For: 3.3.5 If another process is already listening on the auto_conf port (8083 by default), traffic_manager silently fails to bind to it. This can break heartbeats, because heartbeats are sent to the process on 8083 (which will probably not give the expected response as http://127.0.0.1:8083/synthetic.txt). With heartbeats broken, traffic_cop constantly re-starts traffic_server - which was the obvious symptom, in my case. Observed on ts 3.2.4, stock config, centos 5.9 discussed in #traffic-server on freenode IRC, ortho_stice (clintoncwolfe) and amc, 2013-05-01 and 2013-05-02 -- 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] [Resolved] (TS-1832) automatically upgrade HostDB for 3.4
[ https://issues.apache.org/jira/browse/TS-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1832. - Resolution: Duplicate Assignee: James Peach Closing as a dupe. automatically upgrade HostDB for 3.4 Key: TS-1832 URL: https://issues.apache.org/jira/browse/TS-1832 Project: Traffic Server Issue Type: Bug Components: Core, DNS Reporter: James Peach Assignee: James Peach http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201304.mbox/%3c02b034ee-ae6b-4cde-959a-2bf80c730...@yahoo-inc.com%3e As described by Bryan in the message above, upgrading to the newer HostDB format breaks DNS resolution. We should make sure that users upgrading from stable 3.2 releases never hit this problem. -- 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-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1595: Fix Version/s: sometime Moving out to sometime, because I don't understand what change (if any) is being proposed here. Bin Chen, please reschedule if you disagree. different domain have different origin_max_connections? --- Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Sub-task Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor Fix For: sometime In our env, we want different domain having different origin_max_connections to manage connection more careful avoiding network throttling. If not have different config in remap, use origin_max_connections default. Other, config in remap will replace origin_max_connections. -- 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-1578) connection management
[ https://issues.apache.org/jira/browse/TS-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1578: Summary: connection management (was: connection manage) connection management - Key: TS-1578 URL: https://issues.apache.org/jira/browse/TS-1578 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.5 ts must handle some connection cases: 1、receiving large concurrent connections suddenly 2、have slow original server(incomming producer greater than consumer), so will be throttling. if throttling, ts will restart. Replacing throttling to max_accept limmiting maybe more friendly? 3、different domain have different origin_max_connections? 4、how to handle health check if use max_accept? -- 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] [Resolved] (TS-1872) More robust compiler detection
[ https://issues.apache.org/jira/browse/TS-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1872. - Resolution: Fixed Fix Version/s: 3.3.3 Assignee: Igor Galić This is working well for me. More robust compiler detection -- Key: TS-1872 URL: https://issues.apache.org/jira/browse/TS-1872 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.3.3 Right now our build detects compilers based on their name, especially if this name is just cc that's not very helpful. Following this discussion: http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201305.mbox/%3c38a46ac3-3fbb-479f-b7b6-c4b9e9882...@me.com%3E I'm adding this http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_compiler_vendor.m4;hb=HEAD autoconf check. -- 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-1840) make install requires a compiler
[
https://issues.apache.org/jira/browse/TS-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1840:
Fix Version/s: 3.3.4
It's probably been like this for ever, but let's try to at least understand the
issues for 3.3.4.
make install requires a compiler
Key: TS-1840
URL: https://issues.apache.org/jira/browse/TS-1840
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Fix For: 3.3.4
Are we missing something during the build?
{noformat}
make[2]: Entering directory `/home/igalic/src/asf/trafficserver/mgmt/api'
Making install in remote
make[3]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
make[4]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
/bin/mkdir -p '/opt/ats-trunk/lib'
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libtsmgmt.la '/opt/ats-trunk/lib'
libtool: install: warning: relinking `libtsmgmt.la'
libtool: install: (cd /home/igalic/src/asf/trafficserver/mgmt/api/remote;
/bin/bash /home/igalic/src/asf/trafficserver/libtool --silent --tag CXX
--mode=relink clang++ -std=c++11 -g -O3 -fno-strict-aliasing -Werror
-Qunused-arguments -Wno-invalid-offsetof -version-info 6:3:3 -o libtsmgmt.la
-rpath /opt/ats-trunk/lib CfgContextImpl.lo CfgContextManager.lo
CfgContextUtils.lo CoreAPIShared.lo EventCallback.lo GenericParser.lo
INKMgmtAPI.lo CoreAPIRemote.lo EventRegistration.lo NetworkUtilsRemote.lo
../../../lib/ts/libtsutil.la )
/home/igalic/src/asf/trafficserver/libtool: line 8982: clang++: command not
found
libtool: install: error: relink `libtsmgmt.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
{noformat}
--
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-1677) header_filter should first look in sysconfdir for its config file
[
https://issues.apache.org/jira/browse/TS-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1677:
Fix Version/s: 3.3.3
Assignee: James Peach
Let me look at this for 3.3.3.
header_filter should first look in sysconfdir for its config file
-
Key: TS-1677
URL: https://issues.apache.org/jira/browse/TS-1677
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Assignee: James Peach
Fix For: 3.3.3
When {{header_filter}} plugin gets a relative config-file, it should look for
it in our {{sysconfdir}}
--
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] [Commented] (TS-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648791#comment-13648791 ] Leif Hedstrom commented on TS-1595: --- So, I do know what this means :) Basically today, we have to global settings: 1) Max number of outgoing connections (total) 2) Max number of outgoing connections per origin. 2) is not configurable per remap rule, or origin, or anything like that. But there's a very valid use case where you want to say allow no more than 500 connections to origin1.example.com, and 2000 to origin2.example.com. different domain have different origin_max_connections? --- Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Sub-task Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor Fix For: sometime In our env, we want different domain having different origin_max_connections to manage connection more careful avoiding network throttling. If not have different config in remap, use origin_max_connections default. Other, config in remap will replace origin_max_connections. -- 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] [Commented] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648792#comment-13648792
]
James Peach commented on TS-871:
TS-1627 was committed. Is this still an issue? Is anyone able to set up a test
for this?
Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
---
Key: TS-871
URL: https://issues.apache.org/jira/browse/TS-871
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 3.3.3
Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
serf_revproxy.cap, stats.diff, TS-871-20121107.diff, TS-871.diff
When accessing a remote subversion repository via http or https with svn 1.7,
it will currently timeout:
{noformat}
igalic@tynix ~/src/asf % svn co
http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
svn: E020014: Unable to connect to a repository at URL
'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
svn: E020014: Unspecified error message: 504 Connection Timed Out
1 igalic@tynix ~/src/asf %
{noformat}
I have started traffic_server -Thttp and captured the output, which I'm
attaching.
There's also a capture from the network.
--
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] [Commented] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648795#comment-13648795
]
Leif Hedstrom commented on TS-871:
--
Yeah, I think there's more work on this. I have a test setup, I can fiddle with
it again after vacation.
Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
---
Key: TS-871
URL: https://issues.apache.org/jira/browse/TS-871
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 3.3.3
Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
serf_revproxy.cap, stats.diff, TS-871-20121107.diff, TS-871.diff
When accessing a remote subversion repository via http or https with svn 1.7,
it will currently timeout:
{noformat}
igalic@tynix ~/src/asf % svn co
http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
svn: E020014: Unable to connect to a repository at URL
'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
svn: E020014: Unspecified error message: 504 Connection Timed Out
1 igalic@tynix ~/src/asf %
{noformat}
I have started traffic_server -Thttp and captured the output, which I'm
attaching.
There's also a capture from the network.
--
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] [Commented] (TS-1770) Unable to create remap rule for SSL sites when accessed as a forward proxy
[
https://issues.apache.org/jira/browse/TS-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648827#comment-13648827
]
ASF subversion and git services commented on TS-1770:
-
Commit 16099e8541abc266cca0220fefb85fb904cdf48b in branch refs/heads/master
from [~a...@brivo.com]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=16099e8 ]
TS-1770 Unable to create remap rule for SSL sites when accessed as a
forward proxy.
Unable to create remap rule for SSL sites when accessed as a forward proxy
--
Key: TS-1770
URL: https://issues.apache.org/jira/browse/TS-1770
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.1, 3.2.4
Reporter: Mark Harrison
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.3.3
When connecting to https sites using ATS as a forward proxy, the CONNECT
method is used, and the URL doesn't have a scheme (http/https) present. When
using remap.config to limit which sites ATS will proxy for (remap_required
set to 1), there is no rule that can be made to match an a request without a
scheme present, and so no way to allow requests to a https site.
Example:
{code}
# curl -x 127.0.0.1:8080 -o /dev/null -v -s https://example.com/
* About to connect() to proxy 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Establish HTTP proxy tunnel to example.com:443
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Proxy-Connection: Keep-Alive
HTTP/1.1 404 Not Found
Date: Fri, 22 Mar 2013 21:41:25 GMT
Connection: close
Server: ATS/3.3.1-dev
Cache-Control: no-store
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 309
* Received HTTP code 404 from proxy after CONNECT
* Closing connection #0
{code}
--
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-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Labels: A (was: ) ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Priority: Critical Labels: A Fix For: 3.5.0 ATS does not verify the certificates correctly. -- 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-1873) RAM cache unable to use large memory ?
[ https://issues.apache.org/jira/browse/TS-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1873: -- Labels: A (was: ) RAM cache unable to use large memory ? -- Key: TS-1873 URL: https://issues.apache.org/jira/browse/TS-1873 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Labels: A Fix For: 3.3.4 This is anecdotal, and not verified. But supposedly, the RAM cache would not utilize very large amounts of RAM allocated. I'm filing a bug to not forget about this. I'm pondering if this could be related to running out of mmap segments, but, that should manifest itself as a crash (out of memory). TS-1822. -- 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] [Commented] (TS-1825) TSPortDescriptorAccept() does not use its TSCont contp parameter
[
https://issues.apache.org/jira/browse/TS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648961#comment-13648961
]
Leif Hedstrom commented on TS-1825:
---
You taking this one James? Should we A it ?
TSPortDescriptorAccept() does not use its TSCont contp parameter
Key: TS-1825
URL: https://issues.apache.org/jira/browse/TS-1825
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Leif Hedstrom
Priority: Blocker
Fix For: 3.3.3
This looks odd:
{code}
TSReturnCode
TSPortDescriptorAccept(TSPortDescriptor descp, TSCont contp)
{
HttpProxyPort * port = (HttpProxyPort *)descp;
return start_HttpProxyPort(*port, 0 /* nthreads */) ? TS_SUCCESS : TS_ERROR;
}
{code}
Assuming that (as per the IRC discussions) TSPortDescriptAccept() should work
something similar to TSNetAccept, shouldn't it be using the contp for
callbacks?
--
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-1816) active_timeout may lead TS crash
[ https://issues.apache.org/jira/browse/TS-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1816: -- Labels: A (was: ) active_timeout may lead TS crash Key: TS-1816 URL: https://issues.apache.org/jira/browse/TS-1816 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Labels: A 1: client request with 'If-Modified-Since' 2: ts has no copy in the cache and prepare for cache write 3: ts send server without the field 'If-Modified-Since' 4: server response hdr is back (200 0K) 5: suppose the request`s If-Modified-Since reponse`s Last-Modified, ts will send client 304 back(HttpSM::setup_internal_transfer) 6: ts will do the tunnel_handler_cache_fill to write the response to cache the is a problem in step 5 and step 6. In step 5, all the event`s associated by server_session is also handled by HttpSM::state_read_server_response_header rather than the tunnel, which may lead to serious problems. -- 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-1779) Crash using SNI and ssl_ca_name
[ https://issues.apache.org/jira/browse/TS-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1779: -- Labels: A (was: ) Crash using SNI and ssl_ca_name --- Key: TS-1779 URL: https://issues.apache.org/jira/browse/TS-1779 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Rodney Assignee: James Peach Labels: A Fix For: 3.3.3 When I add 'ssl_ca_name' to include a chain cert CA the traffic server fails to start with a core dump. It seems to be okay if I just have one entry in 'ssl_multicert.config' file but as soon as I use SNI the traffic server will not start with a core dump. This witnessed on 3.2.0 and currently 3.2.4 with Debian Squeeze. Example entries: ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt ssl_cert_name=my2.crt ssl_key_name=my2.key ssl_ca_name=my2CA.crt #Default dest_ip=* ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt -- 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] [Commented] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648963#comment-13648963 ] Leif Hedstrom commented on TS-1777: --- Is this still an issue? We're succesfully building on a fairly large number of 32-bit systems now. If it's not an issue, please close as invalid, and remove the Fix Version. can not build on 32 bit system -- Key: TS-1777 URL: https://issues.apache.org/jira/browse/TS-1777 Project: Traffic Server Issue Type: Bug Components: Build Reporter: weijin Assignee: weijin Fix For: 3.3.3 Attachments: ts-1777.diff ats can not build on 32 bit system because of TS-1742 (volatile key word removed). -- 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-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1648:
--
Labels: A (was: )
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: weijin
Labels: A
Fix For: 3.3.3
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
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] [Commented] (TS-1642) need sum up memory used in dir index
[ https://issues.apache.org/jira/browse/TS-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648964#comment-13648964 ] Leif Hedstrom commented on TS-1642: --- i think adding a metric for this could be useful, gives people an idea where the hell the memory is going. need sum up memory used in dir index Key: TS-1642 URL: https://issues.apache.org/jira/browse/TS-1642 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Zhao Yongming Fix For: 3.3.3 when we checking the memory usage in ATS, the ram and dir index usage always metter. we should print out the total memory used in dir index after cache init done, or add a stat for it. -- 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-1642) need sum up memory used in dir index
[ https://issues.apache.org/jira/browse/TS-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1642: -- Labels: A (was: ) need sum up memory used in dir index Key: TS-1642 URL: https://issues.apache.org/jira/browse/TS-1642 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Zhao Yongming Labels: A Fix For: 3.3.3 when we checking the memory usage in ATS, the ram and dir index usage always metter. we should print out the total memory used in dir index after cache init done, or add a stat for it. -- 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-1622) Add an API to query if a response header would be cacheable
[ https://issues.apache.org/jira/browse/TS-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1622: -- Labels: A (was: ) Add an API to query if a response header would be cacheable --- Key: TS-1622 URL: https://issues.apache.org/jira/browse/TS-1622 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Labels: A Fix For: 3.5.0 It would be useful for a plugin to be able to take e.g. a response header (a Hdr object) and ask the HttpSM if this response would be cacheable or not. It should use the same logic (and configs) as the core does normally. -- 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-1612) RAW disk problem with CLFUS and compression enabled
[ https://issues.apache.org/jira/browse/TS-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1612: -- Labels: A (was: ) RAW disk problem with CLFUS and compression enabled --- Key: TS-1612 URL: https://issues.apache.org/jira/browse/TS-1612 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Alex Labels: A When you use RAW disk bigger than 2 x 2TB and you enable CLFUS algorithm along with compression (fastlz i tested with) you get segmentation faults: After enabling the debug mode I got seg fault in /usr/local/var/log/trafficserver/traffic.out NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/bin/traffic_server - STACK TRACE: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2b30fc503cb0] /usr/local/bin/traffic_server(_ZN23RamCacheCLFUSCompressor9mainEventEiP5Event+0xa4)[0x65d104] /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x86)[0x6a45c6] /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x31b)[0x6a4ebb] /usr/local/bin/traffic_server[0x6a33b2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2b30fc4fbe9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b30fe3f5cbd] [E. Mgmt] log == [TrafficManager] using root directory '/usr/local' Tested with 8x2TB disks and 10x3TB disks. Without compression and using LRU algorithm everything works fine. ATS version (Apache Traffic Server - traffic_line - 3.3.1-dev - (build # 11315 on Dec 3 2012 at 15:51:14)) -- 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-1612) RAW disk problem with CLFUS and compression enabled
[ https://issues.apache.org/jira/browse/TS-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1612: -- Fix Version/s: 3.3.4 RAW disk problem with CLFUS and compression enabled --- Key: TS-1612 URL: https://issues.apache.org/jira/browse/TS-1612 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Alex Labels: A Fix For: 3.3.4 When you use RAW disk bigger than 2 x 2TB and you enable CLFUS algorithm along with compression (fastlz i tested with) you get segmentation faults: After enabling the debug mode I got seg fault in /usr/local/var/log/trafficserver/traffic.out NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/bin/traffic_server - STACK TRACE: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2b30fc503cb0] /usr/local/bin/traffic_server(_ZN23RamCacheCLFUSCompressor9mainEventEiP5Event+0xa4)[0x65d104] /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x86)[0x6a45c6] /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x31b)[0x6a4ebb] /usr/local/bin/traffic_server[0x6a33b2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2b30fc4fbe9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b30fe3f5cbd] [E. Mgmt] log == [TrafficManager] using root directory '/usr/local' Tested with 8x2TB disks and 10x3TB disks. Without compression and using LRU algorithm everything works fine. ATS version (Apache Traffic Server - traffic_line - 3.3.1-dev - (build # 11315 on Dec 3 2012 at 15:51:14)) -- 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-1605) crash at mime_parse_int64
[
https://issues.apache.org/jira/browse/TS-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1605:
--
Labels: A crash (was: crash)
crash at mime_parse_int64
-
Key: TS-1605
URL: https://issues.apache.org/jira/browse/TS-1605
Project: Traffic Server
Issue Type: Bug
Components: HTTP, MIME
Reporter: Bin Chen
Assignee: Bin Chen
Labels: A, crash
Fix For: sometime
{code}
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of
bounds,
end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of
bounds,
end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
#1 0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0)
at MIME.cc:1694
#2 0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8,
name=0x2db7388 Age, name_length=3)
at ../../proxy/hdrs/MIME.h:1217
#3 0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at
../../proxy/hdrs/MIME.h:1356
#4 0x005aac0b in HttpTransactHeaders::calculate_document_age
(request_time=1353920547, response_time=1353920547,
base_response=0x2af6853bf5c8, base_response_date=1352509636,
now=1354258269) at HttpTransactHeaders.cc:400
#5 0x00581d73 in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2af5f0a057c0,
client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at
HttpTransactCache.cc:221
#6 0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0,
event=3900, e=0x0) at CacheRead.cc:1019
#7 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
event=3900, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#8 0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0,
event=3900, e=0x2af5f0a05840) at Cache.cc:1952
#9 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0,
event=3900, data=0x2af5f0a05840)
at ../iocore/eventsystem/I_Continuation.h:146
#10 0x006761cc in AIOCallbackInternal::io_complete
(this=0x2af5f0a05840, event=1, data=0x2af79c001420)
at ../../iocore/aio/P_AIO.h:80
#11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840,
event=1, data=0x2af79c001420)
at ../iocore/eventsystem/I_Continuation.h:146
#12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010,
e=0x2af79c001420, calling_code=1)
at UnixEThread.cc:189
#13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at
UnixEThread.cc:240
#14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at
Thread.cc:88
#15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
#16 0x0034bf8e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of
bounds,
end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
(gdb) l
3071bool negative;
3072
3073if (!buf || (buf == end))
3074 return 0;
3075
3076if (is_digit(*buf)) // fast case
3077 {
3078num = *buf++ - '0';
3079while ((buf != end) is_digit(*buf))
3080 num = (num * 10) + (*buf++ - '0');
(gdb) p buf
$1 = 0x3fb Address 0x3fb out of bounds
{code}
--
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-1602) crash at http_hdr_type_get
[
https://issues.apache.org/jira/browse/TS-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1602:
--
Labels: A crash (was: crash)
crash at http_hdr_type_get
--
Key: TS-1602
URL: https://issues.apache.org/jira/browse/TS-1602
Project: Traffic Server
Issue Type: Bug
Components: HTTP, MIME
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: weijin
Labels: A, crash
Fix For: sometime
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
#1 0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at
hdrs/HTTP.h:967
#2 0x0058e6f4 in HttpTransact::HandleCacheOpenRead
(s=0x2ba51d5d2838) at HttpTransact.cc:2046
#3 0x0057af93 in HttpSM::call_transact_and_set_next_state
(this=0x2ba51d5d27d0,
f=0x58e5cc HttpTransact::HandleCacheOpenRead(HttpTransact::State*)) at
HttpSM.cc:6425
#4 0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10)
at HttpSM.cc:2406
#5 0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
#6 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0,
event=1102, data=0x2ba3f8d00c10)
at ../iocore/eventsystem/I_Continuation.h:146
#7 0x00556f02 in HttpCacheSM::state_cache_open_read
(this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
at HttpCacheSM.cc:118
#8 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898,
event=1102, data=0x2ba3f8d00c10)
at ../iocore/eventsystem/I_Continuation.h:146
#9 0x00649779 in CacheContinuation::callback_user
(this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
at ClusterCache.cc:2813
#10 0x00648433 in CacheContinuation::remoteOpEvent
(this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
at ClusterCache.cc:2345
#11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560,
event=1151, data=0x2ba4d149f000)
at ../iocore/eventsystem/I_Continuation.h:146
#12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140,
d=0x2ba570cd4018, l=2776)
at ClusterCache.cc:2088
#13 0x00651747 in ClusterHandler::process_incoming_callouts
(this=0x2ba428881140, m=0x2ba3f92a3c50)
at ClusterHandler.cc:1237
#14 0x006598db in ClusterCalloutContinuation::CalloutHandler
(this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
at ClusterHandlerBase.cc:62
#15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0,
event=2, data=0x2ba314b48ef0)
at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010,
e=0x2ba314b48ef0, calling_code=2)
at UnixEThread.cc:189
#17 0x006dbd79 in PriorityEventQueue::check_ready
(this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
at PQ-List.cc:141
#18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at
UnixEThread.cc:258
#19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
#20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
#21 0x003c084e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
hdrs/HTTP.h:957
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
(gdb) l
952
-*/
953
954 inline HTTPType
955 http_hdr_type_get(HTTPHdrImpl *hh)
956 {
957 return (hh-m_polarity);
958 }
959
960
/*-
961
-*/
(gdb) p hh-m_polarity
Cannot access memory at address 0x2abf98de989c
(gdb) p *hh
Cannot access memory at address 0x2abf98de9898
{code}
--
This message is automatically generated by JIRA.
If you think it was sent
[jira] [Updated] (TS-1592) crash at HttpCompat::parse_tok_list
[
https://issues.apache.org/jira/browse/TS-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1592:
--
Labels: A crash (was: )
crash at HttpCompat::parse_tok_list
---
Key: TS-1592
URL: https://issues.apache.org/jira/browse/TS-1592
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: full_cluster
Reporter: Bin Chen
Assignee: weijin
Labels: A, crash
Fix For: sometime
{code}
Program terminated with signal 11, Segmentation fault.
#0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value
optimized out, string=value optimized out,
len=value optimized out, sep=59 ';') at HttpCompat.cc:77
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value
optimized out, string=value optimized out,
len=value optimized out, sep=59 ';') at HttpCompat.cc:77
#1 0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118,
content_field=value optimized out)
at ../../proxy/hdrs/HttpCompat.h:92
#2 HttpTransactCache::calculate_quality_of_accept_match
(accept_field=0x2b3da50ab118, content_field=value optimized out)
at HttpTransactCache.cc:519
#3 0x00530cf6 in HttpTransactCache::calculate_quality_of_match
(http_config_param=0x2b3da6a074a0,
client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0,
obj_origin_server_response=0x2b3f4748d600)
at HttpTransactCache.cc:327
#4 0x00531a7d in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2b3d94749be0,
client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at
HttpTransactCache.cc:214
#5 0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0,
event=3900, e=0x0) at CacheRead.cc:1019
#6 0x00604348 in handleEvent (this=0x2b3d94749ae0, event=value
optimized out, e=value optimized out)
at ../../iocore/eventsystem/I_Continuation.h:146
#7 CacheVC::handleReadDone (this=0x2b3d94749ae0, event=value optimized
out, e=value optimized out) at Cache.cc:1952
#8 0x00608035 in handleEvent (this=value optimized out,
event=value optimized out, data=value optimized out)
at ../../iocore/eventsystem/I_Continuation.h:146
#9 AIOCallbackInternal::io_complete (this=value optimized out,
event=value optimized out, data=value optimized out)
at ../../iocore/aio/P_AIO.h:80
#10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10,
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1)
at UnixEThread.cc:189
#12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at
UnixEThread.cc:240
#13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
#14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
#15 0x0034bf8e570d in clone () from /lib64/libc.so.6
{code}
--
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-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1547:
--
Labels: A crash (was: )
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 3.3.5
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
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-1527) Coredump: FATAL: HttpTunnel.cc:532: failed assert `active == false`
[
https://issues.apache.org/jira/browse/TS-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1527:
--
Labels: A (was: )
Coredump: FATAL: HttpTunnel.cc:532: failed assert `active == false`
---
Key: TS-1527
URL: https://issues.apache.org/jira/browse/TS-1527
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0
Environment: RHEL 6.2: Linux
2.6.32-220.23.1.el6.YAHOO.20120713.x86_64 #1 SMP x86_64 x86_64 x86_64
GNU/Linux
Reporter: Abhishek Nayani
Labels: A
Fix For: 3.3.5
Attachments: sample.cc
I get the following stact trace:
{noformat}
FATAL: HttpTunnel.cc:532: failed assert `active == false`
/home/y/bin/traffic_server - STACK TRACE:
/home/y/lib64/libtsutil.so.3(ink_fatal+0x88)[0x2b024cb8b868]
/home/y/lib64/libtsutil.so.3(_ink_assert+0x1f)[0x2b024cb89edf]
/home/y/bin/traffic_server(HttpTunnel::deallocate_buffers()+0x924)[0x56adc4]
/home/y/bin/traffic_server(HttpSM::kill_this()+0x6df)[0x52b47f]
/home/y/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x52b9e8]
/home/y/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x696ed4]
/home/y/bin/traffic_server(EThread::execute()+0x633)[0x6979d3]
/home/y/bin/traffic_server[0x695ea2]
/lib64/libpthread.so.0[0x3387207851]
/lib64/libc.so.6(clone+0x6d)[0x3386ee76dd]
{noformat}
--
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-1517) FATAL: InkIOCoreAPI.cc:538: failed assert `sdk_sanity_check_iocore_structure(bufp) == TS_SUCCESS`
[
https://issues.apache.org/jira/browse/TS-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1517:
--
Labels: A (was: )
FATAL: InkIOCoreAPI.cc:538: failed assert
`sdk_sanity_check_iocore_structure(bufp) == TS_SUCCESS`
-
Key: TS-1517
URL: https://issues.apache.org/jira/browse/TS-1517
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Affects Versions: 3.3.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Labels: A
Fix For: 3.3.5
I get some strange assert in the regression testing:
{code}
Regression test(SDK_API_HttpTxnTransform) still in progress
[SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] PASS { ok }
[SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] PASS {
ok }
FATAL: InkIOCoreAPI.cc:538: failed assert
`sdk_sanity_check_iocore_structure(bufp) == TS_SUCCESS`
ats-install/bin/traffic_server - STACK TRACE:
/home/buildslave1/slave1/tserver-trunk-debug/build/ats-install/lib/libtsutil.so.3(ink_fatal_die+0x0)[0x7fad18324e42]
/home/buildslave1/slave1/tserver-trunk-debug/build/ats-install/lib/libtsutil.so.3(ink_get_rand()+0x0)[0x7fad18323d9c]
ats-install/bin/traffic_server(_TSAssert+0x0)[0x4f2063]
ats-install/bin/traffic_server(TSIOBufferCopy+0x3d)[0x50d2d9]
ats-install/bin/traffic_server[0x557222]
ats-install/bin/traffic_server[0x557469]
ats-install/bin/traffic_server(INKVConnInternal::handle_event(int,
void*)+0xae)[0x4f351e]
ats-install/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e9350]
ats-install/bin/traffic_server(EThread::process_event(Event*,
int)+0x125)[0x70a399]
ats-install/bin/traffic_server(EThread::execute()+0xca)[0x70a5f6]
ats-install/bin/traffic_server[0x708c2a]
/lib/libpthread.so.0(+0x69ca)[0x7fad180f09ca]
/lib/libc.so.6(clone+0x6d)[0x7fad15f48cdd]
process killed by signal 6
{code}
--
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-1507) debug mode crash with bogus HTTP version
[ https://issues.apache.org/jira/browse/TS-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1507: -- Labels: A codenomicon crash (was: codenomicon crash) debug mode crash with bogus HTTP version Key: TS-1507 URL: https://issues.apache.org/jira/browse/TS-1507 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: James Peach Priority: Minor Labels: A, codenomicon, crash Fix For: 3.3.3 Codenomicon test case #424 This test sends a HTTP request beginning with GET /424 HTTP/1.31122234\r\n. If ATS is built in debug mode, it triggers the assertion in http_hdr_version_to_string(). FATAL: HTTP.cc:387: failed assert `HTTP_MINOR(version) 10` /opt/ats/bin/traffic_server - STACK TRACE: 0 libtsutil.3.dylib 0x0001054f7af9 ink_fatal + 345 1 libtsutil.3.dylib 0x0001054f6a72 _ink_assert + 66 2 traffic_server 0x000104b6a21d _ZL26http_hdr_version_to_stringiPc + 157 3 traffic_server 0x000104b6a4f4 _Z14http_hdr_printP7HdrHeapP11HTTPHdrImplPciPiS4_ + 596 4 traffic_server 0x0001049f286d _ZN7HTTPHdr5printEPciPiS1_ + 141 5 traffic_server 0x000104ad1c5f _ZN12HttpTransact13HandleRequestEPNS_5StateE + 1679 6 traffic_server 0x000104aa9b30 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 144 7 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 8 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 9 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 10 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 11 traffic_server 0x000104ac2a47 _ZN6HttpSM14set_next_stateEv + 455 12 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 13 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 14 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 15 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 16 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 17 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 18 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 19 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 20 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 21 traffic_server 0x000104aa98ee _ZN6HttpSM32state_read_client_request_headerEiPv + 2638 22 traffic_server 0x000104aa7d11 _ZN6HttpSM12main_handlerEiPv + 833 This crash only happens in debug mode, but we should verify that the release execution path is safe. The HTTP_MAJOR and HTTP_MINOR macros can result in there being high ascii characters set in the char buffer. -- 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] [Commented] (TS-1507) debug mode crash with bogus HTTP version
[ https://issues.apache.org/jira/browse/TS-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648966#comment-13648966 ] Leif Hedstrom commented on TS-1507: --- I was unable to reproduce this, James? debug mode crash with bogus HTTP version Key: TS-1507 URL: https://issues.apache.org/jira/browse/TS-1507 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: James Peach Priority: Minor Labels: A, codenomicon, crash Fix For: 3.3.3 Codenomicon test case #424 This test sends a HTTP request beginning with GET /424 HTTP/1.31122234\r\n. If ATS is built in debug mode, it triggers the assertion in http_hdr_version_to_string(). FATAL: HTTP.cc:387: failed assert `HTTP_MINOR(version) 10` /opt/ats/bin/traffic_server - STACK TRACE: 0 libtsutil.3.dylib 0x0001054f7af9 ink_fatal + 345 1 libtsutil.3.dylib 0x0001054f6a72 _ink_assert + 66 2 traffic_server 0x000104b6a21d _ZL26http_hdr_version_to_stringiPc + 157 3 traffic_server 0x000104b6a4f4 _Z14http_hdr_printP7HdrHeapP11HTTPHdrImplPciPiS4_ + 596 4 traffic_server 0x0001049f286d _ZN7HTTPHdr5printEPciPiS1_ + 141 5 traffic_server 0x000104ad1c5f _ZN12HttpTransact13HandleRequestEPNS_5StateE + 1679 6 traffic_server 0x000104aa9b30 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 144 7 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 8 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 9 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 10 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 11 traffic_server 0x000104ac2a47 _ZN6HttpSM14set_next_stateEv + 455 12 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 13 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 14 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 15 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 16 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 17 traffic_server 0x000104aae186 _ZN6HttpSM17handle_api_returnEv + 326 18 traffic_server 0x000104ac578f _ZN6HttpSM14do_api_calloutEv + 63 19 traffic_server 0x000104ac28f0 _ZN6HttpSM14set_next_stateEv + 112 20 traffic_server 0x000104aa9ca1 _ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE + 513 21 traffic_server 0x000104aa98ee _ZN6HttpSM32state_read_client_request_headerEiPv + 2638 22 traffic_server 0x000104aa7d11 _ZN6HttpSM12main_handlerEiPv + 833 This crash only happens in debug mode, but we should verify that the release execution path is safe. The HTTP_MAJOR and HTTP_MINOR macros can result in there being high ascii characters set in the char buffer. -- 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-1495) dest_ip rule in cache.config doesnot work
[ https://issues.apache.org/jira/browse/TS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1495: -- Labels: A (was: ) dest_ip rule in cache.config doesnot work - Key: TS-1495 URL: https://issues.apache.org/jira/browse/TS-1495 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Affects Versions: 3.2.0, 3.0.5 Environment: FreeBSD 8.2-RELEASE amd64 Reporter: wang jin Labels: A Fix For: 3.3.5 In HttpTransact::HandleRequest, update_cache_control_information_from_config is called before dns lookup, so dest_ip rule in cache.config nerver matched. -- 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-1493) TShtrime() returning negative value
[ https://issues.apache.org/jira/browse/TS-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1493: -- Labels: A (was: ) TShtrime() returning negative value --- Key: TS-1493 URL: https://issues.apache.org/jira/browse/TS-1493 Project: Traffic Server Issue Type: Bug Components: Core Reporter: bianca cooper Labels: A Fix For: 3.3.5 calling TShrtime function after TS_EVENT_HTTP_TXN_CLOSE (and before reenable the transaction) sometimes returns negative number calling the same function in other places in code always returns positive number. -- 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-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1492: -- Labels: A (was: ) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Labels: A Fix For: 3.3.3 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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-1487) the ordering of plugin_init and init_HttpProxyServer cause crashed TS to core endlessly
[ https://issues.apache.org/jira/browse/TS-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1487: -- Labels: A (was: ) the ordering of plugin_init and init_HttpProxyServer cause crashed TS to core endlessly --- Key: TS-1487 URL: https://issues.apache.org/jira/browse/TS-1487 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.0 Environment: Linux RHEL6.2 Reporter: Aidan McGurn Assignee: Alan M. Carroll Priority: Critical Labels: A Fix For: 3.3.5 Attachments: INTD-529-RespawnCrash.patch, INTD-529-RespawnCrash.patch We've had a serious issue whereby the TS when it crashes re-spawns/cores continuously when its tries to re-start under load. I traced the issue to SNMP research library (a third party lib)- They use selects and what happens is the file descriptor number spikes under load after the crash as all the sockets get opened at once - this causes buffer overflow in the select (which their library is full of) as the fd allocated to the FD_SET is much bigger than the FD_SETSIZE of 1024 (which was a bitch to track down as the stack was corrupted and gdb therefore useless). Tracing why this happened on 3.2.0 and not 3.0.2, I find the sequence of the plugin_init has changed - On 3.0.2 the sequence was in effect 1. plugin_init and then 2. init_HttpProxyServer. Whereas this has mysteriously been reversed on 3.2.0. In order to get our system to work in this crash case , I've patched ATS to flip them around like in 3.0.2. i'll attach the patch we propose we need to use to get around this. Is this actually a bug then waiting to happen in other systems - Or was there a reason to change this sequence? -- 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] [Commented] (TS-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648969#comment-13648969 ] Leif Hedstrom commented on TS-1344: --- Patch?? url.cc doesn't terminate path correctly for malformed query strings --- Key: TS-1344 URL: https://issues.apache.org/jira/browse/TS-1344 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.0, 3.0.5 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.3 Malformed query strings can cause ATS to incorrectly take the query string as the path. -- 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-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1344: -- Labels: A (was: ) url.cc doesn't terminate path correctly for malformed query strings --- Key: TS-1344 URL: https://issues.apache.org/jira/browse/TS-1344 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.0, 3.0.5 Reporter: Brian Geffon Assignee: Brian Geffon Labels: A Fix For: 3.3.3 Malformed query strings can cause ATS to incorrectly take the query string as the path. -- 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-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1336:
--
Labels: A (was: )
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
10705 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 21]
1 root 20 0 24328 2256 1344 S0 0.0 0:02.53 init
2 root 20 0 000 S0 0.0 0:00.05 kthreadd
stracing the ET_TASK threads showed a repeating set of calls to futex:
futex(0x946ca4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 255405471,
{1341604150, 0}, ) = -1 ETIMEDOUT (Connection timed out)
futex(0x946ce0, FUTEX_WAKE_PRIVATE, 1) = 0
I installed the symbols and interrupted the process with GDB... The ET_TASK
functions were generally looked
[jira] [Updated] (TS-1273) Crash report: selectively deleting instances of mime header field which has duplicates causes core dump
[
https://issues.apache.org/jira/browse/TS-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1273:
--
Labels: A (was: )
Crash report: selectively deleting instances of mime header field which has
duplicates causes core dump
---
Key: TS-1273
URL: https://issues.apache.org/jira/browse/TS-1273
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 3.0.4
Reporter: Manjesh Nilange
Labels: A
Fix For: 3.3.4
Try header plugin
#include ts/ts.h
static int deleteLastCookie(TSCont, TSEvent, void *);
void TSPluginInit(int argc, const char *argv[])
{
TSCont globalCont = TSContCreate(deleteLastCookie, 0);
TSHttpHookAdd(TS_HTTP_SEND_RESPONSE_HDR_HOOK, globalCont);
}
static int deleteLastCookie(TSCont cont, TSEvent event, void *edata)
{
TSHttpTxn txn = static_castTSHttpTxn(edata);
TSMBuffer hdrBuf;
TSMLoc hdrLoc;
if (TSHttpTxnClientRespGet(txn, hdrBuf, hdrLoc) != TS_SUCCESS)
{
TSError(Could not get client response object);
TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
return 0;
}
TSMLoc fieldLoc = TSMimeHdrFieldFind(hdrBuf, hdrLoc,
TS_MIME_FIELD_SET_COOKIE, -1);
while (fieldLoc)
{
TSMLoc nextFieldLoc = TSMimeHdrFieldNextDup(hdrBuf, hdrLoc, fieldLoc);
if (!nextFieldLoc)
{
TSMimeHdrFieldRemove(hdrBuf, hdrLoc, fieldLoc);
TSMimeHdrFieldDestroy(hdrBuf, hdrLoc, fieldLoc);
}
TSHandleMLocRelease(hdrBuf, hdrLoc, fieldLoc);
fieldLoc = nextFieldLoc;
}
TSHandleMLocRelease(hdrBuf, 0, hdrLoc);
TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
return 0;
}
with OS script
?php
// bool setcookie ( string $name [, string $value [, int $expire = 0 [,
string $path [, string $domain [, bool $secure = false [, bool $httponly =
false ]] )
setcookie('foo', 'bar1');
setcookie('foo', 'bar2', time() + 1000, /, www.test.com, false, false);
setcookie('foo2', 'bar4', time() + 1000, /, .test.com, false, false);
setcookie('foo', 'bar3', time() + 1000, /, .www.test.com, false, false);
setcookie('foo2', 'bar4', time() + 1000, /, .test.com, false, false);
setcookie('foo2', 'bar5', time() + 1000, /, test.com, false, false);
setcookie('foo3', 'bar6');
setcookie('foo3', 'bar6', time() + 1000, /, www.test.com, true, false);
?
html
body
This is a test
/body
/html
And there's a core consistently with this stack trace
(gdb) bt
#0 mime_hdr_field_detach (mh=0x7403f8c8, field=0x7403fa58,
detach_all_dups=false) at MIME.cc:1640
#1 0x005a0237 in mime_hdr_field_delete (heap=0x7403f810,
mh=0x7403f8c8, field=0x7403fa58,
delete_all_dups=value optimized out) at MIME.cc:1688
#2 0x004a6a51 in TSMimeHdrFieldDestroy (bufp=0x7fffec251ab8,
mh_mloc=0x7403f898,
field_mloc=0x7fffdc0258d0) at InkAPI.cc:2719
#3 0x7fffed56ba73 in deleteLastCookie(tsapi_cont*, TSEvent, void*) ()
from /home/mnilange/temp/mime-field-crash.so
#4 0x005137a5 in HttpSM::state_api_callout (this=0x7fffec2511c0,
event=value optimized out,
data=value optimized out) at HttpSM.cc:1374
#5 0x0051bc6c in HttpSM::set_next_state (this=0x7fffec2511c0) at
HttpSM.cc:6534
#6 0x0050912f in HttpSM::call_transact_and_set_next_state
(this=0x7fffec2511c0, f=value optimized out)
at HttpSM.cc:6329
#7 0x005134f8 in HttpSM::state_api_callout (this=0x7fffec2511c0,
event=0, data=0x0) at HttpSM.cc:1448
#8 0x00514d38 in do_api_callout (this=0x7fffec2511c0, event=100,
data=0x7fffe401db80) at HttpSM.cc:497
#9 HttpSM::state_read_server_response_header (this=0x7fffec2511c0,
event=100, data=0x7fffe401db80)
at HttpSM.cc:1826
#10 0x00515cc8 in HttpSM::main_handler (this=0x7fffec2511c0,
event=100, data=0x7fffe401db80)
at HttpSM.cc:2439
#11 0x006346bb in handleEvent (event=value optimized out,
vc=0x7fffe401d9c0)
at ../../iocore/eventsystem/I_Continuation.h:146
#12 read_signal_and_update (event=value optimized out, vc=0x7fffe401d9c0)
at UnixNetVConnection.cc:138
#13 0x006371f1 in read_from_net (nh=0x76630628,
vc=0x7fffe401d9c0, thread=value optimized out)
at UnixNetVConnection.cc:320
#14 0x00630952 in NetHandler::mainNetEvent (this=0x76630628,
event=value optimized out,
e=value optimized out) at UnixNet.cc:389
#15 0x00656d24 in handleEvent (this=0x7662f010, e=0xfc1190,
calling_code=5) at I_Continuation.h:146
#16 EThread::process_event (this=0x7662f010, e=0xfc1190, calling_code=5)
at UnixEThread.cc:140
#17 0x006576b3 in EThread::execute (this=0x7662f010) at
UnixEThread.cc:262
#18 0x00655f82 in
[jira] [Updated] (TS-1219) Crash report: ink_freelist_new causing core dumps
[
https://issues.apache.org/jira/browse/TS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1219:
--
Labels: A crash (was: )
Crash report: ink_freelist_new causing core dumps
-
Key: TS-1219
URL: https://issues.apache.org/jira/browse/TS-1219
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.4, 3.0.2
Reporter: Manjesh Nilange
Labels: A, crash
Fix For: 3.3.4
Our TS based production boxes are seeing a couple of crashes per day with
stack traces ending in
#3 0x004c85ea in signal_handler (sig=11) at signals.cc:225
#4 signal handler called
#5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
ink_queue.cc:326
#6 0x00331240d47a in alloc_void (this=0x7fff80173cd8, size=511,
alignment=1) at Allocator.h:208
#7 blk_alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:45
#8 Arena::alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:118
#9 0x00569b93 in str_alloc (arena=value optimized out,
url=0x31be6a8 *...,
len_in=value optimized out, len_out=0x7fff80173d20) at
../../lib/ts/Arena.h:123
#10 LogUtils::escapify_url (arena=value optimized out,
url=0x31be6a8 *...,
len_in=value optimized out, len_out=0x7fff80173d20) at LogUtils.cc:392
#11 0x005482e9 in LogAccessHttp::init (this=0x7fff80173cc0) at
LogAccessHttp.cc:98
#12 0x0054b436 in Log::access (lad=0x7fff80173cc0) at Log.cc:1055
#13 0x004f3085 in HttpSM::update_stats (this=0x2ae5480651e0) at
HttpSM.cc:6044
#14 0x004f8918 in HttpSM::kill_this (this=0x2ae5480651e0) at
HttpSM.cc:6005
#15 0x004f8c08 in HttpSM::main_handler (this=0x2ae5480651e0,
event=2301, data=0x2ae548066ec8)
at HttpSM.cc:2452
The URL was valid, I just anonymized it. This is our environment
$ uname -a
Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
x86_64 x86_64 x86_64 GNU/Linux
$ file /usr/bin/traffic_server
/usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
There doesn't seem to be more useful information in the frame:
(gdb) f 5
#5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at
ink_queue.cc:326
326 FREELIST_VERSION(item) + 1);
(gdb) list
321 fastalloc_mem_in_use += f-chunk_size * f-type_size;
322 #endif
323
324 } else {
325 SET_FREELIST_POINTER_VERSION(next,
*ADDRESS_OF_NEXT(TO_PTR(FREELIST_POINTER(item)), f-offset),
326 FREELIST_VERSION(item) + 1);
327 #if !defined(INK_USE_MUTEX_FOR_FREELISTS)
328 result = ink_atomic_cas64((int64_t *) f-head.data, item.data,
next.data);
329 #else
330 f-head.data = next.data;
(gdb) p next
$2 = value optimized out
(gdb) p f
$3 = (InkFreeList *) 0x3312629ce0
(gdb) p *f
$4 = {head = {data = -8941773651046140890}, name = 0x331241e92f ArenaBlock,
type_size = 1024, chunk_size = 128,
count = 519, allocated = 1536, offset = 0, alignment = 8, allocated_base =
0, count_base = 0}
(gdb) p item
$5 = {data = -8953314125091277786}
--
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-1204) Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
[
https://issues.apache.org/jira/browse/TS-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1204:
--
Labels: A crash (was: )
Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic ==
HTTP_SM_MAGIC_ALIVE`
---
Key: TS-1204
URL: https://issues.apache.org/jira/browse/TS-1204
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: git master Sat Apr 7 03:29:50 2012. forwarding proxy on
centos 6.2 x86_64, with cacheurl plugin
Reporter: Zhao Yongming
Labels: A, crash
Fix For: 3.3.4
{code}
FATAL: HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ddba14368]
/usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0x1f)[0x3ddba12c6f]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x2e)[0x5163fe]
/usr/bin/traffic_server[0x628b4b]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x353)[0x62c7a3]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x624cce]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6494f4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x649e83]
/usr/bin/traffic_server[0x648832]
/lib64/libpthread.so.0[0x380dc077f1]
/lib64/libc.so.6(clone+0x6d)[0x380d0e592d]
{code}
--
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-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1201:
--
Labels: A crash (was: )
Crash report: hostdb multicache, double free
Key: TS-1201
URL: https://issues.apache.org/jira/browse/TS-1201
Project: Traffic Server
Issue Type: Bug
Components: DNS
Reporter: Zhao Yongming
Labels: A, crash
Fix For: 3.3.3
{code}
*** glibc detected *** /usr/bin/traffic_server: corrupted double-linked list:
0x1fe10ef0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3db2072555]
/lib64/libc.so.6(cfree+0x4b)[0x3db20728bb]
/usr/bin/traffic_server(MultiCacheSync::mcEvent(int, Event*)+0xa4)[0x5dae04]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x22f)[0x691c8f]
/usr/bin/traffic_server(EThread::execute()+0x6a1)[0x692681]
/usr/bin/traffic_server[0x69115e]
/lib64/libpthread.so.0[0x3db280673d]
/lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
=== Memory map:
{code}
--
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-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Labels: A (was: ) RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Phil Sorber Labels: A Fix For: 3.3.4 Attachments: SSL_CTX_set_tlsext_ticket_key_cb.txt For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1118: -- Labels: A (was: ) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. -- Key: TS-1118 URL: https://issues.apache.org/jira/browse/TS-1118 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.4 I'd like to make the core simpler, and more efficient, dealing with the cache keys. We have APIs today to modify the cache URL (lookup_url), but it's incredibly inefficient. I'll post more details on my ideas here when I have it all written down. -- 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-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1033: -- Labels: A (was: ) Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.4 And of course various other places (including InkAPI). -- 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-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-974: - Labels: A (was: ) TS should have a mode to hold partial objects in cache -- Key: TS-974 URL: https://issues.apache.org/jira/browse/TS-974 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.1 Reporter: William Bardwell Labels: A Fix For: sometime For ATS to do an excelent job caching large files like video it would need to be able to hold partial objects for a large file. This could be done in a plugin or in the core. This would need to be integrated with the Range handling code to serve requests out of the partial objects and to get more parts of a file to satisfy a Range request. An intermediate step (also do-able in the core or in a plugin) would be to have some settings to let the Range handling code be able to trigger a full file download either asynchronously when a Range response indicates that the file isn't larger than some threshold, or synchronously when a Range request could reasonably be answered quickly from a full request. (Right now Range requests are tunneled if there is not full cached content as far as I can tell.) -- 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-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-966: - Labels: A (was: ) cache.config dest_domain= dest_hostname= dest_ip= do not match anything --- Key: TS-966 URL: https://issues.apache.org/jira/browse/TS-966 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Labels: A Fix For: 3.3.4 Caching policies are not applied when using these options to match targets. It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- 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-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-965: - Labels: A (was: ) cache.config can't deal with both revalidate= and ttl-in-cache= specified - Key: TS-965 URL: https://issues.apache.org/jira/browse/TS-965 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Labels: A Fix For: 3.3.4 If both of these options are specified (with the same time?), nothing is cached at all. -- 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-777) Increasing logbuffer size makes us drop log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-777: - Labels: A (was: ) Increasing logbuffer size makes us drop log entries - Key: TS-777 URL: https://issues.apache.org/jira/browse/TS-777 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 2.1.8 Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.5.0 Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB makes us start losing log entries. This is bad, since increasing this setting could be a way to increase performance for busy systems. I've for now set the defaults to 16KB, which seems to be stable. -- 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-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-794:
-
Labels: A (was: )
ssl session reuse can not pass sslswamp testing
---
Key: TS-794
URL: https://issues.apache.org/jira/browse/TS-794
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.8
Environment: sslv3 tlsv1
Reporter: Zhao Yongming
Labels: A
Fix For: 3.3.4
When I testing from the patches from qianshi, for TS-718, the ssl session
resumption looks perfect, but still can not pass the sslswamp testing, it
looks like the second and later request will not be handled from the https
connection. it may be a issue for https handler, here is some information
testing from sslswamp:
{code}
[root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
-count 4 -session srrr -update 10 -request GET
https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
HTTP/1.0\r\n\r\n -session_ids -nologo -expect 64000 -sslmeth tlsv1
No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
no client cert provided, continuing anyway.
Certificate verification failed, probably a self-signed server cert *or*
the signing CA cert is not trusted by us (hint: use '-CAfile').
This message will only be printed once
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
ops/sec
{code}
the log from traffic.out:
{code}
[May 20 18:30:59.544] Manager {140339380279072} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '10'
[May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
Server Process born
[May 20 18:31:00.564] {47816222021376} STATUS: opened
/var/log/trafficserver/diags.log
[May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
[May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
[SSLNetProcessor::initSSLServerCTX] set the callback for external session
caching.
[May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
logging_mode = 3
[May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
[May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
[ssl_callback_NewSessionCacheEntry] store id
[D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
into cache.
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=82
SSL Read
GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=82
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4014
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[jira] [Updated] (TS-754) Reduce memory usage on idle connections
[ https://issues.apache.org/jira/browse/TS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-754: - Labels: A (was: ) Reduce memory usage on idle connections --- Key: TS-754 URL: https://issues.apache.org/jira/browse/TS-754 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Labels: A Fix For: 3.5.0 We should examine what memory (if any) can be returned to class allocators / freelist when a connection is idle (in keep-alive). Right now, I suspect we hold on to more memory than is necessary, which limits the number of KA connections a server can have. -- 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-1825) TSPortDescriptorAccept() does not use its TSCont contp parameter
[
https://issues.apache.org/jira/browse/TS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1825:
Yeh it's mine. Not an 'A' imho.
TSPortDescriptorAccept() does not use its TSCont contp parameter
Key: TS-1825
URL: https://issues.apache.org/jira/browse/TS-1825
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Leif Hedstrom
Priority: Blocker
Fix For: 3.3.3
This looks odd:
{code}
TSReturnCode
TSPortDescriptorAccept(TSPortDescriptor descp, TSCont contp)
{
HttpProxyPort * port = (HttpProxyPort *)descp;
return start_HttpProxyPort(*port, 0 /* nthreads */) ? TS_SUCCESS : TS_ERROR;
}
{code}
Assuming that (as per the IRC discussions) TSPortDescriptAccept() should work
something similar to TSNetAccept, shouldn't it be using the contp for
callbacks?
--
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] [Commented] (TS-1779) Crash using SNI and ssl_ca_name
[ https://issues.apache.org/jira/browse/TS-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648980#comment-13648980 ] James Peach commented on TS-1779: - I still dom't know how to reproduce this, and I don't have a stack trace. Crash using SNI and ssl_ca_name --- Key: TS-1779 URL: https://issues.apache.org/jira/browse/TS-1779 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Rodney Assignee: James Peach Labels: A Fix For: 3.3.3 When I add 'ssl_ca_name' to include a chain cert CA the traffic server fails to start with a core dump. It seems to be okay if I just have one entry in 'ssl_multicert.config' file but as soon as I use SNI the traffic server will not start with a core dump. This witnessed on 3.2.0 and currently 3.2.4 with Debian Squeeze. Example entries: ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt ssl_cert_name=my2.crt ssl_key_name=my2.key ssl_ca_name=my2CA.crt #Default dest_ip=* ssl_cert_name=my1.crt ssl_key_name=my1.key ssl_ca_name=my1CA.crt -- 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] [Commented] (TS-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648981#comment-13648981 ] James Peach commented on TS-1344: - Any examples of malformed query strings which exhibit this behaviour? url.cc doesn't terminate path correctly for malformed query strings --- Key: TS-1344 URL: https://issues.apache.org/jira/browse/TS-1344 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.0, 3.0.5 Reporter: Brian Geffon Assignee: Brian Geffon Labels: A Fix For: 3.3.3 Malformed query strings can cause ATS to incorrectly take the query string as the path. -- 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] [Resolved] (TS-449) Split RecordsConfig.cc into modules
[ https://issues.apache.org/jira/browse/TS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-449. -- Resolution: Won't Fix Split RecordsConfig.cc into modules - Key: TS-449 URL: https://issues.apache.org/jira/browse/TS-449 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Priority: Minor Fix For: sometime To modularize configurations, we ought to split proxy/mgmt2/RecordsConfig.cc into each module. This is/was partially done, albeit very incomplete, for iocore. What I'd suggest we do is something like 1) Create a RecordsConfig.cc for each module that has configurations. This should allow for the same capabilities as the old RecordsConfig.cc, and should use the same APIs / format for all modules. 2) Once migrated over to a module specific RecordsConfig.cc, eliminate it from the old proxy/mgmt2/RecordsConfig.cc. This allows for per-module migration over to the new layout. -- 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-449) Split RecordsConfig.cc into modules
[ https://issues.apache.org/jira/browse/TS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-449: - Fix Version/s: (was: sometime) Split RecordsConfig.cc into modules - Key: TS-449 URL: https://issues.apache.org/jira/browse/TS-449 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Priority: Minor To modularize configurations, we ought to split proxy/mgmt2/RecordsConfig.cc into each module. This is/was partially done, albeit very incomplete, for iocore. What I'd suggest we do is something like 1) Create a RecordsConfig.cc for each module that has configurations. This should allow for the same capabilities as the old RecordsConfig.cc, and should use the same APIs / format for all modules. 2) Once migrated over to a module specific RecordsConfig.cc, eliminate it from the old proxy/mgmt2/RecordsConfig.cc. This allows for per-module migration over to the new layout. -- 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-683) range_offset_limit behaviour the same as squid
[ https://issues.apache.org/jira/browse/TS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-683: - Labels: A (was: ) range_offset_limit behaviour the same as squid -- Key: TS-683 URL: https://issues.apache.org/jira/browse/TS-683 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Kingsley Foreman Priority: Minor Labels: A Fix For: sometime Feature request, I would like to have the squid range_offset_limit behaviour added to TS, The range_offset_limit option allows a 206 connection to be made to a server, if the start range of the request is less then the ammount set in the config, eg 100k and the request is not in cache the TS server will make a 200 connection request to the backend server and treat it like a 200 download getting the entire file (while of course still sending the correct range to the client). -- 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-380) Remaining 64-bit conversion
[ https://issues.apache.org/jira/browse/TS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-380: - Labels: A (was: ) Remaining 64-bit conversion - Key: TS-380 URL: https://issues.apache.org/jira/browse/TS-380 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Critical Labels: A Fix For: 3.5.1 There are a few areas which still needs to some 'lovin for true 64-bit support. In particular, I know of an area in logging, related to log filtering, that needs to be modified. -- 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-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1510: -- Labels: A (was: ) Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Labels: A Fix For: 3.3.5 With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1330:
--
Priority: Critical (was: Major)
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Critical
Labels: A, crash
Fix For: 3.3.4
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
NOTE: Traffic Server received Sig 11: Segmentation fault
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x3b54e0f4a0]
/lib64/libpthread.so.0[0x3b54e0f4a0]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x6736a1]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
/home/y/bin/traffic_server[0x672f81]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66df96]
[jira] [Assigned] (TS-1825) TSPortDescriptorAccept() does not use its TSCont contp parameter
[
https://issues.apache.org/jira/browse/TS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1825:
-
Assignee: James Peach
TSPortDescriptorAccept() does not use its TSCont contp parameter
Key: TS-1825
URL: https://issues.apache.org/jira/browse/TS-1825
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Leif Hedstrom
Assignee: James Peach
Priority: Blocker
Fix For: 3.3.3
This looks odd:
{code}
TSReturnCode
TSPortDescriptorAccept(TSPortDescriptor descp, TSCont contp)
{
HttpProxyPort * port = (HttpProxyPort *)descp;
return start_HttpProxyPort(*port, 0 /* nthreads */) ? TS_SUCCESS : TS_ERROR;
}
{code}
Assuming that (as per the IRC discussions) TSPortDescriptAccept() should work
something similar to TSNetAccept, shouldn't it be using the contp for
callbacks?
--
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-1660) Host field should not has c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1660: -- Labels: A (was: ) Host field should not has c style terminator - Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Labels: A Fix For: 3.3.3 Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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-1703) simultaneous cache entry refresh has performance issues
[ https://issues.apache.org/jira/browse/TS-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1703: -- Labels: A (was: ) simultaneous cache entry refresh has performance issues --- Key: TS-1703 URL: https://issues.apache.org/jira/browse/TS-1703 Project: Traffic Server Issue Type: Improvement Components: Cache, HTTP Reporter: William Bardwell Labels: A Fix For: 3.5.0 If you use enable_read_while_writer off, any requests after the first that occur while a cache entry needs to be refreshed end up going to the origin (internally the second request treats things as a cache miss.) If you use enable_read_while_writer on, then a lot of requests are answered from a single refresh, but occasionally some will have trouble getting some sort of write lock and will still fail, and will go to the origin when they shouldn't. (And they will trigger TS-1702 until that is fixed.) I would argue that for both lock failure cases, instead of just ignoring the cache entry, it should be used in a read-only mode and should still do a refresh, and just use the entry if a 304 is received or use the new contents (but don't save them, since it doesn't have a write lock) if it does not get a 304. -- 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-1141) Server intercept performance problems.
[ https://issues.apache.org/jira/browse/TS-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1141: -- Summary: Server intercept performance problems. (was: Server intercerpt performance problems.) Server intercept performance problems. -- Key: TS-1141 URL: https://issues.apache.org/jira/browse/TS-1141 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: 3.5.0 It seems server intercept plugins are fairly expensive. A very simple one, serving a few bytes out of RAM, can only do in the order of 20K QPS, whereas the same server serving out of RAM cache do wo 175k QPS. I know there will be overhead in plugin APIs, but almost 10x seems quite high. -- 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] [Resolved] (TS-1874) Server Intercept is slower than it ought to be
[ https://issues.apache.org/jira/browse/TS-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1874. --- Resolution: Duplicate Duplicate of TS-1141. Server Intercept is slower than it ought to be -- Key: TS-1874 URL: https://issues.apache.org/jira/browse/TS-1874 Project: Traffic Server Issue Type: Bug Components: Performance Reporter: Leif Hedstrom Even with a Content-Length header in the response from a server intercept (see TS-1381), the performance is sub-par. On my box, it's about 6x slower than serving the same content out of RAM cache. I'd expect the server intercept to be as fast, or faster. -- 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-1161) unsafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1161: -- Fix Version/s: (was: 3.5.0) unsafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- 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] [Resolved] (TS-1161) unsafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1161. --- Resolution: Duplicate Marking as duplicate of TS-667 unsafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- 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-667) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode.
[ https://issues.apache.org/jira/browse/TS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-667: - Labels: A features (was: features) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode. -- Key: TS-667 URL: https://issues.apache.org/jira/browse/TS-667 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration Reporter: David Robinson Priority: Minor Labels: A, features Fix For: 3.3.5 When disk devices are configured in storage.config for RAW mode they are automatically initialized when traffic server first starts up. If disk device names change later due to adding/removing disks or kernel changes trafficserver will overwrite disks that the user may not want to be cache disks. This leads to data loss on the affected disks. Maybe a feature could be added similar to squid's -z where cache disks must be explicitly initialized before they can be used. Or a configuration variable that changes trafficserver's initialization behavior. (6:49:06 PM) zwoop: so, maybe have a few settings for the config (6:49:06 PM) zwoop: 0 - Let it reinitialize cache as it likes (6:49:06 PM) zwoop: 1 - Only initialize cache explicitly (6:49:06 PM) zwoop: 2 - Only initialize cache explicitly, and refuse to start up if we detect a cache disk with bad header -- 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] [Commented] (TS-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648989#comment-13648989 ] James Peach commented on TS-1118: - https://cwiki.apache.org/confluence/display/TS/Cleanup+of+Cache+URLs Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. -- Key: TS-1118 URL: https://issues.apache.org/jira/browse/TS-1118 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 3.3.4 I'd like to make the core simpler, and more efficient, dealing with the cache keys. We have APIs today to modify the cache URL (lookup_url), but it's incredibly inefficient. I'll post more details on my ideas here when I have it all written down. -- 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
