[jira] [Updated] (TS-994) X-Forwarded-For should follow the squid way
[ https://issues.apache.org/jira/browse/TS-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-994: - Attachment: XFF.patch a quick fix > X-Forwarded-For should follow the squid way > --- > > Key: TS-994 > URL: https://issues.apache.org/jira/browse/TS-994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.1 > > Attachments: XFF.patch > > > TS will append the IP in the format of: > X-Forwarded-For: 127.0.0.1, 10.32.102.41\r\n > while http://en.wikipedia.org/wiki/X-Forwarded-For says: > X-Forwarded-For: client1, proxy1, proxy2 > there is 2 spaces -- 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-994) X-Forwarded-For should follow the squid way
X-Forwarded-For should follow the squid way --- Key: TS-994 URL: https://issues.apache.org/jira/browse/TS-994 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Minor Fix For: 3.1.1 Attachments: XFF.patch TS will append the IP in the format of: X-Forwarded-For: 127.0.0.1, 10.32.102.41\r\n while http://en.wikipedia.org/wiki/X-Forwarded-For says: X-Forwarded-For: client1, proxy1, proxy2 there is 2 spaces -- 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-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132332#comment-13132332 ] bettydramit commented on TS-992: good job > Generic portability fixes. > -- > > Key: TS-992 > URL: https://issues.apache.org/jira/browse/TS-992 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora >Priority: Minor > Attachments: 0001-iocore-s-swap-ts_swap-g.patch, > 0001-iocore-s-swap-ts_swap-g.patch, > 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, > 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, > 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, > 0005-tests-add-missing-link-time-flags.patch, > 0006-proxy-NULL-is-defined-in-unistd.h.patch, > 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, > 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, > 0009-proxy-fix-off-by-one-error-in-sscanf.patch, > 0010-autoconf-improve-detection-of-available-system-heade.patch, > 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, > 0012-examples-add-missing-sys-types.h-header.patch > > > Bunch of patches. -- 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-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Sikora updated TS-992: Attachment: 0001-iocore-s-swap-ts_swap-g.patch > Generic portability fixes. > -- > > Key: TS-992 > URL: https://issues.apache.org/jira/browse/TS-992 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora >Priority: Minor > Attachments: 0001-iocore-s-swap-ts_swap-g.patch, > 0001-iocore-s-swap-ts_swap-g.patch, > 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, > 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, > 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, > 0005-tests-add-missing-link-time-flags.patch, > 0006-proxy-NULL-is-defined-in-unistd.h.patch, > 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, > 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, > 0009-proxy-fix-off-by-one-error-in-sscanf.patch, > 0010-autoconf-improve-detection-of-available-system-heade.patch, > 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, > 0012-examples-add-missing-sys-types.h-header.patch > > > Bunch of patches. -- 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-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132298#comment-13132298 ] Piotr Sikora commented on TS-993: - Attached patch let's ATS & examples compile on OpenBSD, but this isn't usable state yet, because ATS fails to register kqueue events. I most likely won't have time to investigate this further during the next few weeks, so if anyone wants to take a shot at it, it would be great. > Add OpenBSD support. > > > Key: TS-993 > URL: https://issues.apache.org/jira/browse/TS-993 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora > Attachments: 0001-Add-OpenBSD-support.patch > > > Add OpenBSD support. -- 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-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Sikora updated TS-993: Attachment: 0001-Add-OpenBSD-support.patch > Add OpenBSD support. > > > Key: TS-993 > URL: https://issues.apache.org/jira/browse/TS-993 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora > Attachments: 0001-Add-OpenBSD-support.patch > > > Add OpenBSD support. -- 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-993) Add OpenBSD support.
Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Attachments: 0001-Add-OpenBSD-support.patch Add OpenBSD support. -- 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-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132296#comment-13132296 ] Leif Hedstrom commented on TS-992: -- Just took a quick glance, but lets make sure we use the ats_ prefix for "core" code, and not use the ts_ prefix. The TS prefix is reserved for public APIs. > Generic portability fixes. > -- > > Key: TS-992 > URL: https://issues.apache.org/jira/browse/TS-992 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora >Priority: Minor > Attachments: 0001-iocore-s-swap-ts_swap-g.patch, > 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, > 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, > 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, > 0005-tests-add-missing-link-time-flags.patch, > 0006-proxy-NULL-is-defined-in-unistd.h.patch, > 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, > 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, > 0009-proxy-fix-off-by-one-error-in-sscanf.patch, > 0010-autoconf-improve-detection-of-available-system-heade.patch, > 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, > 0012-examples-add-missing-sys-types.h-header.patch > > > Bunch of patches. -- 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-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Sikora updated TS-992: Attachment: 0012-examples-add-missing-sys-types.h-header.patch 0011-mgmt-cast-localtime-argument-to-const-time_t.patch 0010-autoconf-improve-detection-of-available-system-heade.patch 0009-proxy-fix-off-by-one-error-in-sscanf.patch 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch 0006-proxy-NULL-is-defined-in-unistd.h.patch 0005-tests-add-missing-link-time-flags.patch 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch 0001-iocore-s-swap-ts_swap-g.patch > Generic portability fixes. > -- > > Key: TS-992 > URL: https://issues.apache.org/jira/browse/TS-992 > Project: Traffic Server > Issue Type: Improvement > Environment: OpenBSD >Reporter: Piotr Sikora >Priority: Minor > Attachments: 0001-iocore-s-swap-ts_swap-g.patch, > 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, > 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, > 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, > 0005-tests-add-missing-link-time-flags.patch, > 0006-proxy-NULL-is-defined-in-unistd.h.patch, > 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, > 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, > 0009-proxy-fix-off-by-one-error-in-sscanf.patch, > 0010-autoconf-improve-detection-of-available-system-heade.patch, > 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, > 0012-examples-add-missing-sys-types.h-header.patch > > > Bunch of patches. -- 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-992) Generic portability fixes.
Generic portability fixes. -- Key: TS-992 URL: https://issues.apache.org/jira/browse/TS-992 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Priority: Minor Bunch of patches. -- 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] [Resolved] (TS-934) Proxy Mutex null pointer crash
[ https://issues.apache.org/jira/browse/TS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-934. Resolution: Fixed Patch committed 1187108. This reduces the problem but may not be a complete fix. It improves the situation enough to use but we may need to re-open this bug later. > Proxy Mutex null pointer crash > -- > > Key: TS-934 > URL: https://issues.apache.org/jira/browse/TS-934 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.0 > Environment: Debian 6.0.2 quadcore, forward transparent proxy. >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 3.1.2 > > Attachments: ts-934-patch.txt > > > [Client report] > We had the cache crash gracefully twice last night on a segfault. Both > times the callstack produced by trafficserver's signal handler was: > /usr/bin/traffic_server[0x529596] > /lib/libpthread.so.0(+0xef60)[0x2ab09a897f60] > [0x2ab09e7c0a10] > usr/bin/traffic_server(HttpServerSession::do_io_close(int)+0xa8)[0x567a3c] > /usr/bin/traffic_server(HttpVCTable::cleanup_entry(HttpVCTableEntry*)+0x4c)[0x56aff6] > /usr/bin/traffic_server(HttpVCTable::cleanup_all()+0x64)[0x56b07a] > /usr/bin/traffic_server(HttpSM::kill_this()+0x120)[0x57c226] > /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x208)[0x571b28] > /usr/bin/traffic_server(Continuation::handleEvent(int, > void*)+0x69)[0x4e4623] > I went through the disassembly and the instruction that it is on in > ::do_io_close is loading the value of diags (not dereferencing it) so it > is unlikely that that through a segfault (unless this is some how in > thread local storage and that is corrupt). > The kernel message claimed that the instruction pointer was 0x4e438e > which in this build is in ProxyMutexPtr::operator ->() on the > instruction that dereferences the object pointer to get the stored mutex > pointer (bingo!), so it would seem that at some point we are > dereferencing a null "safe" pointer. -- 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-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
[ https://issues.apache.org/jira/browse/TS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131875#comment-13131875 ] Alan M. Carroll commented on TS-986: It should be a sockaddr*, not in_addr. Also, if we want to fix this, we should just put a declaration in name only at the top, e.g. "struct sockaddr;" OTOH I don't see how we will eliminate dependency on netinet/net.h for something that deals heavily with IP addresses. > ts/experimental has a dependency on netinet/net.h (for struct in_addr) > -- > > Key: TS-986 > URL: https://issues.apache.org/jira/browse/TS-986 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Fix For: 3.1.2 > > > Alan seems to indicate this is wrong anyways, but just adding this bug so we > remember it's probably a bad idea. The offending API is > tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in); -- 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] [Resolved] (TS-991) WCCP can stall during a restart.
[ https://issues.apache.org/jira/browse/TS-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-991. Resolution: Fixed Fix Version/s: (was: 3.1.2) 3.1.1 Changed view update logic to generate an assignment if the last reported time of a cache in the view is not the time of the last packet (so the cache has left and returned to the view in the router's opinion but not in the client's opinion). > WCCP can stall during a restart. > > > Key: TS-991 > URL: https://issues.apache.org/jira/browse/TS-991 > Project: Traffic Server > Issue Type: Bug > Components: Management >Affects Versions: 3.1.0 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: wccp > Fix For: 3.1.1 > > > If the WCCP router uses an identifying IP address which is not the same as > the source IP address on the packet (which is allowed by the WCCP spec) then > the TS client side WCCP code can fail to properly generate an assignment. > This happens during a window after a restart when TS is trying to set up the > WCCP view while the router has not yet realized TS has restarted. The client > WCCP logic then soft stalls and doesn't generate a new assignement when the > router responses are processed. -- 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-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131804#comment-13131804
]
Alan M. Carroll commented on TS-947:
[Mailing list
discussion|http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201109.mbox/%3ccamkwmbeeu8uqa+ymaqvsoqgy0hajjbuevdex17eqjbog9v7...@mail.gmail.com%3E]
Key quote by John Pleyvak
{quote}So the situation is that the existing design dates from a time when
threads and scheduling for Unix were primitive. It was not uncommon in
those
days for threads to "go away" for half a second, a second or more in a
loaded system.
To deal with this, the current design is non-blocking all the way down.
This means that no code (correctly written) ever blocks on a mutex (we use
try_lock) which
is the origin of that AIO code.
Now, threading and scheduling has dramatically improved and the problems
that motivated
that design decision have (most probably :) gone away.
It would be dramatically easier to do away with this requirement and write
the code with
small critical sections and just block if we miss a mutex. First, that is
the way most
programs are written these days and second, having to back out of the entire
stack, saving
context is a huge burden. It makes the code hard to read, write and debug.
The upshot is that my suggestion to just add a 10 msec timeout is for the
short term.
I'd like to see a blocking, small critical section AIO/Cache/RamCache patch
performance
tested against the existing code *then* pull the trigger on such a new
design and fix the
offending code (including the AIO race).
I plan to work on such a patch and would be very interested in talking to
anyone who might be interested in such a thing as well.
{quote}
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
>Assignee: John Plevyak
> Fix For: 3.1.2
>
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {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] [Created] (TS-991) WCCP can stall during a restart.
WCCP can stall during a restart. Key: TS-991 URL: https://issues.apache.org/jira/browse/TS-991 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.2 If the WCCP router uses an identifying IP address which is not the same as the source IP address on the packet (which is allowed by the WCCP spec) then the TS client side WCCP code can fail to properly generate an assignment. This happens during a window after a restart when TS is trying to set up the WCCP view while the router has not yet realized TS has restarted. The client WCCP logic then soft stalls and doesn't generate a new assignement when the router responses are processed. -- 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-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-947:
--
Assignee: John Plevyak (was: Alan M. Carroll)
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
>Assignee: John Plevyak
> Fix For: 3.1.2
>
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {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-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131692#comment-13131692
]
Alan M. Carroll commented on TS-947:
The timed wait fix was put on trunk, which ameliorates this problem. However,
the mailing list consensus was that this is a hack and the queuing logic should
be fixed to be correct. John Pleyvack has volunteered to take lead on that
although he welcomes contributions from others.
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
>Assignee: Alan M. Carroll
> Fix For: 3.1.2
>
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {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] [Issue Comment Edited] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131692#comment-13131692
]
Alan M. Carroll edited comment on TS-947 at 10/20/11 3:34 PM:
--
The timed wait fix was put on trunk, which ameliorates this problem. However,
the mailing list consensus was that this is a hack and the queuing logic should
be fixed to be correct. John Pleyvak has volunteered to take lead on that
although he welcomes contributions from others.
was (Author: amc):
The timed wait fix was put on trunk, which ameliorates this problem.
However, the mailing list consensus was that this is a hack and the queuing
logic should be fixed to be correct. John Pleyvack has volunteered to take lead
on that although he welcomes contributions from others.
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
>Assignee: John Plevyak
> Fix For: 3.1.2
>
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {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] [Created] (TS-990) IPv6 support for clustering
IPv6 support for clustering --- Key: TS-990 URL: https://issues.apache.org/jira/browse/TS-990 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.2 Update clustering to be IPv6 compatible. -- 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-988) Upgrade ICP support for IPv6
[ https://issues.apache.org/jira/browse/TS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-988: --- Labels: icp ipv6 (was: ) > Upgrade ICP support for IPv6 > > > Key: TS-988 > URL: https://issues.apache.org/jira/browse/TS-988 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Affects Versions: 3.1.0 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: icp, ipv6 > Fix For: 3.1.2 > > > Make ICP compatible with IPv6. -- 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-988) Upgrade ICP support for IPv6
Upgrade ICP support for IPv6 Key: TS-988 URL: https://issues.apache.org/jira/browse/TS-988 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.2 Make ICP compatible with IPv6. -- 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-989) Update logging to be IPv6 compatible.
Update logging to be IPv6 compatible. - Key: TS-989 URL: https://issues.apache.org/jira/browse/TS-989 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.2 Change logging to support IPv6 data. -- 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-987) Documentation for performance statistics
Documentation for performance statistics Key: TS-987 URL: https://issues.apache.org/jira/browse/TS-987 Project: Traffic Server Issue Type: Task Components: Documentation Reporter: Conan Wang Priority: Trivial need documentation for running statistics. statistics list: http://svn.apache.org/repos/asf/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/traffic-line-commands/index.en.mdtext such as `proxy.process.http.response_document_size_10K`, we don't know the value is count or what. -- 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
