[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-980:
-
Fix Version/s: (was: 3.1.4)
3.3.0
reschedule to 3.3.0, may need more tweak testing
change client_session schedule from global to thread local, and reduce the
try_locks in UnixNetVConnection::reenable
-
Key: TS-980
URL: https://issues.apache.org/jira/browse/TS-980
Project: Traffic Server
Issue Type: Improvement
Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
Environment: all
Reporter: weijin
Assignee: weijin
Fix For: 3.3.0
Attachments: ts-980.diff
I did some performance test on ats last days(disable cache, set share_server
session 2, pure proxy mode), I did see significant improvement on low load,
but it dropped rapidly when load is high. meanwhile, some stability problems
happened. Through gdb, I found the client_session`s mutex can be acquired by
two or more threads, I believe some schedules happened during the sm
life_time. May be we need do some work to find these eventProcessor.schedules
and change them to thread schedules.
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list
} else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
// put into enable_list;
} else {
// put into ready_list;
}
}
remove UnixNetVConnection::reenable try_lock operations, 3 reasons
1. try_lock operation means obj allocation and deallocation operation.
frequently
2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
by as soon as possible)
3. try_lock should not acquire the net-handler`s mutex. That may lead more
net io latency if it is an epoll event need to be processed in other threads.
If it is not an epoll event(time event), I don`t think putting vc in
ready_list has any advantage than in enable_list.
may be we can change reenale function like this:
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list;
} else {
// put into enable_list;
}
my buddies, any advice?
--
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-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249836#comment-13249836 ] Leif Hedstrom commented on TS-1193: --- There was at least one other bug related to building on OpenBSD,so please make sure we don't have duplications. Traffic Server building on OpenBSD -- Key: TS-1193 URL: https://issues.apache.org/jira/browse/TS-1193 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.3 Reporter: Brian Geffon Assignee: Brian Geffon This is a parent issue for the task of getting traffic server building on OpenBSD. -- 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-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249837#comment-13249837 ] Leif Hedstrom commented on TS-1193: --- Also, please mark bugs with a fix version, to avoid flooding the bucket of untargeted bugs :). Traffic Server building on OpenBSD -- Key: TS-1193 URL: https://issues.apache.org/jira/browse/TS-1193 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.3 Reporter: Brian Geffon Assignee: Brian Geffon This is a parent issue for the task of getting traffic server building on OpenBSD. -- 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
Traffic Server and Video caching
I'm wondering if I can use the Apache Traffic Server as a Video cache and if so: 1. Can it forward the video while caching it? 2. Can it handles the video other than as an object (like image caching) 3. Is there anyone that use it as video cache Thanks in advance Have a nice day Rav Sa
Re: Traffic Server and Video caching
On 4/9/12 5:18 AM, Ravid Sagy wrote: I'm wondering if I can use the Apache Traffic Server as a Video cache and if so: 1. Can it forward the video while caching it? Yes. As long as the request is not a Range: request (we don't cache Range requests). Range requests into a cached, large objects is still poor performance too. This generally makes ATS a poor cache choice at this point for large Video's (most players will use Range requests for positioning). We really have to fix this (there's a Jira bug for it, the infamous TS-475. 2. Can it handles the video other than as an object (like image caching) Note sure what that means. :)
[jira] [Updated] (TS-1087) TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
[
https://issues.apache.org/jira/browse/TS-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
B Wyatt updated TS-1087:
Fix Version/s: (was: 3.1.4)
3.3.0
TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
--
Key: TS-1087
URL: https://issues.apache.org/jira/browse/TS-1087
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.0
Reporter: B Wyatt
Assignee: B Wyatt
Priority: Trivial
Fix For: 3.3.0
Attachments: txn-outgoing-addr.patch
Original Estimate: 1m
Remaining Estimate: 1m
ts.h.in lists the following declaration:
{code}TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr);{code}
However, the current implementation has this function sig:
{code}tsapi TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct
sockaddr const* addr, socklen_t addrlen);{code}
Trafficserver is unable to load plugins which use this function due to the
unresolved symbol.
--
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-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 updated TS-1163: Fix Version/s: (was: 3.1.4) 3.3.0 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.3.0 Attachments: blkgetsize64.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] [Created] (TS-1195) IPv6 address URLs are not parsed.
IPv6 address URLs are not parsed. - Key: TS-1195 URL: https://issues.apache.org/jira/browse/TS-1195 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.2.0 A URL with a raw IPv6 address is not parsed. It should be parsed with or without braces (per RFC). http://fe80:2710::1:1/some/path http://[fe80:2810::1:1]/some/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] [Commented] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250159#comment-13250159 ] Leif Hedstrom commented on TS-1187: --- Not sure I follow here, can you show some code example that doesn't work ? I'm assuming you are setting the appropriate header buffer? Remember there are four different headers, some of which are not available in all hooks. I'm going to move this out to 3.3.0, unless you feel it's a bug that needs to be fixed for 3.2. TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Fix Version/s: (was: 3.1.4) 3.3.0 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.3.0 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-621: Assignee: weijin (was: John Plevyak) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: weijin Fix For: 3.1.4 Attachments: TS-621_cluster_zero_size_objects.patch, force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- 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-975) server-transform.c broken
[ https://issues.apache.org/jira/browse/TS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-975: Assignee: Leif Hedstrom (was: Igor Galić) server-transform.c broken - Key: TS-975 URL: https://issues.apache.org/jira/browse/TS-975 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.0 Reporter: Otto van der Schaaf Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: server-transform.c.diff While playing around with the server-transform plugin example, i noticed it was broken. After some meddling around, i got it working again. The changes are mainly that in some cases content-length was passed in network-byte order where it shouldn't be. Another fix was handling the TS_EVENT_IMMEDIATE event in transform_write_event(). i currently perform a TSVIOReenable(data-server_vio); on that event, and it seems to work. However, I'm not sure at all if that is the correct thing to do, so if anybody could help me out on that? :-). I have tested the changed code with a custom echo server, and confirmed that the plugin is actually sending and receiving to the echo server. I added the working 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
[jira] [Commented] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250221#comment-13250221 ] Leif Hedstrom commented on TS-1130: --- yes, where's the patch? :) ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250287#comment-13250287 ] Uri Shachar commented on TS-1079: - I've tried a number of times to reproduce this degradation -- Very long benchmarks show a reproducible 0.4% drop, but that is almost an order of magnitude smaller then what you see... (I'm testing with proxy.config.diags.debug.enabled INT 0). I'll attach my results to the bug. The only thing I could think of is the macro I added to HttpTransact.cc -- It adds a couple of pointer dereferences every debug line. I've tried removing it, but haven't seen any perf change. Could you try benchmarking the patch without the changes to HttpTransact.cc/h? Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- 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-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1079: Attachment: benchmarks.tgz Uploaded benchmark results tarball Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: benchmarks.tgz, debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- 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
