[jira] [Commented] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758822#comment-13758822
]
Yunkai Zhang commented on TS-2168:
--
In ./proxy/config/records.config.default.in:
{code}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT @use_reclaimable_freelist@
{code}
When user enable reclaimable freelist, this fix will cause new and more bad
confusion.
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1840) make install requires a compiler
[
https://issues.apache.org/jira/browse/TS-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758845#comment-13758845
]
Igor Galić commented on TS-1840:
I just checked, yes.
make install requires a compiler
Key: TS-1840
URL: https://issues.apache.org/jira/browse/TS-1840
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Fix For: 4.2.0
Are we missing something during the build?
{noformat}
make[2]: Entering directory `/home/igalic/src/asf/trafficserver/mgmt/api'
Making install in remote
make[3]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
make[4]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
/bin/mkdir -p '/opt/ats-trunk/lib'
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libtsmgmt.la '/opt/ats-trunk/lib'
libtool: install: warning: relinking `libtsmgmt.la'
libtool: install: (cd /home/igalic/src/asf/trafficserver/mgmt/api/remote;
/bin/bash /home/igalic/src/asf/trafficserver/libtool --silent --tag CXX
--mode=relink clang++ -std=c++11 -g -O3 -fno-strict-aliasing -Werror
-Qunused-arguments -Wno-invalid-offsetof -version-info 6:3:3 -o libtsmgmt.la
-rpath /opt/ats-trunk/lib CfgContextImpl.lo CfgContextManager.lo
CfgContextUtils.lo CoreAPIShared.lo EventCallback.lo GenericParser.lo
INKMgmtAPI.lo CoreAPIRemote.lo EventRegistration.lo NetworkUtilsRemote.lo
../../../lib/ts/libtsutil.la )
/home/igalic/src/asf/trafficserver/libtool: line 8982: clang++: command not
found
libtool: install: error: relink `libtsmgmt.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758858#comment-13758858 ] Igor Galić commented on TS-1486: should we just silently and slowly phase it out, or get rid of it with a big bang? drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 4.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2168:
-
Attachment: 0001-TS-2168-Use-ifdef-to-control-reclaimable-freelist-op.patch
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
Attachments:
0001-TS-2168-Use-ifdef-to-control-reclaimable-freelist-op.patch
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758887#comment-13758887
]
Yunkai Zhang commented on TS-2168:
--
I submmited a patch to fix inconsistency when enable reclaimable freelist.
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
Attachments:
0001-TS-2168-Use-ifdef-to-control-reclaimable-freelist-op.patch
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2168:
-
Attachment: (was:
0001-TS-2168-Use-ifdef-to-control-reclaimable-freelist-op.patch)
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2168:
-
Attachment: 0001-TS-2168-Use-if-condition-to-control-reclaimable-free.patch
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
Attachments:
0001-TS-2168-Use-if-condition-to-control-reclaimable-free.patch
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758945#comment-13758945
]
ASF subversion and git services commented on TS-2168:
-
Commit 6de8354f20944032fc1ace6559e4bf7bdd1c0186 in branch refs/heads/master
from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6de8354 ]
TS-2168: Use #if condition to control reclaimable freelist options
1) Define reclaimabe freelist options only when compiles ATS
with --enable-reclaimabe-freelist,
2) proxy.config.allocator.enable_reclaim will be set to 1 by default
for two reasons:
a) It should keep consistent with the description in
records.config.default.in: Default 1, reclaim enabled,
b) More important, most users want to get reclaim feature when
they compiles ATS with --enable-reclaimable-freelist.
3) Make the *NOTE description* in records.config.default.in more notable.
Signed-off-by: Yunkai Zhang qiushu@taobao.com
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
Attachments:
0001-TS-2168-Use-if-condition-to-control-reclaimable-free.patch
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759120#comment-13759120 ] Leif Hedstrom commented on TS-1486: --- Well, does it work today? If so, we should get rid of it for 5.0.0, right ? If it doesn't work today, then lets just go wild on it and kick it to the curb. drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 4.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1840) make install requires a compiler
[
https://issues.apache.org/jira/browse/TS-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759124#comment-13759124
]
Leif Hedstrom commented on TS-1840:
---
What's the expectation? How are you getting to a stage where you can run make
install, without having a compiler? :)
make install requires a compiler
Key: TS-1840
URL: https://issues.apache.org/jira/browse/TS-1840
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Fix For: 4.2.0
Are we missing something during the build?
{noformat}
make[2]: Entering directory `/home/igalic/src/asf/trafficserver/mgmt/api'
Making install in remote
make[3]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
make[4]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
/bin/mkdir -p '/opt/ats-trunk/lib'
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libtsmgmt.la '/opt/ats-trunk/lib'
libtool: install: warning: relinking `libtsmgmt.la'
libtool: install: (cd /home/igalic/src/asf/trafficserver/mgmt/api/remote;
/bin/bash /home/igalic/src/asf/trafficserver/libtool --silent --tag CXX
--mode=relink clang++ -std=c++11 -g -O3 -fno-strict-aliasing -Werror
-Qunused-arguments -Wno-invalid-offsetof -version-info 6:3:3 -o libtsmgmt.la
-rpath /opt/ats-trunk/lib CfgContextImpl.lo CfgContextManager.lo
CfgContextUtils.lo CoreAPIShared.lo EventCallback.lo GenericParser.lo
INKMgmtAPI.lo CoreAPIRemote.lo EventRegistration.lo NetworkUtilsRemote.lo
../../../lib/ts/libtsutil.la )
/home/igalic/src/asf/trafficserver/libtool: line 8982: clang++: command not
found
libtool: install: error: relink `libtsmgmt.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759144#comment-13759144 ] Igor Galić commented on TS-1486: testing that right now drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 4.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1840) make install requires a compiler
[
https://issues.apache.org/jira/browse/TS-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759130#comment-13759130
]
Igor Galić commented on TS-1840:
I think the point is, as TS-1489 suggests, to not relink `libtsmgmt.la' --
needing (and on my system not finding ;) a compiler is just a symptom of that.
make install requires a compiler
Key: TS-1840
URL: https://issues.apache.org/jira/browse/TS-1840
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Fix For: 4.2.0
Are we missing something during the build?
{noformat}
make[2]: Entering directory `/home/igalic/src/asf/trafficserver/mgmt/api'
Making install in remote
make[3]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
make[4]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
/bin/mkdir -p '/opt/ats-trunk/lib'
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libtsmgmt.la '/opt/ats-trunk/lib'
libtool: install: warning: relinking `libtsmgmt.la'
libtool: install: (cd /home/igalic/src/asf/trafficserver/mgmt/api/remote;
/bin/bash /home/igalic/src/asf/trafficserver/libtool --silent --tag CXX
--mode=relink clang++ -std=c++11 -g -O3 -fno-strict-aliasing -Werror
-Qunused-arguments -Wno-invalid-offsetof -version-info 6:3:3 -o libtsmgmt.la
-rpath /opt/ats-trunk/lib CfgContextImpl.lo CfgContextManager.lo
CfgContextUtils.lo CoreAPIShared.lo EventCallback.lo GenericParser.lo
INKMgmtAPI.lo CoreAPIRemote.lo EventRegistration.lo NetworkUtilsRemote.lo
../../../lib/ts/libtsutil.la )
/home/igalic/src/asf/trafficserver/libtool: line 8982: clang++: command not
found
libtool: install: error: relink `libtsmgmt.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1882) ATS doesn't warn about unknown config items
[ https://issues.apache.org/jira/browse/TS-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759143#comment-13759143 ] ASF subversion and git services commented on TS-1882: - Commit 03b88fca6fa6e2d5561a78ed055ed247d8001799 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=03b88fc ] TS-2168 Clean up the verbose comments There's not much purpose to repeat the same thing 4 times :). This also fixes a potential problem with debug_filter, since it currently has two bit fields in use, we should allow for values 0-3, right? There's still a huge problem with this code as it is now, because it would make it impossible to implement features that does consistency checks on records.config (see TS-1882). ATS doesn't warn about unknown config items --- Key: TS-1882 URL: https://issues.apache.org/jira/browse/TS-1882 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Ebrahim Mohammadi Assignee: Leif Hedstrom Fix For: 4.2.0 Apache Traffic Server doesn't warn about unknown configuration file items. It can cause huge confusions, specially in case of trying to get features of a newer version to work on an older installed version by mistake, as I found out the hard way! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2168) Confusion about proxy.config.allocator.enable_reclaim setting
[
https://issues.apache.org/jira/browse/TS-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759142#comment-13759142
]
ASF subversion and git services commented on TS-2168:
-
Commit 03b88fca6fa6e2d5561a78ed055ed247d8001799 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=03b88fc ]
TS-2168 Clean up the verbose comments
There's not much purpose to repeat the same thing 4 times :). This
also fixes a potential problem with debug_filter, since it currently
has two bit fields in use, we should allow for values 0-3, right?
There's still a huge problem with this code as it is now, because
it would make it impossible to implement features that does
consistency checks on records.config (see TS-1882).
Confusion about proxy.config.allocator.enable_reclaim setting
-
Key: TS-2168
URL: https://issues.apache.org/jira/browse/TS-2168
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.1.0
Attachments:
0001-TS-2168-Use-if-condition-to-control-reclaimable-free.patch
The default records.config in 4.0.1 says the following which is contradictory:
{noformat}
# The value of enable_reclaim should be 0 or 1. Default 1, reclaim enabled.
CONFIG proxy.config.allocator.enable_reclaim INT 0
{noformat}
mgmt/RecordsConfig.cc shows the following:
{RECT_CONFIG, proxy.config.allocator.enable_reclaim, RECD_INT, 1,
RECU_NULL, RR_NULL, RECC_NULL, [0-1], RECA_NULL}
So the default is 1, but records.config changes it to 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2172) Explicitly use subdir-objects in automake init
[
https://issues.apache.org/jira/browse/TS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759195#comment-13759195
]
James Peach commented on TS-2172:
-
FYI I reverted this change because enabling {{subdir-objects}} breaks {{make
distclean}}. The build farm now tests {{make distclean}} and out of tree
builds, so the next person to take a crack at this will be able to see the
results.
Explicitly use subdir-objects in automake init
--
Key: TS-2172
URL: https://issues.apache.org/jira/browse/TS-2172
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: Li-Wen Hsu
Assignee: Yunkai Zhang
Fix For: 4.1.0
This avoids warnings from automake 1.14:
warning: source file 'foo/bar.c' is in a subdirectory,
but option 'subdir-objects' is disabled
and generates correct configure script.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1411) Seg faulting during log rotation
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759280#comment-13759280
]
David Carlin commented on TS-1411:
--
I applied this patch to four hosts today; I will roll out more next week. It
may take a week or two before I can say if this patch works or not due to the
intermittent nature of the crash.
Thanks Yunkai!
Seg faulting during log rotation
Key: TS-1411
URL: https://issues.apache.org/jira/browse/TS-1411
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: RHEL 6.2 x86_64
Reporter: David Carlin
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include
the unmapped URL and the user agent string:
%cqtq %ttms %chi %crc/%pssc %psql %cqhm %cquc %caun
%phr/%pqsn %psct %xid %cquuc \%{User-Agent}cqh\
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones
seem to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x48)[0x58a118]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x58c3f0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x59d5a2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x6756e7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66e076]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696ce4]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-350) Document new Ram Cache options
[ https://issues.apache.org/jira/browse/TS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-350: - Fix Version/s: (was: Docs) 4.1.0 Assignee: Leif Hedstrom Summary: Document new Ram Cache options (was: new Ram Cache options) Document new Ram Cache options -- Key: TS-350 URL: https://issues.apache.org/jira/browse/TS-350 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 # Replacement algorithm # 0 : Clocked Least Frequently Used by Size (CLFUS) w/optional compression # 1 : LRU w/o optional compression - trivially simple CONFIG proxy.config.cache.ram_cache.algorithm INT 0 # Compress the content of the ram cache: # 0 : no compression # 1 : fastlz (extremely fast, relatively low compression) # 2 : libz (moderate speed, reasonable compression) # 3 : liblzma (very slow, high compression) CONFIG proxy.config.cache.ram_cache.compress INT 0 documented in https://cwiki.apache.org/confluence/display/TS/RamCache -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-350) new Ram Cache options
[ https://issues.apache.org/jira/browse/TS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759334#comment-13759334 ] ASF subversion and git services commented on TS-350: Commit 6648a786f8d370f0d682be71545d9dcb64187dca in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6648a78 ] TS-350 Add documentation for the new RAM cache options new Ram Cache options - Key: TS-350 URL: https://issues.apache.org/jira/browse/TS-350 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.1.0 Reporter: John Plevyak Priority: Minor Fix For: Docs # Replacement algorithm # 0 : Clocked Least Frequently Used by Size (CLFUS) w/optional compression # 1 : LRU w/o optional compression - trivially simple CONFIG proxy.config.cache.ram_cache.algorithm INT 0 # Compress the content of the ram cache: # 0 : no compression # 1 : fastlz (extremely fast, relatively low compression) # 2 : libz (moderate speed, reasonable compression) # 3 : liblzma (very slow, high compression) CONFIG proxy.config.cache.ram_cache.compress INT 0 documented in https://cwiki.apache.org/confluence/display/TS/RamCache -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-350) Document new Ram Cache options
[ https://issues.apache.org/jira/browse/TS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-350. -- Resolution: Fixed Document new Ram Cache options -- Key: TS-350 URL: https://issues.apache.org/jira/browse/TS-350 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 # Replacement algorithm # 0 : Clocked Least Frequently Used by Size (CLFUS) w/optional compression # 1 : LRU w/o optional compression - trivially simple CONFIG proxy.config.cache.ram_cache.algorithm INT 0 # Compress the content of the ram cache: # 0 : no compression # 1 : fastlz (extremely fast, relatively low compression) # 2 : libz (moderate speed, reasonable compression) # 3 : liblzma (very slow, high compression) CONFIG proxy.config.cache.ram_cache.compress INT 0 documented in https://cwiki.apache.org/confluence/display/TS/RamCache -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-350) Document new Ram Cache options
[ https://issues.apache.org/jira/browse/TS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759341#comment-13759341 ] ASF subversion and git services commented on TS-350: Commit d31a4f92e1e865d8aaef3621e7d6993444d5066e in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d31a4f9 ] TS-350 Try to fix the formatting Document new Ram Cache options -- Key: TS-350 URL: https://issues.apache.org/jira/browse/TS-350 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 # Replacement algorithm # 0 : Clocked Least Frequently Used by Size (CLFUS) w/optional compression # 1 : LRU w/o optional compression - trivially simple CONFIG proxy.config.cache.ram_cache.algorithm INT 0 # Compress the content of the ram cache: # 0 : no compression # 1 : fastlz (extremely fast, relatively low compression) # 2 : libz (moderate speed, reasonable compression) # 3 : liblzma (very slow, high compression) CONFIG proxy.config.cache.ram_cache.compress INT 0 documented in https://cwiki.apache.org/confluence/display/TS/RamCache -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-2167) Update apichecker.pl to give suggestions on additional deprecated APIs
[ https://issues.apache.org/jira/browse/TS-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Cosgrave closed TS-2167. - Update apichecker.pl to give suggestions on additional deprecated APIs -- Key: TS-2167 URL: https://issues.apache.org/jira/browse/TS-2167 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Sean Cosgrave Assignee: Bryan Call Priority: Minor Fix For: 4.1.0 Attachments: apichecker.patch The apichecker.pl from open source ATS does not give suggestions for converting some very old INK API function calls we see in YTS and in some cases gives the wrong suggestion. For instance, the suggestion for converting INKStatCreateV2 is to make it TSStatCreateV2, when it should be TSStatCreate. We should update the script to handle more of these cases that we see in YTS, and that others may see if they are migrating from a very old Traffic Server to ATS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2183) Add RAM cache tech details to the docs
[ https://issues.apache.org/jira/browse/TS-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2183: -- Fix Version/s: Docs Add RAM cache tech details to the docs -- Key: TS-2183 URL: https://issues.apache.org/jira/browse/TS-2183 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom Fix For: Docs We should add the technical (code / data structure) details from https://cwiki.apache.org/confluence/display/TS/RamCache to doc/arch section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2183) Add RAM cache tech details to the docs
Leif Hedstrom created TS-2183: - Summary: Add RAM cache tech details to the docs Key: TS-2183 URL: https://issues.apache.org/jira/browse/TS-2183 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom We should add the technical (code / data structure) details from https://cwiki.apache.org/confluence/display/TS/RamCache to doc/arch section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1411) Seg faulting during log rotation
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759466#comment-13759466
]
David Carlin commented on TS-1411:
--
I regret to report that the patch didn't help. One of the boxes I installed it
on crashed 17 mins later, same trace. Very low traffic, like 20 rps, it had
handed only a few thousand requests in that time - mostly GSLB and load
balancer health checks prior to crashing.
Seg faulting during log rotation
Key: TS-1411
URL: https://issues.apache.org/jira/browse/TS-1411
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: RHEL 6.2 x86_64
Reporter: David Carlin
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include
the unmapped URL and the user agent string:
%cqtq %ttms %chi %crc/%pssc %psql %cqhm %cquc %caun
%phr/%pqsn %psct %xid %cquuc \%{User-Agent}cqh\
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones
seem to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x48)[0x58a118]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x58c3f0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x59d5a2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x6756e7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66e076]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696ce4]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-2167) Update apichecker.pl to give suggestions on additional deprecated APIs
[ https://issues.apache.org/jira/browse/TS-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Cosgrave reopened TS-2167: --- Update apichecker.pl to give suggestions on additional deprecated APIs -- Key: TS-2167 URL: https://issues.apache.org/jira/browse/TS-2167 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Sean Cosgrave Assignee: Bryan Call Priority: Minor Fix For: 4.1.0 Attachments: apichecker.patch The apichecker.pl from open source ATS does not give suggestions for converting some very old INK API function calls we see in YTS and in some cases gives the wrong suggestion. For instance, the suggestion for converting INKStatCreateV2 is to make it TSStatCreateV2, when it should be TSStatCreate. We should update the script to handle more of these cases that we see in YTS, and that others may see if they are migrating from a very old Traffic Server to ATS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
Scott Harris created TS-2184: Summary: Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[
https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759504#comment-13759504
]
Igor Galić commented on TS-1486:
That failure comes quicker than I would've anticipated:
{noformat}
Making all in proxy/api/ts
gmake[1]: Entering directory `/export/home/igalic/trafficserver/proxy/api/ts'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/export/home/igalic/trafficserver/proxy/api/ts'
Making all in iocore
gmake[1]: Entering directory `/export/home/igalic/trafficserver/iocore'
Making all in eventsystem
gmake[2]: Entering directory
`/export/home/igalic/trafficserver/iocore/eventsystem'
CXX EventSystem.o
../../lib/ts/ParseRules.h, line 830: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 835: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 878: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 885: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 923: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 953: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 958: Error: The function __builtin_expect
must have a prototype.
../../lib/ts/ParseRules.h, line 995: Error: The function __builtin_expect
must have a prototype.
P_IOBuffer.h, line 536: Error: The function __builtin_expect must have a
prototype.
P_IOBuffer.h, line 689: Error: The function __builtin_expect must have a
prototype.
P_IOBuffer.h, line 825: Error: The function __builtin_expect must have a
prototype.
P_IOBuffer.h, line 844: Error: The function __builtin_expect must have a
prototype.
P_IOBuffer.h, line 868: Error: The function __builtin_expect must have a
prototype.
P_UnixSocketManager.h, line 68: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 82: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 95: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 120: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 143: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 179: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 192: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 203: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 215: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 226: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 245: Error: The function __builtin_expect must
have a prototype.
P_UnixSocketManager.h, line 256: Error: The function __builtin_expect must
have a prototype.
Compilation aborted, too many Error messages.
gmake[2]: *** [EventSystem.o] Error 2
gmake[2]: Leaving directory
`/export/home/igalic/trafficserver/iocore/eventsystem'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/export/home/igalic/trafficserver/iocore'
gmake: *** [all-recursive] Error 1
{noformat}
drop solaris studio support
---
Key: TS-1486
URL: https://issues.apache.org/jira/browse/TS-1486
Project: Traffic Server
Issue Type: Bug
Components: Core, Portability
Reporter: James Peach
Assignee: Igor Galić
Fix For: 4.1.0
We should drop Solaris Studio support for the 3.4 release.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759808#comment-13759808 ] Leif Hedstrom commented on TS-1486: --- So it's already broken, which means (I hope) that we don't have to worry about breaking compatibility within 4.x. In fact, removing it keep compatibility: it's broken now, and it'll be broken once we remove support for it, just better errors. Make it so #1. drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 4.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-361) Document human readable number multiplies for configuration values
[ https://issues.apache.org/jira/browse/TS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-361: - Fix Version/s: (was: Docs) 4.1.0 Assignee: Leif Hedstrom Summary: Document human readable number multiplies for configuration values (was: Use human readable number multiplies for configuration values) Document human readable number multiplies for configuration values -- Key: TS-361 URL: https://issues.apache.org/jira/browse/TS-361 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Mladen Turk Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 Use friendly multipliers for the configuration numbers using the following notation: [-]digit*[gGkKmM] k or K multiplies the provided number with 1024 m or M multiplies the provided number with 1024 * 1024 g or G multiplies the provided number with 1024 * 1024 * 1024 Add this as generic string function similar to ink_atoll -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-361) Document human readable number multiplies for configuration values
[ https://issues.apache.org/jira/browse/TS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759826#comment-13759826 ] ASF subversion and git services commented on TS-361: Commit f15a2559abd60f86cee489e7d1599fdf1215c3cf in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f15a255 ] TS-361 Document human readable number multiplies for configuration values Document human readable number multiplies for configuration values -- Key: TS-361 URL: https://issues.apache.org/jira/browse/TS-361 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Mladen Turk Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 Use friendly multipliers for the configuration numbers using the following notation: [-]digit*[gGkKmM] k or K multiplies the provided number with 1024 m or M multiplies the provided number with 1024 * 1024 g or G multiplies the provided number with 1024 * 1024 * 1024 Add this as generic string function similar to ink_atoll -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2185) support to control ClusterCom::sendSharedData frequency
Bin Chen created TS-2185: Summary: support to control ClusterCom::sendSharedData frequency Key: TS-2185 URL: https://issues.apache.org/jira/browse/TS-2185 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen support to control ClusterCom::sendSharedData frequency. The original design ClusterCom::sendSharedData will be called every loop. It's so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-361) Document human readable number multiplies for configuration values
[ https://issues.apache.org/jira/browse/TS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-361. -- Resolution: Fixed Document human readable number multiplies for configuration values -- Key: TS-361 URL: https://issues.apache.org/jira/browse/TS-361 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Mladen Turk Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 Use friendly multipliers for the configuration numbers using the following notation: [-]digit*[gGkKmM] k or K multiplies the provided number with 1024 m or M multiplies the provided number with 1024 * 1024 g or G multiplies the provided number with 1024 * 1024 * 1024 Add this as generic string function similar to ink_atoll -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2185: Assignee: Bin Chen support to control ClusterCom::sendSharedData frequency --- Key: TS-2185 URL: https://issues.apache.org/jira/browse/TS-2185 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen support to control ClusterCom::sendSharedData frequency. The original design ClusterCom::sendSharedData will be called every loop. It's so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-361) Document human readable number multiplies for configuration values
[ https://issues.apache.org/jira/browse/TS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759831#comment-13759831 ] ASF subversion and git services commented on TS-361: Commit d3917df32b01e701adc8aeee59fdb4f511c807f2 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d3917df ] TS-361 Explain K, M, G and T Document human readable number multiplies for configuration values -- Key: TS-361 URL: https://issues.apache.org/jira/browse/TS-361 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Mladen Turk Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 Use friendly multipliers for the configuration numbers using the following notation: [-]digit*[gGkKmM] k or K multiplies the provided number with 1024 m or M multiplies the provided number with 1024 * 1024 g or G multiplies the provided number with 1024 * 1024 * 1024 Add this as generic string function similar to ink_atoll -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-498) New configuration for dedicated DNS thread
[ https://issues.apache.org/jira/browse/TS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-498. -- Resolution: Fixed New configuration for dedicated DNS thread -- Key: TS-498 URL: https://issues.apache.org/jira/browse/TS-498 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 *) Experimental supoprt for a dedicated DNS thread. This can be enabled with the records.config option CONFIG proxy.config.dns.dedicated_thread INT 1 This feature is possibly useful for very busy forward or transparent proxies [TS-307]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-498) New configuration for dedicated DNS thread
[ https://issues.apache.org/jira/browse/TS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759838#comment-13759838 ] ASF subversion and git services commented on TS-498: Commit 194d2454dbf6328920c266f46f4012939350263d in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=194d245 ] TS-498 Document dedicate DNS thread configuration New configuration for dedicated DNS thread -- Key: TS-498 URL: https://issues.apache.org/jira/browse/TS-498 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom Priority: Minor Fix For: Docs *) Experimental supoprt for a dedicated DNS thread. This can be enabled with the records.config option CONFIG proxy.config.dns.dedicated_thread INT 1 This feature is possibly useful for very busy forward or transparent proxies [TS-307]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-498) New configuration for dedicated DNS thread
[ https://issues.apache.org/jira/browse/TS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-498: - Fix Version/s: (was: Docs) 4.1.0 Assignee: Leif Hedstrom New configuration for dedicated DNS thread -- Key: TS-498 URL: https://issues.apache.org/jira/browse/TS-498 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 4.1.0 *) Experimental supoprt for a dedicated DNS thread. This can be enabled with the records.config option CONFIG proxy.config.dns.dedicated_thread INT 1 This feature is possibly useful for very busy forward or transparent proxies [TS-307]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
