[jira] [Assigned] (TS-1168) Remap blind tunnel handling is not IPv6 compliant
[ https://issues.apache.org/jira/browse/TS-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1168: --- Assignee: Alan M. Carroll > Remap blind tunnel handling is not IPv6 compliant > - > > Key: TS-1168 > URL: https://issues.apache.org/jira/browse/TS-1168 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.3 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: blind, ipv6, remap, tunnel > Fix For: 3.1.4 > > > When a blind tunnel request is received, the hostname is set as the IP > address. This is hardwired for IPv4. ink_gethostbyname should be replaced by > getaddrinfo and the logic made IPv6 compliant. -- 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-1167) proxy/ParentSelection.cc is not IPv6 compliant.
[ https://issues.apache.org/jira/browse/TS-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1167: --- Assignee: Alan M. Carroll > proxy/ParentSelection.cc is not IPv6 compliant. > --- > > Key: TS-1167 > URL: https://issues.apache.org/jira/browse/TS-1167 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Affects Versions: 3.1.3 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Labels: ipv6, parent, socks > Fix For: 3.1.4 > > > setup_socks_servers is IPv4 only. It should be changed to use getaddrinfo() > and handle IPv6 addresses. This may require changing ParentRecord. -- 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-1165) Health checks not working
[ https://issues.apache.org/jira/browse/TS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1165: --- Assignee: Alan M. Carroll > Health checks not working > - > > Key: TS-1165 > URL: https://issues.apache.org/jira/browse/TS-1165 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.3 >Reporter: Igor Brezac >Assignee: Alan M. Carroll > Fix For: 3.1.4 > > > Health checks not working -- 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-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1089: --- Assignee: Alan M. Carroll > Allow Plugins to create transparent internal http connections > - > > Key: TS-1089 > URL: https://issues.apache.org/jira/browse/TS-1089 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 3.1.0 > Environment: This feature was built on top of a 3.1.0 release > candidate. Unfortunately, it will superficially conflict with the IPv6 > changes (I'm including it in case someone needs to update it before I do) >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.1.2 > > Attachments: trans-pluginvc.patch > > > Plugins can create a fake connection HTTP connection into the proxy and > provide a logging address. This feature allows those connections to appear > to the rest of trafficsever as incoming transparent connections (such as the > ones accepted by tproxy enabled installations). -- 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-1088) Allow Per-transaction Transparency (TProxy) Override
[ https://issues.apache.org/jira/browse/TS-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1088: --- Assignee: Alan M. Carroll > Allow Per-transaction Transparency (TProxy) Override > > > Key: TS-1088 > URL: https://issues.apache.org/jira/browse/TS-1088 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, TS API >Affects Versions: 3.1.0 > Environment: The feature was built on top of a 3.1.0 release > candidate, however only minor adjustments are needed for HEAD >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.1.2 > > Attachments: tsapi-allow-transparency.patch > > > Address level transparency (using TProxy) is propagated forward from the > incoming connection based on global configuration. This feature allows > internal and external systems that use the TS api to "disable" propagation on > a per transaction basis. The result is that the client<=>proxy connection > transparently appears as a client<=>origin server connection and the > proxy<=>origin server connection is opaque. -- 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] [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: 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: 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] [Assigned] (TS-698) LogFilter should support an actual IP type and matching rules
[
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-698:
--
Assignee: Alan M. Carroll
> LogFilter should support an actual IP type and matching rules
> -
>
> Key: TS-698
> URL: https://issues.apache.org/jira/browse/TS-698
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.1.6
> Environment: N/A
>Reporter: Eric Connell
>Assignee: Alan M. Carroll
>Priority: Minor
> Fix For: 3.3.0
>
>
> The LogFilter configuration in logs_xml.config should support a native IPv4
> and IPv6 filtering. For example, it would be handy to be able to filter out
> log lines from a specific server or netblock. For example, the following
> config would reject log lines for all hosts in the 10/8 network:
> {code}
>
>
>
>
>
>
>
>
> "/>
>
>
>
>
>
>
> {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
