[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
[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] [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-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] [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-tabpanelfocusedCommentId=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()))
Bbreak;
...
service request
...
} while (1);
Cink_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)) {
Dink_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] [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()))
Bbreak;
...
service request
...
} while (1);
Cink_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)) {
Dink_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-tabpanelfocusedCommentId=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()))
Bbreak;
...
service request
...
} while (1);
Cink_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)) {
Dink_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] [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-tabpanelfocusedCommentId=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()))
Bbreak;
...
service request
...
} while (1);
Cink_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)) {
Dink_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] [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-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-tabpanelfocusedCommentId=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-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] [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] [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] [Commented] (TS-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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] [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-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
