[jira] [Updated] (TS-1224) Make AGG_SIZE configurable?
[ https://issues.apache.org/jira/browse/TS-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1224: -- Fix Version/s: (was: 3.1.4) sometime Moving this out to much later, I think at a minimum, we can handle 100GB files already, and optimistically, closer to 500GB. I better be retired before that becomes an issues. Make AGG_SIZE configurable? --- Key: TS-1224 URL: https://issues.apache.org/jira/browse/TS-1224 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime Attachments: TS-1224.diff In order to support very large objects, making this configurable could help. It might also be useful for those who are sensitive to latency on writes (to reduce it). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1237) Log field/filtering improvements
B Wyatt created TS-1237: --- Summary: Log field/filtering improvements Key: TS-1237 URL: https://issues.apache.org/jira/browse/TS-1237 Project: Traffic Server Issue Type: New Feature Reporter: B Wyatt Assignee: B Wyatt Priority: Minor Fix For: 3.1.5 This is a combined new feature for the following log data improvements: * Adding log fields for cache response code, header length and content length (to mirror the fields that already exist for the server and client) * Adding a log field container for the cached response headers (to mirror the field container that already exists for the server and client headers) * Adding the ability to filter custom logs based on field container members * Tweaking where we calculate the logged response body length(s) so that it accurately reflects abnormal termination cases like client/server aborts or transforms such as the range transform (when pertaining to cached responses) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1238) RAM cache hit rate unexpectedly low
John Plevyak created TS-1238: Summary: RAM cache hit rate unexpectedly low Key: TS-1238 URL: https://issues.apache.org/jira/browse/TS-1238 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.3 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 The RAM cache is not getting the expected hit rate. Looks like there are a couple issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1238) RAM cache hit rate unexpectedly low
[ https://issues.apache.org/jira/browse/TS-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-1238: - Attachment: TS-1238-jp-1.patch Add new option to disable/enable the seen_filter in the RAM cache. Fix reporting of RAM cache hits to HTTP. Fix for LRU cache. Add back in seen_filter to LRU (disabled by default). Disable seen filter by default for CLFUS. RAM cache hit rate unexpectedly low --- Key: TS-1238 URL: https://issues.apache.org/jira/browse/TS-1238 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.3 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 Attachments: TS-1238-jp-1.patch The RAM cache is not getting the expected hit rate. Looks like there are a couple issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt closed TS-1163. --- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.4 Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux -- Key: TS-1163 URL: https://issues.apache.org/jira/browse/TS-1163 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: B Wyatt Assignee: B Wyatt Fix For: 3.1.4 Attachments: blkgetsize64.bwyatt.patch, blkgetsize64.v2.bwyatt.patch Due to 32bit integers in both the trafficersever code and the ioctl used to determine raw disk size, the number of sectors reported to the cache storage system is bound to 0-0x. If a disk has 512 byte sectors and is larger than 2TB it will report (num_sectors % 0x) * 512 bytes avaliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1236) HTTP Accept filters do not work on Illumos
[ https://issues.apache.org/jira/browse/TS-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265895#comment-13265895 ] Alan M. Carroll commented on TS-1236: - Isn't it wonderful that we have redundant socket creation code so that you can't mess everything up with one patch? This looks good to me. My primary comment would be whether we want to support filter control on a per port basis. That is, add something to HttpProxyPort for this. In that case you would move the global config option checking to HttpProxyPort::processOptions. That would check for the port option and if not found, use the global config setting (proxy.config.net.defer_accept). The local socket binding code would then always just check the HttpProxyPort data, or that would be passed down to the iocore socket code. I don't know enough about the defer accept use case to say if this would be a good idea. HTTP Accept filters do not work on Illumos -- Key: TS-1236 URL: https://issues.apache.org/jira/browse/TS-1236 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.3 Environment: Illumos (OmniOS) Reporter: Theo Schlossnagle Assignee: Theo Schlossnagle Priority: Minor Attachments: LocalManager-acceptfilt.patch, TS-1236.diff Original Estimate: 1h Remaining Estimate: 1h The path for creating the socket() and binding happen outside of the previously used code path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1235) Deny occurring for IPs not in the ip_allow.config file
[
https://issues.apache.org/jira/browse/TS-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-1235:
---
Assignee: Alan M. Carroll
Deny occurring for IPs not in the ip_allow.config file
--
Key: TS-1235
URL: https://issues.apache.org/jira/browse/TS-1235
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Security
Affects Versions: 3.1.3
Environment: Linux server.domain.com 2.6.32-220.el6.x86_64 #1 SMP Wed
Dec 7 10:41:06 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Michael Turner
Assignee: Alan M. Carroll
Consistently seeing this morning IPs that are not set to deny in
ip_allow.config being rejected. Here's the config file we were using:
#
# ip_allow.config
#
# Two types of rules:
# #src_ip=range of IP addresses action=ip_allow
# #src_ip=range of IP addresses action=ip_deny
# Rules are applied in the order listed starting from the top.
#
# Ban all of the servers
src_ip=AAA.BBB.CCC.134 action=ip_deny
#src_ip=AAA.BBB.CCC.135 action=ip_deny # temp unbanning. we've talked
to him
src_ip=AAA.BBB.CCC.137action=ip_deny
src_ip=AAA.BBB.CCC.202action=ip_deny
src_ip=AAA.BBB.CCC.203action=ip_deny
src_ip=AAA.BBB.CCC.208action=ip_deny
src_ip=AAA.BBB.CCC.209action=ip_deny
src_ip=AAA.BBB.CCC.216action=ip_deny
src_ip=AAA.BBB.CCC.217action=ip_deny
src_ip=AAA.BBB.CCC.218action=ip_deny
src_ip=AAA.BBB.CCC.219action=ip_deny
src_ip=AAA.BBB.CCC.220action=ip_deny
src_ip=AAA.BBB.CCC.222action=ip_deny
src_ip=AAA.BBB.CCC.224action=ip_deny
src_ip=AAA.BBB.CCC.236action=ip_deny
# Banned IPs
src_ip=AAA.BBB.CCC.212action=ip_deny
src_ip=AAA.BBB.CCC.246action=ip_deny
src_ip=AAA.BBB.CCC.144action=ip_deny
# Stock Rules
src_ip=0.0.0.0-255.255.255.255action=ip_allow
src_ip=::-::::::: action=ip_allow
And here's log entries from when this config was active:
[Apr 30 10:06:21.446] {0x2b321b2d42a0} NOTE: updated diags config
[Apr 30 10:06:21.449] Server {0x2b321b2d42a0} NOTE: cache clustering disabled
[Apr 30 10:06:21.492] Server {0x2b321b2d42a0} NOTE: cache clustering disabled
[Apr 30 10:06:21.584] Server {0x2b321b2d42a0} NOTE: logging initialized[15],
logging_mode = 3
[Apr 30 10:06:21.591] Server {0x2b321b2d42a0} NOTE: traffic server running
[Apr 30 10:06:25.140] Server {0x2b3222d2c700} NOTE: cache enabled
[Apr 30 10:06:33.804] Server {0x2b3223534700} WARNING: connect by disallowed
client AAA.BBB.CCC.111, closing
[Apr 30 10:07:01.914] Server {0x2b324b2d2700} WARNING: connect by disallowed
client AAA.BBB.CCC.111, closing
[Apr 30 10:07:02.025] Server {0x2b324b4d4700} WARNING: connect by disallowed
client AAA.BBB.CCC.144, closing
[Apr 30 10:07:03.109] Server {0x2b3222827700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:04.594] Server {0x2b3222f2e700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:05.201] Server {0x2b3223332700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.170] Server {0x2b3223534700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.575] Server {0x2b3223736700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.690] Server {0x2b3223837700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.785] Server {0x2b3223938700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.817] Server {0x2b3223a39700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:06.841] Server {0x2b3223b3a700} WARNING: connect by disallowed
client AAA.BBB.CCC.74, closing
[Apr 30 10:07:10.587] Server {0x2b321b2d42a0} WARNING: connect by disallowed
client AAA.BBB.CCC.35, closing
FATAL: HttpSM.cc:890: failed assert `0`
The IPS visible in the log ending in .111 and .74 are not in the deny list
anywhere. The two ending in .144 and .35 are in the deny list.
Please let me know what further information I can provide to help
troubleshoot/reproduce this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1239) TSHttpTxnServerAddrSet has no implementation ; plugins will fail to load do to the undefined reference
B Wyatt created TS-1239: --- Summary: TSHttpTxnServerAddrSet has no implementation ; plugins will fail to load do to the undefined reference Key: TS-1239 URL: https://issues.apache.org/jira/browse/TS-1239 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.3 Reporter: B Wyatt Assignee: B Wyatt Priority: Minor Fix For: 3.1.4 TSHttpTxnServerAddrSet is in ts.h, but it has no implementation or supporting functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1240) Debug assert triggered in LogBuffer.cc:209
Leif Hedstrom created TS-1240:
-
Summary: Debug assert triggered in LogBuffer.cc:209
Key: TS-1240
URL: https://issues.apache.org/jira/browse/TS-1240
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.4
Reporter: Leif Hedstrom
From John:
{code}
[May 1 09:08:44.746] Server {0x77fce800} NOTE: traffic server running
FATAL: LogBuffer.cc:209: failed assert `m_unaligned_buffer`
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server - STACK TRACE:
/home/jplevyak/projects/ts/ts-2/lib/ts/.libs/libtsutil.so.3(ink_fatal+0xa3)[0x77bae4a5]
/home/jplevyak/projects/ts/ts-2/lib/ts/.libs/libtsutil.so.3(_ink_assert+0x3c)[0x77bad47c]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x35)[0x5d3a53]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogObject15_checkout_writeEPmm+0x41)[0x5eef75]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x4cb)[0x5ef5b9]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x4a)[0x5daab4]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN3Log6accessEP9LogAccess+0x235)[0x5d97f9]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM12update_statsEv+0x204)[0x579872]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM9kill_thisEv+0x31d)[0x579525]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x337)[0x56cec1]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x14c)[0x5b24aa]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6bb9d1]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6bbafa]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x6fa)[0x6bcaaf]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_Z12write_to_netP10NetHandlerP18UnixNetVConnectionP14PollDescriptorP7EThread+0x7d)[0x6bc3b3]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6e6)[0x6b8828]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x72)[0x4e2450]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x111)[0x6dde7f]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0x431)[0x6de42b]
/a/home/jplevyak/projects/ts/ts-2/proxy/.libs/lt-traffic_server[0x6dd0bc]
/lib64/libpthread.so.0(+0x7d90)[0x77676d90]
/lib64/libc.so.6(clone+0x6d)[0x754f9f5d]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
