[jira] [Created] (TS-3553) Fix illumos build
Eric Sproul created TS-3553: --- Summary: Fix illumos build Key: TS-3553 URL: https://issues.apache.org/jira/browse/TS-3553 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Eric Sproul Have hit numerous issues building 5.3-rc2 on an illumos platform (OmniOS r151014). This issue should reference efforts to correct these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509160#comment-14509160 ] Susan Hinrichs commented on TS-3547: I think I see why the system isn't coalescing SSL_write blocks. We call SSL_write from SSLWriteBuffer() in SSLUtils.c After the SSL_write, we call BIO_flush, which I assume will force out a packet. Instead, we should move the BIO_flush call to the end of SSLNetVConnection::load_buffer_and_write() after all the queued up blocks have been written via SSLWriteBuffer. I'll experiment on my own with this, but since [~jacksontj] can exercise this problem at will, thought you might want to experiment in parallel. SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3552) TSHttpTxnServerRespNoStoreSet() does not always work as expected
[ https://issues.apache.org/jira/browse/TS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3552: - Assignee: Leif Hedstrom TSHttpTxnServerRespNoStoreSet() does not always work as expected Key: TS-3552 URL: https://issues.apache.org/jira/browse/TS-3552 Project: Traffic Server Issue Type: Bug Components: Core, TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 In particular, HttpTransact::is_response_cacheable() checks this flag too late, which means other checks can mark the response cacheable even when the API above is used in a plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3552) TSHttpTxnServerRespNoStoreSet() does not always work as expected
[ https://issues.apache.org/jira/browse/TS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3552: -- Labels: A (was: ) TSHttpTxnServerRespNoStoreSet() does not always work as expected Key: TS-3552 URL: https://issues.apache.org/jira/browse/TS-3552 Project: Traffic Server Issue Type: Bug Components: Core, TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 In particular, HttpTransact::is_response_cacheable() checks this flag too late, which means other checks can mark the response cacheable even when the API above is used in a plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3552) TSHttpTxnServerRespNoStoreSet() does not always work as expected
Leif Hedstrom created TS-3552: - Summary: TSHttpTxnServerRespNoStoreSet() does not always work as expected Key: TS-3552 URL: https://issues.apache.org/jira/browse/TS-3552 Project: Traffic Server Issue Type: Bug Components: Core, TS API Reporter: Leif Hedstrom In particular, HttpTransact::is_response_cacheable() checks this flag too late, which means other checks can mark the response cacheable even when the API above is used in a plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3552) TSHttpTxnServerRespNoStoreSet() does not always work as expected
[ https://issues.apache.org/jira/browse/TS-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3552: -- Fix Version/s: 6.0.0 TSHttpTxnServerRespNoStoreSet() does not always work as expected Key: TS-3552 URL: https://issues.apache.org/jira/browse/TS-3552 Project: Traffic Server Issue Type: Bug Components: Core, TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 In particular, HttpTransact::is_response_cacheable() checks this flag too late, which means other checks can mark the response cacheable even when the API above is used in a plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3551:
Fix Version/s: 5.3.0
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 5.3.0, 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3551:
Backport to Version: (was: 5.3.0)
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 5.3.0, 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3553) Fix illumos build
[ https://issues.apache.org/jira/browse/TS-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509274#comment-14509274 ] Eric Sproul commented on TS-3553: - Linking previous issues into this catch-all. Fix illumos build - Key: TS-3553 URL: https://issues.apache.org/jira/browse/TS-3553 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Eric Sproul Have hit numerous issues building 5.3-rc2 on an illumos platform (OmniOS r151014). This issue should reference efforts to correct these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3551:
Backport to Version: 5.3.0
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3548) psiginfo differs on illumos vs. Linux
[
https://issues.apache.org/jira/browse/TS-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3548:
Backport to Version: (was: 5.3.0)
psiginfo differs on illumos vs. Linux
-
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
Assignee: James Peach
Fix For: 5.3.0, 6.0.0
The arguments to psiginfo() are different on illumos platforms such as
OmniOS. This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-3551.
-
Resolution: Fixed
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 5.3.0, 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3548) psiginfo differs on illumos vs. Linux
[
https://issues.apache.org/jira/browse/TS-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3548:
Fix Version/s: 5.3.0
psiginfo differs on illumos vs. Linux
-
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
Assignee: James Peach
Fix For: 5.3.0, 6.0.0
The arguments to psiginfo() are different on illumos platforms such as
OmniOS. This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509249#comment-14509249
]
ASF subversion and git services commented on TS-3551:
-
Commit 6f4bea0b7e736454cb8697f29ba2b398ab8a0f77 in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f4bea0 ]
TS-3551: Fix LogUtils.cc compile on Illumos
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3553) Fix illumos build
[ https://issues.apache.org/jira/browse/TS-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3553: Fix Version/s: 6.0.0 5.3.0 Fix illumos build - Key: TS-3553 URL: https://issues.apache.org/jira/browse/TS-3553 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Eric Sproul Fix For: 5.3.0, 6.0.0 Have hit numerous issues building 5.3-rc2 on an illumos platform (OmniOS r151014). This issue should reference efforts to correct these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3553) Fix illumos build
[ https://issues.apache.org/jira/browse/TS-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509300#comment-14509300 ] Phil Sorber commented on TS-3553: - This also covers commits a777a14a03d278623f31baa48ee5f8f03f5dec08 and 172db8e1c376a3cb29811967e4090e83c343f53b. Fix illumos build - Key: TS-3553 URL: https://issues.apache.org/jira/browse/TS-3553 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Eric Sproul Fix For: 5.3.0, 6.0.0 Have hit numerous issues building 5.3-rc2 on an illumos platform (OmniOS r151014). This issue should reference efforts to correct these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3553) Fix illumos build
[ https://issues.apache.org/jira/browse/TS-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-3553. - Resolution: Fixed Assignee: Phil Sorber Fix illumos build - Key: TS-3553 URL: https://issues.apache.org/jira/browse/TS-3553 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Eric Sproul Assignee: Phil Sorber Fix For: 5.3.0, 6.0.0 Have hit numerous issues building 5.3-rc2 on an illumos platform (OmniOS r151014). This issue should reference efforts to correct these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3551:
Fix Version/s: 6.0.0
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3551) LogUtils.cc does not compile on Illumos
[
https://issues.apache.org/jira/browse/TS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-3551:
---
Assignee: Phil Sorber
LogUtils.cc does not compile on Illumos
---
Key: TS-3551
URL: https://issues.apache.org/jira/browse/TS-3551
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Phil Sorber
Assignee: Phil Sorber
Fix For: 6.0.0
{noformat}
gmake[2]: Entering directory
`/tmp/build_esproul/trafficserver-5.3.0/proxy/logging'
CXX Log.o
CXX LogAccess.o
CXX LogAccessHttp.o
CXX LogAccessICP.o
CXX LogBuffer.o
CXX LogConfig.o
CXX LogField.o
CXX LogFieldAliasMap.o
CXX LogFile.o
CXX LogFilter.o
CXX LogFormat.o
CXX LogHost.o
CXX LogObject.o
CXX LogPredefined.o
CXX LogSock.o
CXX LogUtils.o
CXX LogCollationAccept.o
CXX LogCollationClientSM.o
CXX LogCollationHostSM.o
LogUtils.cc: In function 'char* LogUtils::timestamp_to_netscape_str(long
int)':
LogUtils.cc:106:23: error: 'struct std::tm' has no member named 'tm_gmtoff'
long zone = -tms-tm_gmtoff; // double negative!
^
gmake[2]: *** [LogUtils.o] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3544) traffic_logcat asserts when fmt_buf_bytes = 0
[
https://issues.apache.org/jira/browse/TS-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Feltner updated TS-3544:
---
Backport to Version: (was: 5.3.0)
traffic_logcat asserts when fmt_buf_bytes = 0
-
Key: TS-3544
URL: https://issues.apache.org/jira/browse/TS-3544
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Steven Feltner
Labels: crash
Fix For: 6.0.0
While reading a 766MB squid.blog, traffic_logcat seg faults.
Here is a live gdb session:
1429614621.421 4 173.252.120.113 TCP_MISS/200 6392 GET http://72.167.230.251/
- DIRECT/72.167.230.251 text/html
1429614621.428 3 197.232.18.238 TCP_MISS/200 3663 GET
http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.mi
FATAL: LogFile.cc:541: failed assert `fmt_line_bytes 0`
Program received signal SIGABRT, Aborted.
0x003949832625 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-3.el6_5.x86_64
keyuibselinux-2.0.94-5.8.el6.x86_64 libstdc++-4.4.7-11.el6.x86_64
libxml2-2.7.6-17.el6_6.1.x86_64 nss-softokn-freebl-re-7.8-6.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64
zlib-1.2.3-29.el6.x86_
(gdb) bt full
#0 0x003949832625 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x003949833e05 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x003057e2705a in ink_die_die_die (fmt=0x3057e333a8 %s:%d: failed
assert `%s`, ap=0x7ffe6b40) at in
No locals.
#3 ink_fatal_va(const char *, typedef __va_list_tag __va_list_tag *)
(fmt=0x3057e333a8 %s:%d: failed assert `%s
msg = FATAL: LogFile.cc:541: failed assert `fmt_line_bytes 0`,
'\000' repeats 966 times
#4 0x003057e270ed in ink_fatal (message_format=0x10c5f Address 0x10c5f
out of bounds) at ink_error.cc:73
ap = {{gp_offset = 32, fp_offset = 48, overflow_arg_area =
0x7ffe6c20, reg_save_area = 0x7ffe6b60
#5 0x003057e24a05 in _ink_assert (expression=0x Address
0x out of bounds,
No locals.
#6 0x00431544 in LogFile::write_ascii_logbuffer
(buffer_header=0x7ffee4f0, fd=1, path=0x460c6f .,
iter = {m_in_network_order = false, m_next = 0x7fff3150
\035\060\066U, m_iter_entry_count = 1, m_bu
fmt_line_bytes = 0
fmt_buf = 1429614620.635 1 198.58.10.197 TCP_MISS/200 3926 GET
http://72.167.243.35/times/vasco.png - DI
format_type = LOG_FORMAT_CUSTOM
__func__ = write_ascii_logbuffer
fmt_line = 1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET
http://50.62.195.13/wp-includes/js/jque
entry_header = value optimized out
fmt_buf_bytes = 0
bytes = 0
fieldlist_str = 0x7ffee536
cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct
printf_str = 0x7ffee56f \377 \377 \377 \377/\377 \377 \377 \377
\377 \377/\377 \377
#7 0x0041b258 in process_file (in_fd=12, out_fd=1) at logcat.cc:164
first_read_size = 8
header_size = 64
byte_count = value optimized out
header = 0x7ffee4f0
second_read_size = 56
alt_format = 0x0
buffer =
\316\372\316\n\002\000\000\000\004\000\000\000\310g\000\000%\000\000\000\035\060\066U\036\060\\000\000squid\000cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct\000\377
\377 \377 \377/\377 \377
\37K\000\000\000\000\000\000\000\000\000\000\v\000\000\000\000\000\000\000\002\000+\222h\354Fn3\000\000\000\000\000\
buffer_bytes = value optimized out
bytes = value optimized out
__func__ = process_file
nread = 26504
#8 0x0041b4f7 in main (argv=value optimized out) at logcat.cc:297
in_fd = 12
i = value optimized out
out_fd = 1
error = value optimized out
(gdb) frame 6
#6 0x00431544 in LogFile::write_ascii_logbuffer
(buffer_header=0x7ffee4f0, fd=1, path=0x460c6f ., alt_format=0x0) at
LogFile.cc:541
541 ink_assert(fmt_line_bytes 0);
(gdb) p fmt_line_bytes
$1 = 0
(gdb) entry_header
Undefined command: entry_header. Try help.
(gdb) p entry_header
$2 = value optimized out
(gdb) p *entry_header
value has been optimized out
(gdb) p entry_header-entry_len
value has been optimized out
(gdb) set print elements 0
(gdb) p fmt_line
$3 = 1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET
http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.2.1 -
DIRECT/50.62.195.13
application/javascriptplication/x-font-woffion/javascriptT/72.167.243.35
text/html0a62098f_1 - DIRECT/72.167.25.149
[jira] [Commented] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509548#comment-14509548 ] ASF GitHub Bot commented on TS-3427: GitHub user zeb209 opened a pull request: https://github.com/apache/trafficserver/pull/190 Fix the header file missing error for out-of-tree build for cppapi. This pull request replaces the patch for TS-3427. You can merge this pull request into a Git repository by running: $ git pull https://github.com/zeb209/trafficserver cppapi-out-of-tree-build Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/190.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #190 commit bcb692f33fdc8bfdd75c89f700d4ac3f90f90913 Author: Bin Zeng bz...@linkedin.com Date: 2015-04-23T18:22:20Z Fix the header file missing error for out-of-tree build for cppapi. compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508108#comment-14508108 ] Bin edited comment on TS-3427 at 4/23/15 6:34 PM: -- ping. You can also merge the pull request #190 from github. was (Author: bzeng): ping compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
Steven Feltner created TS-3554: -- Summary: ATS memory leak reloading ssl_multicert.config with many ssl cert configs Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3544) traffic_logcat asserts when fmt_buf_bytes = 0
[
https://issues.apache.org/jira/browse/TS-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Feltner updated TS-3544:
---
Backport to Version: 5.3.0
traffic_logcat asserts when fmt_buf_bytes = 0
-
Key: TS-3544
URL: https://issues.apache.org/jira/browse/TS-3544
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Steven Feltner
Labels: crash
Fix For: 6.0.0
While reading a 766MB squid.blog, traffic_logcat seg faults.
Here is a live gdb session:
1429614621.421 4 173.252.120.113 TCP_MISS/200 6392 GET http://72.167.230.251/
- DIRECT/72.167.230.251 text/html
1429614621.428 3 197.232.18.238 TCP_MISS/200 3663 GET
http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.mi
FATAL: LogFile.cc:541: failed assert `fmt_line_bytes 0`
Program received signal SIGABRT, Aborted.
0x003949832625 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-3.el6_5.x86_64
keyuibselinux-2.0.94-5.8.el6.x86_64 libstdc++-4.4.7-11.el6.x86_64
libxml2-2.7.6-17.el6_6.1.x86_64 nss-softokn-freebl-re-7.8-6.el6.x86_64
tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64
zlib-1.2.3-29.el6.x86_
(gdb) bt full
#0 0x003949832625 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x003949833e05 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x003057e2705a in ink_die_die_die (fmt=0x3057e333a8 %s:%d: failed
assert `%s`, ap=0x7ffe6b40) at in
No locals.
#3 ink_fatal_va(const char *, typedef __va_list_tag __va_list_tag *)
(fmt=0x3057e333a8 %s:%d: failed assert `%s
msg = FATAL: LogFile.cc:541: failed assert `fmt_line_bytes 0`,
'\000' repeats 966 times
#4 0x003057e270ed in ink_fatal (message_format=0x10c5f Address 0x10c5f
out of bounds) at ink_error.cc:73
ap = {{gp_offset = 32, fp_offset = 48, overflow_arg_area =
0x7ffe6c20, reg_save_area = 0x7ffe6b60
#5 0x003057e24a05 in _ink_assert (expression=0x Address
0x out of bounds,
No locals.
#6 0x00431544 in LogFile::write_ascii_logbuffer
(buffer_header=0x7ffee4f0, fd=1, path=0x460c6f .,
iter = {m_in_network_order = false, m_next = 0x7fff3150
\035\060\066U, m_iter_entry_count = 1, m_bu
fmt_line_bytes = 0
fmt_buf = 1429614620.635 1 198.58.10.197 TCP_MISS/200 3926 GET
http://72.167.243.35/times/vasco.png - DI
format_type = LOG_FORMAT_CUSTOM
__func__ = write_ascii_logbuffer
fmt_line = 1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET
http://50.62.195.13/wp-includes/js/jque
entry_header = value optimized out
fmt_buf_bytes = 0
bytes = 0
fieldlist_str = 0x7ffee536
cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct
printf_str = 0x7ffee56f \377 \377 \377 \377/\377 \377 \377 \377
\377 \377/\377 \377
#7 0x0041b258 in process_file (in_fd=12, out_fd=1) at logcat.cc:164
first_read_size = 8
header_size = 64
byte_count = value optimized out
header = 0x7ffee4f0
second_read_size = 56
alt_format = 0x0
buffer =
\316\372\316\n\002\000\000\000\004\000\000\000\310g\000\000%\000\000\000\035\060\066U\036\060\\000\000squid\000cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct\000\377
\377 \377 \377/\377 \377
\37K\000\000\000\000\000\000\000\000\000\000\v\000\000\000\000\000\000\000\002\000+\222h\354Fn3\000\000\000\000\000\
buffer_bytes = value optimized out
bytes = value optimized out
__func__ = process_file
nread = 26504
#8 0x0041b4f7 in main (argv=value optimized out) at logcat.cc:297
in_fd = 12
i = value optimized out
out_fd = 1
error = value optimized out
(gdb) frame 6
#6 0x00431544 in LogFile::write_ascii_logbuffer
(buffer_header=0x7ffee4f0, fd=1, path=0x460c6f ., alt_format=0x0) at
LogFile.cc:541
541 ink_assert(fmt_line_bytes 0);
(gdb) p fmt_line_bytes
$1 = 0
(gdb) entry_header
Undefined command: entry_header. Try help.
(gdb) p entry_header
$2 = value optimized out
(gdb) p *entry_header
value has been optimized out
(gdb) p entry_header-entry_len
value has been optimized out
(gdb) set print elements 0
(gdb) p fmt_line
$3 = 1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET
http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.2.1 -
DIRECT/50.62.195.13
application/javascriptplication/x-font-woffion/javascriptT/72.167.243.35
text/html0a62098f_1 - DIRECT/72.167.25.149
[jira] [Updated] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3554: Backport to Version: 5.3.0 ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-3554: --- Assignee: Susan Hinrichs ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3554: Fix Version/s: 6.0.0 ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin updated TS-3427: Attachment: atscppapi_out_of_tree_2.diff compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509519#comment-14509519 ] James Peach commented on TS-3554: - FWIW, I looked at this (or something similar) some time ago I wasn't able to prove there was a leak. However when you get large numbers of certificates, what can happen is that the background certificate stores are released slower than new ones are created. Nothing is leaked, but memory accumulates. ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3554: --- Attachment: ts-3554-53.diff ts-3554-53.diff is a patch against the 5.3.x branch. ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 Attachments: ts-3554-53.diff ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509612#comment-14509612 ] Susan Hinrichs edited comment on TS-3554 at 4/23/15 7:37 PM: - There indeed is a leak. We were missing the release for the SSLCertificateConfig in the ticket callback. I fear that I might have been there last to tidy things up. Replaced the direct acquire/release with a scoped pointer to be more defensive against such ref counting leaks. I also added a config debug tag to print information and config objects are set and released. But James is exactly right that in a high traffic, large certificate situation, it may take quite a while before the release happens. At a minimum the system hard codes in a minute delay before it releases the root count on the old config object. was (Author: shinrich): There indeed is a leak. We were missing the release for the SSLCertificateConfig in the ticket callback. I fear that I might have been there last to tidy things up. Replaced the direct acquire/release with a scoped pointer to be more defensive against such ref counting leaks. I also added a config debug tag to print information and config objects are set and released. But James is exactly right that in a high traffic, large certificate situation, it make take quite a while before the release happens. At a minimum the system hard codes in a minute delay before it releases the root count on the old config object. ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509660#comment-14509660 ] ASF subversion and git services commented on TS-3554: - Commit 98c87ee51b2ad91787b7a9fa2827cab1c03b3d22 in trafficserver's branch refs/heads/master from shinrich [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=98c87ee ] TS-3554: Memory load reloading ssl_multicert.config ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509700#comment-14509700 ] ASF subversion and git services commented on TS-3554: - Commit fad02a76e16cf93be301296d61cccf80e37ccdee in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fad02a7 ] TS-3554 clang-format ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 Attachments: ts-3554-53.diff ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509612#comment-14509612 ] Susan Hinrichs commented on TS-3554: There indeed is a leak. We were missing the release for the SSLCertificateConfig in the ticket callback. I fear that I might have been there last to tidy things up. Replaced the direct acquire/release with a scoped pointer to be more defensive against such ref counting leaks. I also added a config debug tag to print information and config objects are set and released. But James is exactly right that in a high traffic, large certificate situation, it make take quite a while before the release happens. At a minimum the system hard codes in a minute delay before it releases the root count on the old config object. ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3555) Add a new API: TSHttpTxnCacheLookupUrlSet()
[ https://issues.apache.org/jira/browse/TS-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509953#comment-14509953 ] Leif Hedstrom commented on TS-3555: --- Adding this new API is a stop-gap solution to address some of the issues in TS-1118 and https://cwiki.apache.org/confluence/display/TS/Cleanup+of+Cache+URLs Add a new API: TSHttpTxnCacheLookupUrlSet() --- Key: TS-3555 URL: https://issues.apache.org/jira/browse/TS-3555 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 This is the inverse of the existing TSHttpTxnCacheLookupUrlGet(), with the same prototype. The typical use case is to use this new API rather than the old TSCacheUrlSet(), which is inefficient in that it requires a series of step to stringify and then URL parse the string again. Using this API, we avoid both of those steps, and do all work on the cache key (Lookup URL) using normal URL APIs. I will put this through the normal API review process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509928#comment-14509928 ] Brian Geffon commented on TS-3547: -- [~shinrich] That's actually the first thing I tried. I removed the BIO_flush and only called it after all SSL_writes were completed and we still observed the problem. SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3524) Add a log tag to log the lookup_url (cache-key)
[ https://issues.apache.org/jira/browse/TS-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3524: - Assignee: Leif Hedstrom Add a log tag to log the lookup_url (cache-key) --- Key: TS-3524 URL: https://issues.apache.org/jira/browse/TS-3524 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 It would be dandy to be able to log the lookup_url (i.e. the cache key) in a log field. There's existing code in CachePages.cc which shows the cache key in the cache inspector as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3531) cacheurl plugin not working in 5.3.0-5.3.x
[
https://issues.apache.org/jira/browse/TS-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509936#comment-14509936
]
Leif Hedstrom commented on TS-3531:
---
Any updates on this ?
cacheurl plugin not working in 5.3.0-5.3.x
---
Key: TS-3531
URL: https://issues.apache.org/jira/browse/TS-3531
Project: Traffic Server
Issue Type: Bug
Components: Cache, Plugins
Reporter: Faysal Banna
Fix For: 6.0.0
Hi Guys
was working and doing tests on 5.3.0 before i could integrate it in my
production servers, and while doing so i noticed some issues with cacheurl
plugin and maybe other plugins but that i can not confirm.
Here is what my observation was :
in cacheurl.config i have
http://s1.2mdn.net/viewad/4079501/BeitMisk_Spring_160x600_web.gif
http://tested/switched.gif
loaded cacheurl.so cacheurl.config in plugin.config
and i confirm that i get [Apr 18 02:45:54.442] Server {0x2b05b69fba80} DIAG:
(cacheurl) Adding pattern/replacement pair:
'http://s1.2mdn.net/viewad/4079501/BeitMisk_Spring_160x600_web.gif' -
'http://tested/switched.gif'
in traffic.out
which says that the pattern was added correctly
nevertheless when i do curl or wget with xdebug header request
i get :
X-Cache-Key: http://s1.2mdn.net/viewad/4079501/BeitMisk_Spring_160x600_web.gif
meaning that the cacheurl plugin didn't actually do the mapping in any way
possible
Next was testing with 5.2.1 version of ATS to see how things go so i git
cloned it and compiled and ran the same test again
now i get
X-Cache-Key: http://tested/switched.gif
which means that cacheurl in 5.2.1 works while in latest mainstream or 5.3.0
it does not
i shall do further tests and feed you back here
much regards
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3555) Add a new API: TSHttpTxnCacheLookupUrlSet()
[ https://issues.apache.org/jira/browse/TS-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3555: -- Labels: A (was: ) Add a new API: TSHttpTxnCacheLookupUrlSet() --- Key: TS-3555 URL: https://issues.apache.org/jira/browse/TS-3555 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 This is the inverse of the existing TSHttpTxnCacheLookupUrlGet(), with the same prototype. The typical use case is to use this new API rather than the old TSCacheUrlSet(), which is inefficient in that it requires a series of step to stringify and then URL parse the string again. Using this API, we avoid both of those steps, and do all work on the cache key (Lookup URL) using normal URL APIs. I will put this through the normal API review process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3555) Add a new API: TSHttpTxnCacheLookupUrlSet()
Leif Hedstrom created TS-3555: - Summary: Add a new API: TSHttpTxnCacheLookupUrlSet() Key: TS-3555 URL: https://issues.apache.org/jira/browse/TS-3555 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom This is the inverse of the existing TSHttpTxnCacheLookupUrlGet(), with the same prototype. The typical use case is to use this new API rather than the old TSCacheUrlSet(), which is inefficient in that it requires a series of step to stringify and then URL parse the string again. Using this API, we avoid both of those steps, and do all work on the cache key (Lookup URL) using normal URL APIs. I will put this through the normal API review process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3555) Add a new API: TSHttpTxnCacheLookupUrlSet()
[ https://issues.apache.org/jira/browse/TS-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3555: -- Fix Version/s: 6.0.0 Add a new API: TSHttpTxnCacheLookupUrlSet() --- Key: TS-3555 URL: https://issues.apache.org/jira/browse/TS-3555 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 This is the inverse of the existing TSHttpTxnCacheLookupUrlGet(), with the same prototype. The typical use case is to use this new API rather than the old TSCacheUrlSet(), which is inefficient in that it requires a series of step to stringify and then URL parse the string again. Using this API, we avoid both of those steps, and do all work on the cache key (Lookup URL) using normal URL APIs. I will put this through the normal API review process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3555) Add a new API: TSHttpTxnCacheLookupUrlSet()
[ https://issues.apache.org/jira/browse/TS-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3555: - Assignee: Leif Hedstrom Add a new API: TSHttpTxnCacheLookupUrlSet() --- Key: TS-3555 URL: https://issues.apache.org/jira/browse/TS-3555 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 6.0.0 This is the inverse of the existing TSHttpTxnCacheLookupUrlGet(), with the same prototype. The typical use case is to use this new API rather than the old TSCacheUrlSet(), which is inefficient in that it requires a series of step to stringify and then URL parse the string again. Using this API, we avoid both of those steps, and do all work on the cache key (Lookup URL) using normal URL APIs. I will put this through the normal API review process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin updated TS-3427: Attachment: (was: atscppapi_out_of_tree_2.diff) compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3554) ATS memory leak reloading ssl_multicert.config with many ssl cert configs
[ https://issues.apache.org/jira/browse/TS-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509669#comment-14509669 ] Susan Hinrichs commented on TS-3554: You could write a plugin that listens on a socket for updates to the certificate list. This would avoid the complete certificate reload. But if you are adding remap rules too, you'll still need a reload since I don't think you can programatically add/remove remap rules. ATS memory leak reloading ssl_multicert.config with many ssl cert configs - Key: TS-3554 URL: https://issues.apache.org/jira/browse/TS-3554 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, SSL Reporter: Steven Feltner Assignee: Susan Hinrichs Fix For: 6.0.0 ATS will consume all available memory on a server with 128GB of RAM. @shinrich suspects it may be due to CertLookup table not being freed on a config reload. Our current process: - New cert comes in - ssl_multicert.config and remap.config updated - traffic_line -x This reload could occur as often as every 3 mins with 5000+ certs configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3547: Assignee: Brian Geffon SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson Assignee: Brian Geffon UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510104#comment-14510104 ] Brian Geffon commented on TS-3547: -- After further investigation and reading: https://www.openssl.org/docs/crypto/BIO_s_connect.html#EXAMPLE , it appears we shouldn't be mixing BIOs and SSL_write / SSL_reads, I'm thinking about putting a patch together that uses BIOs only. [~shinrich] , any thoughts on this? SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509100#comment-14509100 ] Susan Hinrichs commented on TS-3547: Fiddling with the nagle times as [~sudheerv] suggested might also help. May ultimately need to not use SSL_write but do BIO stuff directly to get the control we need. From chatting with [~jacksontj] last night, it wasn't clear that the separate writes were really causing the delay. It sounded like the delays only occurred if the box was in rotation (under some load). But I see that you guys have done some more experiments since then. If you could share a pcap file of a pathological case, that would be great. Also [~davet] might have some insights. SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508525#comment-14508525 ] daemon commented on TS-3550: OK ，Thanks Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon Assignee: Leif Hedstrom Fix For: 6.0.0 traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3545) Make traffic_line and traffic_ctl more verbose
[ https://issues.apache.org/jira/browse/TS-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3545: -- Component/s: Documentation Make traffic_line and traffic_ctl more verbose -- Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation Reporter: David Carlin Fix For: Docs Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3545) Make traffic_line and traffic_ctl more verbose
[ https://issues.apache.org/jira/browse/TS-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510406#comment-14510406 ] Leif Hedstrom commented on TS-3545: --- Moving to docs for now, move if there are code changes to be made. Make traffic_line and traffic_ctl more verbose -- Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation Reporter: David Carlin Fix For: Docs Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3545) Make traffic_line and traffic_ctl more verbose
[ https://issues.apache.org/jira/browse/TS-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3545: -- Fix Version/s: Docs Make traffic_line and traffic_ctl more verbose -- Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation Reporter: David Carlin Fix For: Docs Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3547: -- Fix Version/s: 6.0.0 SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Components: Network, SSL Reporter: Thomas Jackson Assignee: Brian Geffon Fix For: 6.0.0 UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3547: -- Component/s: SSL Network SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Components: Network, SSL Reporter: Thomas Jackson Assignee: Brian Geffon Fix For: 6.0.0 UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
