[jira] [Assigned] (TS-2082) Remove NON_MODULAR #ifdef and others
[
https://issues.apache.org/jira/browse/TS-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-2082:
-
Assignee: Zhao Yongming
Remove NON_MODULAR #ifdef and others
Key: TS-2082
URL: https://issues.apache.org/jira/browse/TS-2082
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Zhao Yongming
Labels: cleanup
Fix For: 5.0.0
Attachments: 0001-fix-build-with-enable-standalone-iocore.patch
{code}
#if TS_HAS_STANDALONE_IOCORE
# define STANDALONE_IOCORE 1
#else
# define FIXME_NONMODULAR 1
# define SPLIT_DNS 1
# define NON_MODULAR1
# define HTTP_CACHE 1
#endif
{code}
all those ifdefine states relate to some work to make iocore portable to
other project, that we don't have any interest right now.
I think all those define should be cleanup to make codes alive, and we do not
need to make a stand alone library right now. when we need to make the iocore
into a library, we don't use #ifdefine.
let us nuke them
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2082) Remove NON_MODULAR #ifdef and others
[
https://issues.apache.org/jira/browse/TS-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-2082:
--
Attachment: 0002-TS-2082-remove-NON_MODULAR-define.patch
0001-TS-2082-remove-STANDALONE_IOCORE-defines.patch
Remove NON_MODULAR #ifdef and others
Key: TS-2082
URL: https://issues.apache.org/jira/browse/TS-2082
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Zhao Yongming
Labels: cleanup
Fix For: 5.0.0
Attachments: 0001-TS-2082-remove-STANDALONE_IOCORE-defines.patch,
0001-fix-build-with-enable-standalone-iocore.patch,
0002-TS-2082-remove-NON_MODULAR-define.patch
{code}
#if TS_HAS_STANDALONE_IOCORE
# define STANDALONE_IOCORE 1
#else
# define FIXME_NONMODULAR 1
# define SPLIT_DNS 1
# define NON_MODULAR1
# define HTTP_CACHE 1
#endif
{code}
all those ifdefine states relate to some work to make iocore portable to
other project, that we don't have any interest right now.
I think all those define should be cleanup to make codes alive, and we do not
need to make a stand alone library right now. when we need to make the iocore
into a library, we don't use #ifdefine.
let us nuke them
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2082) Remove NON_MODULAR #ifdef and others
[
https://issues.apache.org/jira/browse/TS-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815971#comment-13815971
]
Zhao Yongming commented on TS-2082:
---
the next step is to remove HTTP_CACHE SPLIT_DNS and FIXME_NONMODULAR defines.
but for HTTP_CACHE, there the code is something good when you can find out
which parts is not following the origin desgin or distinct from the other
parts, it will easy the task when we need to split the big components into
small ones
Remove NON_MODULAR #ifdef and others
Key: TS-2082
URL: https://issues.apache.org/jira/browse/TS-2082
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Zhao Yongming
Labels: cleanup
Fix For: 5.0.0
Attachments: 0001-TS-2082-remove-STANDALONE_IOCORE-defines.patch,
0001-fix-build-with-enable-standalone-iocore.patch,
0002-TS-2082-remove-NON_MODULAR-define.patch
{code}
#if TS_HAS_STANDALONE_IOCORE
# define STANDALONE_IOCORE 1
#else
# define FIXME_NONMODULAR 1
# define SPLIT_DNS 1
# define NON_MODULAR1
# define HTTP_CACHE 1
#endif
{code}
all those ifdefine states relate to some work to make iocore portable to
other project, that we don't have any interest right now.
I think all those define should be cleanup to make codes alive, and we do not
need to make a stand alone library right now. when we need to make the iocore
into a library, we don't use #ifdefine.
let us nuke them
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2328) Document failover for logging system
[ https://issues.apache.org/jira/browse/TS-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-2328: --- Assignee: Yunkai Zhang Document failover for logging system Key: TS-2328 URL: https://issues.apache.org/jira/browse/TS-2328 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation, Logging Reporter: Igor Galić Assignee: Yunkai Zhang TS-2259 creates a new feature, but only documents it in the configuration file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2328) Document failover for logging system
[ https://issues.apache.org/jira/browse/TS-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-2328: --- Affects Version/s: 4.1.0 Document failover for logging system Key: TS-2328 URL: https://issues.apache.org/jira/browse/TS-2328 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation, Logging Affects Versions: 4.1.0 Reporter: Igor Galić Assignee: Yunkai Zhang Fix For: 4.2.0 TS-2259 creates a new feature, but only documents it in the configuration file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2328) Document failover for logging system
Igor Galić created TS-2328: -- Summary: Document failover for logging system Key: TS-2328 URL: https://issues.apache.org/jira/browse/TS-2328 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation, Logging Reporter: Igor Galić TS-2259 creates a new feature, but only documents it in the configuration file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2259) Introduce failover for logging system
[
https://issues.apache.org/jira/browse/TS-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815997#comment-13815997
]
Igor Galić commented on TS-2259:
This also needs to be documented in the reference configuration for
logs_xml.config
Introduce failover for logging system
-
Key: TS-2259
URL: https://issues.apache.org/jira/browse/TS-2259
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.1.0
Attachments:
0001-TS-2259-Introduce-failover-hosts-for-logging-system.V2.patch,
0001-TS-2259-Introduce-failover-hosts-for-logging-system.patch
I have submitted a patch which will introduce failover hosts for collation
host by using '|' delimiter
to extend CollationHosts tags in logs_xml.config.
Let me give an example:
{code}
CollationHosts = host1:5000|host2:5000|host3:6000, 209.131.52.129:6000/
{code}
In the example above, host2/host3 are failover hosts for host1. When host1
disconnected, log entries will be sent to host2, and then if host2 failed
again,
log entries will be sent to host3 until host1 or host2 comes back.
Let's give another more complex example:
{code}
CollationHosts = host1|host2|host3, host4|host5
{code}
In this example, there are two host groups: (host1|host2|host3) and
(host4|host5),
1) host2/host3 are failover hosts for host1,
2) host5 is failover host for host4.
All log entries will be both send to these two host groups, but in each
group, log entries will only be sent to the first connected host.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2329) Document header_rewrite's ability to set overridable configurations
Igor Galić created TS-2329: -- Summary: Document header_rewrite's ability to set overridable configurations Key: TS-2329 URL: https://issues.apache.org/jira/browse/TS-2329 Project: Traffic Server Issue Type: Bug Components: Documentation, Plugins Reporter: Igor Galić This plugin contains a README, but we should probably drop that in favour of the reference documentation for the plugin. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2329) Document header_rewrite's ability to set overridable configurations
[ https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-2329: --- Affects Version/s: 4.2.0 Document header_rewrite's ability to set overridable configurations Key: TS-2329 URL: https://issues.apache.org/jira/browse/TS-2329 Project: Traffic Server Issue Type: Bug Components: Documentation, Plugins Affects Versions: 4.2.0 Reporter: Igor Galić This plugin contains a README, but we should probably drop that in favour of the reference documentation for the plugin. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2329) Document header_rewrite's ability to set overridable configurations
[ https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-2329: --- Assignee: Leif Hedstrom Document header_rewrite's ability to set overridable configurations Key: TS-2329 URL: https://issues.apache.org/jira/browse/TS-2329 Project: Traffic Server Issue Type: Bug Components: Documentation, Plugins Affects Versions: 4.2.0 Reporter: Igor Galić Assignee: Leif Hedstrom This plugin contains a README, but we should probably drop that in favour of the reference documentation for the plugin. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2330) Update proxy.config.body_factory.enable_customizations comments in records.config
David Carlin created TS-2330:
Summary: Update proxy.config.body_factory.enable_customizations
comments in records.config
Key: TS-2330
URL: https://issues.apache.org/jira/browse/TS-2330
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
The comments in records.config for
proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes -
remove any mention of option 0.
{quote}
##
#
# Customizable User Response Pages
#
##
# 0 - turn off customizable user response pages
# 1 - enable customizable user response pages in only the default directory
# 2 - enable language-targeted user response pages
CONFIG proxy.config.body_factory.enable_customizations INT 1
{quote}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2330) Update proxy.config.body_factory.enable_customizations comments in records.config
[
https://issues.apache.org/jira/browse/TS-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2330:
-
Description:
The comments in records.config for
proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes -
remove any mention of option 0.
{noformat}
##
#
# Customizable User Response Pages
#
##
# 0 - turn off customizable user response pages
# 1 - enable customizable user response pages in only the default directory
# 2 - enable language-targeted user response pages
CONFIG proxy.config.body_factory.enable_customizations INT 1
{noformat}
was:
The comments in records.config for
proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes -
remove any mention of option 0.
{quote}
##
#
# Customizable User Response Pages
#
##
# 0 - turn off customizable user response pages
# 1 - enable customizable user response pages in only the default directory
# 2 - enable language-targeted user response pages
CONFIG proxy.config.body_factory.enable_customizations INT 1
{quote}
Update proxy.config.body_factory.enable_customizations comments in
records.config
-
Key: TS-2330
URL: https://issues.apache.org/jira/browse/TS-2330
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
The comments in records.config for
proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes
- remove any mention of option 0.
{noformat}
##
#
# Customizable User Response Pages
#
##
# 0 - turn off customizable user response pages
# 1 - enable customizable user response pages in only the default
directory
# 2 - enable language-targeted user response pages
CONFIG proxy.config.body_factory.enable_customizations INT 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2330) Update proxy.config.body_factory.enable_customizations comments in records.config
[
https://issues.apache.org/jira/browse/TS-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2330:
-
Affects Version/s: 4.1.0
Update proxy.config.body_factory.enable_customizations comments in
records.config
-
Key: TS-2330
URL: https://issues.apache.org/jira/browse/TS-2330
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 4.1.0
Reporter: David Carlin
The comments in records.config for
proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes
- remove any mention of option 0.
{noformat}
##
#
# Customizable User Response Pages
#
##
# 0 - turn off customizable user response pages
# 1 - enable customizable user response pages in only the default
directory
# 2 - enable language-targeted user response pages
CONFIG proxy.config.body_factory.enable_customizations INT 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2331) Build issue on Ubuntu 12.04: conversion error in ink_gethostbyname_r()
Igor Galić created TS-2331:
--
Summary: Build issue on Ubuntu 12.04: conversion error in
ink_gethostbyname_r()
Key: TS-2331
URL: https://issues.apache.org/jira/browse/TS-2331
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Igor Galić
{code}
CXX ink_inet.lo
ink_inet.cc: In function 'hostent* ink_gethostbyname_r(char*,
ink_gethostbyname_r_data*)':
ink_inet.cc:61:52: error: cannot convert 'int*' to 'hostent**' for argument '5'
to 'int gethostbyname_r(const char*, hostent*, char*, size_t, hostent**, int*)'
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:86:52: error: cannot convert 'int*' to 'hostent**' for argument '7'
to 'int gethostbyaddr_r(const void*, __socklen_t, int, hostent*, char*, size_t,
hostent**, int*)'
make[5]: *** [ink_inet.lo] Error 1
make[5]: Leaving directory `/build/trafficserver/lib/ts'
make[4]: *** [all] Error 2
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-1468) vary and accept* are ignored in cache for non-200 responses from the origin - webdav
[ https://issues.apache.org/jira/browse/TS-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1468: --- Attachment: ts1468.diff vary and accept* are ignored in cache for non-200 responses from the origin - webdav Key: TS-1468 URL: https://issues.apache.org/jira/browse/TS-1468 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0, 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: 4.2.0 Attachments: ts1468.diff ATS doesn't look at the Accept* and vary headers when trying to find an alternate in cache for non-200 responses from the origin. Webdav is effected because of 207 response from the origin and ATS doesn't check the Accept* and vary headers. If there is gzipped data in cache and a non-gzipped request comes in, the gzipped version will be handed back to the client. There is an option for YTS to always look at the Accept* and vary headers, but it is not in ATS. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-1468) vary and accept* are ignored in cache for non-200 responses from the origin - webdav
[ https://issues.apache.org/jira/browse/TS-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1468: --- Attachment: (was: ts1468.diff) vary and accept* are ignored in cache for non-200 responses from the origin - webdav Key: TS-1468 URL: https://issues.apache.org/jira/browse/TS-1468 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0, 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: 4.2.0 Attachments: ts1468.diff ATS doesn't look at the Accept* and vary headers when trying to find an alternate in cache for non-200 responses from the origin. Webdav is effected because of 207 response from the origin and ATS doesn't check the Accept* and vary headers. If there is gzipped data in cache and a non-gzipped request comes in, the gzipped version will be handed back to the client. There is an option for YTS to always look at the Accept* and vary headers, but it is not in ATS. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1468) vary and accept* are ignored in cache for non-200 responses from the origin - webdav
[ https://issues.apache.org/jira/browse/TS-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13816409#comment-13816409 ] Bryan Call commented on TS-1468: Talked to Mark Nottingham about checking Vary and Accept on all response codes (2xx, 3xx, 4xx, 5xx) and he didn't see any issues with it. vary and accept* are ignored in cache for non-200 responses from the origin - webdav Key: TS-1468 URL: https://issues.apache.org/jira/browse/TS-1468 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0, 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: 4.2.0 Attachments: ts1468.diff ATS doesn't look at the Accept* and vary headers when trying to find an alternate in cache for non-200 responses from the origin. Webdav is effected because of 207 response from the origin and ATS doesn't check the Accept* and vary headers. If there is gzipped data in cache and a non-gzipped request comes in, the gzipped version will be handed back to the client. There is an option for YTS to always look at the Accept* and vary headers, but it is not in ATS. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-1800) coalesce FNV hash implementations
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1800: Fix Version/s: (was: 6.0.0) 4.2.0 coalesce FNV hash implementations - Key: TS-1800 URL: https://issues.apache.org/jira/browse/TS-1800 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach Assignee: Phil Sorber Fix For: 4.2.0 We have 4 copies of the FNV hash function: example/query-remap/query-remap.c iocore/hostdb/I_HostDBProcessor.h proxy/hdrs/HdrToken.cc proxy/logstats.cc We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1800) coalesce FNV hash implementations
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13816468#comment-13816468 ] Phil Sorber commented on TS-1800: - I have a WIP patch to add hashing infra that I hope to commit in the near future. coalesce FNV hash implementations - Key: TS-1800 URL: https://issues.apache.org/jira/browse/TS-1800 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach Assignee: Phil Sorber Fix For: 4.2.0 We have 4 copies of the FNV hash function: example/query-remap/query-remap.c iocore/hostdb/I_HostDBProcessor.h proxy/hdrs/HdrToken.cc proxy/logstats.cc We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2331) Build issue on Ubuntu 12.04: conversion error in ink_gethostbyname_r()
[
https://issues.apache.org/jira/browse/TS-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-2331:
---
Affects Version/s: 4.1.0
Build issue on Ubuntu 12.04: conversion error in ink_gethostbyname_r()
--
Key: TS-2331
URL: https://issues.apache.org/jira/browse/TS-2331
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 4.1.0
Reporter: Igor Galić
{code}
CXX ink_inet.lo
ink_inet.cc: In function 'hostent* ink_gethostbyname_r(char*,
ink_gethostbyname_r_data*)':
ink_inet.cc:61:52: error: cannot convert 'int*' to 'hostent**' for argument
'5' to 'int gethostbyname_r(const char*, hostent*, char*, size_t, hostent**,
int*)'
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:86:52: error: cannot convert 'int*' to 'hostent**' for argument
'7' to 'int gethostbyaddr_r(const void*, __socklen_t, int, hostent*, char*,
size_t, hostent**, int*)'
make[5]: *** [ink_inet.lo] Error 1
make[5]: Leaving directory `/build/trafficserver/lib/ts'
make[4]: *** [all] Error 2
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2137) Use eventfd instead of pthread signal/wait in ATS
[
https://issues.apache.org/jira/browse/TS-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-2137:
---
Summary: Use eventfd instead of pthread signal/wait in ATS (was: Use
eventfd instread of pthread signal/wait in ATS)
Use eventfd instead of pthread signal/wait in ATS
-
Key: TS-2137
URL: https://issues.apache.org/jira/browse/TS-2137
Project: Traffic Server
Issue Type: Improvement
Components: Core, Logging, Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments:
0001-TS-2137-Forgot-to-add-header-guide-in-EventNotify.h.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V2.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V3.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V4.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.patch,
eventfd_vs_pthread_cond_benchmark.tar.gz
pthread_cond_signal/wait is used in several places in ATS, including but not
limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() need to take lock, it'll cause more
context switch than eventfd.
I have wrote a simple benchmark program to compare the speed of eventfd and
pthread_cond notify mechanism.
You can get the benchmark program from attachment:
https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz,
and test it by yourself if interesting.
What the program do is that:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop times.
Here is my testing result, the command line argument is loop times(100)
of consumer:
{code}
[eventfd_vs_pthread_cond_benchmark]$ ls
main.cc Makefile
[eventfd_vs_pthread_cond_benchmark]$ make
g++ -g -o eventfd_test main.cc -DHAVE_EVENTFD -lpthread
g++ -g -o pthread_cond_test main.cc -lpthread
[eventfd_vs_pthread_cond_benchmark]$ ls
eventfd_test main.cc Makefile pthread_cond_test
[eventfd_vs_pthread_cond_benchmark]$ time ./eventfd_test 100
real0m11.644s
user0m1.517s
sys 1m31.179s
[eventfd_vs_pthread_cond_benchmark]$ time ./pthread_cond_test 100
real0m57.438s
user0m30.152s
sys 6m7.289s
{code}
We can see that eventfd is about 5 times faster than pthread_cond notify
mechanism.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2332) Add Consistent Hash class to libts
Phil Sorber created TS-2332: --- Summary: Add Consistent Hash class to libts Key: TS-2332 URL: https://issues.apache.org/jira/browse/TS-2332 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber We may have a consistent hash implementation in the cluster code, but we don't have a general one available to libts. We need one to implement a consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2332: Fix Version/s: 4.2.0 Add Consistent Hash class to libts -- Key: TS-2332 URL: https://issues.apache.org/jira/browse/TS-2332 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 4.2.0 We may have a consistent hash implementation in the cluster code, but we don't have a general one available to libts. We need one to implement a consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2137) Use eventfd instead of pthread signal/wait in ATS
[
https://issues.apache.org/jira/browse/TS-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-2137:
---
Description:
pthread_cond_signal/wait is used in several places in ATS, including but not
limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() needs to take a lock. As such it'll cause
more context switches than eventfd.
I wrote a simple benchmark program to compare the speed of eventfd and
pthread_cond notify mechanism.
You can get the benchmark program from the attachment:
https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz,
and test it by yourself if interested.
What the program does is:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop time.
Here is my testing result, the command line argument is loop time(100) of
consumer:
{code}
[eventfd_vs_pthread_cond_benchmark]$ ls
main.cc Makefile
[eventfd_vs_pthread_cond_benchmark]$ make
g++ -g -o eventfd_test main.cc -DHAVE_EVENTFD -lpthread
g++ -g -o pthread_cond_test main.cc -lpthread
[eventfd_vs_pthread_cond_benchmark]$ ls
eventfd_test main.cc Makefile pthread_cond_test
[eventfd_vs_pthread_cond_benchmark]$ time ./eventfd_test 100
real0m11.644s
user0m1.517s
sys 1m31.179s
[eventfd_vs_pthread_cond_benchmark]$ time ./pthread_cond_test 100
real0m57.438s
user0m30.152s
sys 6m7.289s
{code}
We can see that eventfd is about 5 times faster than pthread_cond notify
mechanism.
was:
pthread_cond_signal/wait is used in several places in ATS, including but not
limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() need to take lock, it'll cause more context
switch than eventfd.
I have wrote a simple benchmark program to compare the speed of eventfd and
pthread_cond notify mechanism.
You can get the benchmark program from attachment:
https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz,
and test it by yourself if interesting.
What the program do is that:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop times.
Here is my testing result, the command line argument is loop times(100) of
consumer:
{code}
[eventfd_vs_pthread_cond_benchmark]$ ls
main.cc Makefile
[eventfd_vs_pthread_cond_benchmark]$ make
g++ -g -o eventfd_test main.cc -DHAVE_EVENTFD -lpthread
g++ -g -o pthread_cond_test main.cc -lpthread
[eventfd_vs_pthread_cond_benchmark]$ ls
eventfd_test main.cc Makefile pthread_cond_test
[eventfd_vs_pthread_cond_benchmark]$ time ./eventfd_test 100
real0m11.644s
user0m1.517s
sys 1m31.179s
[eventfd_vs_pthread_cond_benchmark]$ time ./pthread_cond_test 100
real0m57.438s
user0m30.152s
sys 6m7.289s
{code}
We can see that eventfd is about 5 times faster than pthread_cond notify
mechanism.
Use eventfd instead of pthread signal/wait in ATS
-
Key: TS-2137
URL: https://issues.apache.org/jira/browse/TS-2137
Project: Traffic Server
Issue Type: Improvement
Components: Core, Logging, Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments:
0001-TS-2137-Forgot-to-add-header-guide-in-EventNotify.h.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V2.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V3.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V4.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.patch,
eventfd_vs_pthread_cond_benchmark.tar.gz
pthread_cond_signal/wait is used in several places in ATS, including but not
limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() needs to take a lock. As such it'll cause
more context switches than eventfd.
I wrote a simple benchmark program to compare the speed of eventfd and
pthread_cond notify mechanism.
You can get the benchmark program from the attachment:
https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz,
and test it by yourself if interested.
What the program does is:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop time.
Here is my testing result, the command line argument is loop time(100) of
[jira] [Assigned] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2332: --- Assignee: Phil Sorber Add Consistent Hash class to libts -- Key: TS-2332 URL: https://issues.apache.org/jira/browse/TS-2332 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 4.2.0 We may have a consistent hash implementation in the cluster code, but we don't have a general one available to libts. We need one to implement a consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-153: -- Attachment: ts153.diff Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 4.2.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2333) regression in proxy.node.* stats
Igor Galić created TS-2333:
--
Summary: regression in proxy.node.* stats
Key: TS-2333
URL: https://issues.apache.org/jira/browse/TS-2333
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Igor Galić
after upgrade from 4.0.2 to 4.1.0 users report that many {{proxy.node.*}} stats
are broken, and mostly return 0.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2334) --with-tcmalloc does not test whether the found library actually exists
Igor Galić created TS-2334:
--
Summary: --with-tcmalloc does not test whether the found library
actually exists
Key: TS-2334
URL: https://issues.apache.org/jira/browse/TS-2334
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Igor Galić
Our {{TS_CHECK_TCMALLOC}} does not work.
I found this when compiling --with-tcmalloc on Ubuntu, where the {{tcmalloc}}
library is called {{tcmalloc_minimal}}. (And its corresponding -dev package,
will, intuitively be named {{libgoogle-perftools-dev}}. )
But none of this actually matters. I don't need to have any tcmalloc libraries
installed for this to fail horribly: {{-ltcmalloc}} will be added to the build
simply because I specified {{--with-tcmalloc}} this causes pretty much
everything in the configure run to break, or at least run with defaults. (e.g.:
glibc2 is not recognized to have a reentrant {{gethostbyname()}})
proposal: ACTUALLY check if {{tcmalloc}} can be found, abort {{configure}} if
it can't.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2334) --with-tcmalloc does not test whether the found library actually exists
[
https://issues.apache.org/jira/browse/TS-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-2334:
---
Affects Version/s: 4.2.0
4.1.0
--with-tcmalloc does not test whether the found library actually exists
-
Key: TS-2334
URL: https://issues.apache.org/jira/browse/TS-2334
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 4.1.0, 4.2.0
Reporter: Igor Galić
Our {{TS_CHECK_TCMALLOC}} does not work.
I found this when compiling --with-tcmalloc on Ubuntu, where the {{tcmalloc}}
library is called {{tcmalloc_minimal}}. (And its corresponding -dev package,
will, intuitively be named {{libgoogle-perftools-dev}}. )
But none of this actually matters. I don't need to have any tcmalloc
libraries installed for this to fail horribly: {{-ltcmalloc}} will be added
to the build simply because I specified {{--with-tcmalloc}} this causes
pretty much everything in the configure run to break, or at least run with
defaults. (e.g.: glibc2 is not recognized to have a reentrant
{{gethostbyname()}})
proposal: ACTUALLY check if {{tcmalloc}} can be found, abort {{configure}} if
it can't.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
