[jira] [Updated] (TS-1472) 3.2.x - RAM cache stats looks wrong
[
https://issues.apache.org/jira/browse/TS-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1472:
---
Fix Version/s: (was: 3.2.3)
3.2.4
3.2.x - RAM cache stats looks wrong
---
Key: TS-1472
URL: https://issues.apache.org/jira/browse/TS-1472
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Leif Hedstrom
Assignee: Igor Galić
Fix For: 3.2.4
E.g.
{code}
proxy.process.cache.volume_0.bytes_used=73639936
proxy.process.cache.volume_0.bytes_total=299840634880
proxy.process.cache.volume_0.ram_cache.total_bytes=536870912
proxy.process.cache.volume_0.ram_cache.bytes_used=279175598080
proxy.process.cache.volume_0.ram_cache.hits=254
proxy.process.cache.volume_0.ram_cache.misses=179
{code}
I'm obviously not using 279GB of RAM cache (I wish I did). Or
{code}
proxy.process.cache.ram_cache.total_bytes=536870912
proxy.process.cache.ram_cache.bytes_used=279175598080
{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-1524) 3.2.x - fix signed/unsigned compilation issues in Vec
[ https://issues.apache.org/jira/browse/TS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1524: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - fix signed/unsigned compilation issues in Vec - Key: TS-1524 URL: https://issues.apache.org/jira/browse/TS-1524 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Core Affects Versions: 3.3.0 Reporter: James Peach Assignee: James Peach Fix For: 3.2.4 cc1plus: warnings being treated as errors Vec.h: In function ‘int main(int, char**)’: Vec.h:616: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Vec.h:616: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Alan says: It is a result of optimization in the call sequence in test_append that calls str.append(value,len) which calls reserve(length() + count). length() is inlined to a reference to n so the argument is treated as n+count. This yields, in the reserve method at the bad line if (n+count = n) which leads to the warning/error you see. I don't see how to disable the error, 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-1522) 3.2.x - improve Cluster purge delete object (Miss) performance
[ https://issues.apache.org/jira/browse/TS-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1522: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - improve Cluster purge delete object (Miss) performance - Key: TS-1522 URL: https://issues.apache.org/jira/browse/TS-1522 Project: Traffic Server Issue Type: Improvement Components: Clustering, HTTP Affects Versions: 3.3.0, 3.2.0 Environment: LOCAL proxy.local.cluster.type INT 1 Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.2.4 when purging a remote object, and the object is missing from the remote cache, the performance(rt) is very bad due to the missing read will need to handle open_write in the cluster read. -- 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-1474) 3.2.x - turn off SSL compression by default
[ https://issues.apache.org/jira/browse/TS-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1474: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - turn off SSL compression by default --- Key: TS-1474 URL: https://issues.apache.org/jira/browse/TS-1474 Project: Traffic Server Issue Type: Bug Affects Versions: 3.3.0, 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.2.4 Attachments: ssl_no_compression.patch -- 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-1491) Browser always prompts for authentication (NTLM)
[ https://issues.apache.org/jira/browse/TS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1491: --- Fix Version/s: (was: 3.2.3) 3.2.4 Browser always prompts for authentication (NTLM) Key: TS-1491 URL: https://issues.apache.org/jira/browse/TS-1491 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.2.4 Attachments: private.diff Original Estimate: 1h Remaining Estimate: 1h When the client surf through the ATS to a site of SharedPoint, the user get NTLM prompt message again and again. This is because of the reuse option that is turned on by default (u can turn it off with the proxy.config.http.share_server_sessions option). My attached patch turns on the private_session flag when the ATS gets auth connection, and then it will not use the reuse option for this connection. For further reading on this global bug in proxies: http://blogs.msdn.com/b/asiatech/archive/2012/03/28/ie-always-prompts-for-authentication-when-browsing-through-proxy-server.aspx Microsoft recommend at (http://technet.microsoft.com/en-us/library/cc995189.aspx): “we recommend that you use SSL encryption for the traffic between Forefront TMG and the client. NTLM authentication is per connection, and encryption prevents improper reuse of connections by legacy proxy devices on the Internet.” -- 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-1652) 3.2.x - mutexAllocator and netVCAllocator in-use count continually growing
[ https://issues.apache.org/jira/browse/TS-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1652: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - mutexAllocator and netVCAllocator in-use count continually growing -- Key: TS-1652 URL: https://issues.apache.org/jira/browse/TS-1652 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.0 Reporter: Shaun McGinnity Assignee: Alan M. Carroll Fix For: 3.2.4 Running HTTP traffic through 3.2.0 we see the in-use count from the mutexAllocator and netVCAllocators continually growing. An example allocator dump before a test: 88064 | 2064 |688 | memory/netVCAllocator 1566720 |1564800 | 80 | memory/mutexAllocator After the test has completed (about 15 minutes of traffic): 13914112 | 629520 |688 | memory/netVCAllocator 2570240 |2376480 | 80 | memory/mutexAllocator We never see the in-use counters fall back to the value set before the test. If we start the test again then we get further growth. Running for longer or under heavy load the growth is much clearer: 6791976960 | 6791970080 | 80 | memory/mutexAllocator -- 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-1536) 3.2.x - SNI support breaks IP-based lookup
[ https://issues.apache.org/jira/browse/TS-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1536: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - SNI support breaks IP-based lookup -- Key: TS-1536 URL: https://issues.apache.org/jira/browse/TS-1536 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Reporter: James Peach Assignee: James Peach Fix For: 3.2.4 The OpenSSL SNI callback will revert to the default context if the name-based lookup fails even if we already did a successful address-based context lookup. In this case, we clobber the address-based context with a default context. -- 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-1497) 3.2.x - stats codes mess up when disk fail
[ https://issues.apache.org/jira/browse/TS-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1497: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - stats codes mess up when disk fail -- Key: TS-1497 URL: https://issues.apache.org/jira/browse/TS-1497 Project: Traffic Server Issue Type: Bug Components: Cache, Stats Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: Igor Galić Fix For: 3.2.4 patch talks -- 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-1523) 3.2.x - High CPU on *BSD
[ https://issues.apache.org/jira/browse/TS-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1523: --- Fix Version/s: (was: 3.2.3) 3.2.4 3.2.x - High CPU on *BSD Key: TS-1523 URL: https://issues.apache.org/jira/browse/TS-1523 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Assignee: Daniel Gruno Fix For: 3.2.4 Attachments: 0001-Add-OpenBSD-support.patch, freebsd.patch Add OpenBSD support. -- 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-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1232: --- Fix Version/s: (was: 3.2.3) (was: 3.3.0) 3.2.4 Support unknown methods in HTTP requests Key: TS-1232 URL: https://issues.apache.org/jira/browse/TS-1232 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Uri Shachar Labels: http Fix For: 3.2.4 Original Estimate: 72h Remaining Estimate: 72h When acting as a transparent proxy, we may intercept WebDAV and other HTTP based protocols. Currently, the response will be 405 Method Not Allowed even though ATS can deal with the request as long as the rest of it is well-formed. Adding this functionality requires only minor changes and it could be configured on/off (proxy.config.http.accept_unknown_methods) Interested? -- 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-1609) Traffic Cop doesn't wait() for its children
[
https://issues.apache.org/jira/browse/TS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1609:
---
Backport to Version: (was: 3.2.4)
Traffic Cop doesn't wait() for its children
---
Key: TS-1609
URL: https://issues.apache.org/jira/browse/TS-1609
Project: Traffic Server
Issue Type: Bug
Environment: Linux and possibly FreeBSD
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.4
When {{traffic_cop}} is killed by a supervising process it doesn't wait() for
its children.
This can lead to race conditions where traffic cop is killed, for instance by
{{upstart}}, and then started again, while a {{traffic_manager}} and
{{traffic_server}} are still running.
n.b.: This does not happen on Solaris, where SMF kills off all processes
running in the same [contract(4)|http://illumos.org/man/4/contract].
--
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] [Work started] (TS-1657) 3.2.x - Traffic Cop doesn't wait() for its children
[
https://issues.apache.org/jira/browse/TS-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-1657 started by Igor Galić.
3.2.x - Traffic Cop doesn't wait() for its children
---
Key: TS-1657
URL: https://issues.apache.org/jira/browse/TS-1657
Project: Traffic Server
Issue Type: Bug
Environment: Linux and possibly FreeBSD
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.4
When {{traffic_cop}} is killed by a supervising process it doesn't wait() for
its children.
This can lead to race conditions where traffic cop is killed, for instance by
{{upstart}}, and then started again, while a {{traffic_manager}} and
{{traffic_server}} are still running.
n.b.: This does not happen on Solaris, where SMF kills off all processes
running in the same [contract(4)|http://illumos.org/man/4/contract].
--
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-1657) 3.2.x - Traffic Cop doesn't wait() for its children
[
https://issues.apache.org/jira/browse/TS-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić resolved TS-1657.
Resolution: Fixed
b20c7404f8775ffc088e6833622fa8440f8d0038
ce7df45b2a20cfa13d57f5eb30e23d15201839f6
fc7c53437d57bb48c283b9b9ae2ebd8f9ab0c1b1
5c14a3c49acd96a1ff21a731716b3c485dd46272 (broken CHANGES)
2069448fea664161a29891f1db46de4e9c05fb78 (solaris fix)
3.2.x - Traffic Cop doesn't wait() for its children
---
Key: TS-1657
URL: https://issues.apache.org/jira/browse/TS-1657
Project: Traffic Server
Issue Type: Bug
Environment: Linux and possibly FreeBSD
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.4
When {{traffic_cop}} is killed by a supervising process it doesn't wait() for
its children.
This can lead to race conditions where traffic cop is killed, for instance by
{{upstart}}, and then started again, while a {{traffic_manager}} and
{{traffic_server}} are still running.
n.b.: This does not happen on Solaris, where SMF kills off all processes
running in the same [contract(4)|http://illumos.org/man/4/contract].
--
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-1656) 3.2.x - enable_read_while_writer not working in 3.2.0
[ https://issues.apache.org/jira/browse/TS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1656: --- Fix Version/s: (was: 3.3.1) 3.2.4 3.2.x - enable_read_while_writer not working in 3.2.0 - Key: TS-1656 URL: https://issues.apache.org/jira/browse/TS-1656 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.2.0 Environment: Ubuntu 10.04 Reporter: Kingsley Foreman Assignee: weijin Fix For: 3.2.4 enable_read_while_writer is not currently working as it should with the settings CONFIG proxy.config.cache.enable_read_while_writer INT 1 CONFIG proxy.config.cache.max_doc_size INT 0 CONFIG proxy.config.http.background_fill_active_timeout INT 0 CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0 If I do wget http://127.0.0.1:8080/largefile.mpg g -O /dev/null and then on the same box 30 seconds later (while the first one is still going I do) wget http://127.0.0.1:8080/largefile.mpg g -O /dev/null again The master server (after I kill them both) gets 012-09-03T10:49:32.007667+09:18 master1-adl6 nginx: 1.1.1.1 - - [03/Sep/2012:10:49:32 +0930] GET /largefile.mpg HTTP/1.1 200 306253448 - Wget/1.12 (linux-gnu) - 2012-09-03T10:49:32.879914+09:18 master1-adl6 nginx: 1.1.1.1 - - [03/Sep/2012:10:49:32 +0930] GET /largefile.mpg HTTP/1.1 200 226717704 - Wget/1.12 (linux-gnu) - -- 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-1656) 3.2.x - enable_read_while_writer not working in 3.2.0
[ https://issues.apache.org/jira/browse/TS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-1656. Resolution: Fixed ca7c9fd3313afba18dfab868d9275d80152b693e 3.2.x - enable_read_while_writer not working in 3.2.0 - Key: TS-1656 URL: https://issues.apache.org/jira/browse/TS-1656 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.2.0 Environment: Ubuntu 10.04 Reporter: Kingsley Foreman Assignee: weijin Fix For: 3.2.4 enable_read_while_writer is not currently working as it should with the settings CONFIG proxy.config.cache.enable_read_while_writer INT 1 CONFIG proxy.config.cache.max_doc_size INT 0 CONFIG proxy.config.http.background_fill_active_timeout INT 0 CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0 If I do wget http://127.0.0.1:8080/largefile.mpg g -O /dev/null and then on the same box 30 seconds later (while the first one is still going I do) wget http://127.0.0.1:8080/largefile.mpg g -O /dev/null again The master server (after I kill them both) gets 012-09-03T10:49:32.007667+09:18 master1-adl6 nginx: 1.1.1.1 - - [03/Sep/2012:10:49:32 +0930] GET /largefile.mpg HTTP/1.1 200 306253448 - Wget/1.12 (linux-gnu) - 2012-09-03T10:49:32.879914+09:18 master1-adl6 nginx: 1.1.1.1 - - [03/Sep/2012:10:49:32 +0930] GET /largefile.mpg HTTP/1.1 200 226717704 - Wget/1.12 (linux-gnu) - -- 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] [Work started] (TS-1655) 3.2.x - wccp does not build out of tree
[
https://issues.apache.org/jira/browse/TS-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-1655 started by Igor Galić.
3.2.x - wccp does not build out of tree
---
Key: TS-1655
URL: https://issues.apache.org/jira/browse/TS-1655
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.3.2
{noformat}
make[2]: Entering directory
`/home/igalic/src/asf/trafficserver/BUILD-3.2.x/lib/tsconfig'
YACC TsConfigGrammar.c
updating TsConfigGrammar.h
/usr/bin/sed -f BisonHeaderToC++.sed TsConfigGrammar.h TsConfigGrammar.hpp
/usr/bin/sed: couldn't open file BisonHeaderToC++.sed: No such file or
directory
make[2]: *** [TsConfigGrammar.hpp] Error 4
{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] [Created] (TS-1658) 3.2.x - FreeBSD: Add raw disk support for the cache
Igor Galić created TS-1658: -- Summary: 3.2.x - FreeBSD: Add raw disk support for the cache Key: TS-1658 URL: https://issues.apache.org/jira/browse/TS-1658 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.3 Environment: FreeBSD Reporter: George Paul Assignee: Igor Galić Fix For: 3.3.1 Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 3.3 release. -George -- 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] [Work started] (TS-1658) 3.2.x - FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-1658 started by Igor Galić. 3.2.x - FreeBSD: Add raw disk support for the cache --- Key: TS-1658 URL: https://issues.apache.org/jira/browse/TS-1658 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.3 Environment: FreeBSD Reporter: George Paul Assignee: Igor Galić Labels: freebsd, gsoc Fix For: 3.3.1 Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 3.3 release. -George -- 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-1658) 3.2.x - FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-1658. Resolution: Fixed Fix Version/s: (was: 3.3.1) 3.2.4 a5f590b0de50a086ca39a6111aca15436dbe2fc3 dc8c5550ae369ec5ac5d24e94df89fccfdab2dac 4ffb342816565478b20d7cd5efad0d53cd5339d2 ed5eb13a63f4a4cd3762c3176721a27c3de4696d (wrong CHANGES entry) 3.2.x - FreeBSD: Add raw disk support for the cache --- Key: TS-1658 URL: https://issues.apache.org/jira/browse/TS-1658 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.3 Environment: FreeBSD Reporter: George Paul Assignee: Igor Galić Labels: freebsd, gsoc Fix For: 3.2.4 Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 3.3 release. -George -- 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] [Assigned] (TS-1659) Gzip: Make it possible to remove compressible-content-type
[
https://issues.apache.org/jira/browse/TS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto van der Schaaf reassigned TS-1659:
---
Assignee: Otto van der Schaaf
Gzip: Make it possible to remove compressible-content-type
Key: TS-1659
URL: https://issues.apache.org/jira/browse/TS-1659
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Assignee: Otto van der Schaaf
I would like to be able to make a simple configuration like:
{noformat}
compressible-content-type text/*
compressible-content-type !text/javascript
{noformat}
This should result in:
Add all {{text/*}} types, remove {{text/javascript}}
--
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-1660) Host field should not has c style terminator
weijin created TS-1660: -- Summary: 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 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-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 ] weijin updated TS-1660: --- Attachment: ts-1660.diff 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 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] [Closed] (TS-1647) VMWARE cannot read from cache node marked as down
[ https://issues.apache.org/jira/browse/TS-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dow Buzzell closed TS-1647. --- Backport to Version: 3.2.0 While we were able to run without this separate nic for cache on physicals and in one datacenter on vm's seems in the other datacenter where there are network issues, this is essential as when there is a dropped packet traffic server shuts down the cluster communication and refuses to reconnect even though it is seen that the other members are trying to reconnect to the member who had the dropped packet.. seems like this is a bug, as who really has a network that never drops a packet? VMWARE cannot read from cache node marked as down - Key: TS-1647 URL: https://issues.apache.org/jira/browse/TS-1647 Project: Traffic Server Issue Type: Bug Components: Cache, Clustering Reporter: Dow Buzzell Attachments: 909smokinggun.png, stackbug.png We are seeing issues related to cluster management on VMWARE. Seems like we have a NIC going to sleep and losing packets during a read operation from a member of the cluster, then seeing this as marked down by ATS, and stays down until the entire cluster is restarted.. seems like idle times are at the heart of the issue and allocating 500MHZ to each VM or pinning the CPU doesn't help the NIC still sleeps .. TCPDUMP see's missing segments yet reports 0 packets lost. dmesg see's PC: bad TCP reclen 0x73746174 (non-terminal) RPC: bad TCP reclen 0x6348 (large) RPC: bad TCP reclen 0x633f (large) under load, and ATS reports cannot read from a cluster node and marks the node down. WE have another datacenter where this does not happen the difference in kernel revisions are: Sleeping NIC Data Center RHEL 5 2.6.18-308.16.1.el5 Working Data Center 2.6.18-194.3.1.el5 WE have validated that VMWARE is running properly in this datacenter but are trying to get a ticket open with them to look into why one configuration works but another does not Everything else in the two configurations are nearly identical we are going to try and get the nic drivers updated as you can see it is the LATER Linux Kernel version that is causing headaches.. Any ideas would really be appreciated ... Thank you, Dow -- 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-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13555899#comment-13555899
]
Zhao Yongming commented on TS-1006:
---
ram_cache.algorithm: 0, that is CLFUS. maybe the CLFUS is good with our
patches? and 72% is about 11G, that sounds very good to me.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments: 0001-Allocator-optimize-InkFreeList-memory-pool.patch,
0002-Allocator-make-InkFreeList-memory-pool-configurable.patch,
0003-Allocator-store-InkChunkInfo-into-Chunk.patch,
0004-Allocator-optimize-alignment-size-to-avoid-mmap-fail.patch,
0005-Allocator-adjust-reclaiming-strategy-of-InkFreeList.patch,
0006-RamCacheLRU-split-LRU-queue-into-multiple-queues-to-.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
