[jira] [Resolved] (TS-3276) Cache incompatible between 5.0.1 and 5.2.0
[
https://issues.apache.org/jira/browse/TS-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-3276.
Resolution: Fixed
There was a problem with the production configuration, volume.config was
changed. I tested it with a normal apache build and it works.
Cache incompatible between 5.0.1 and 5.2.0
--
Key: TS-3276
URL: https://issues.apache.org/jira/browse/TS-3276
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Bryan Call
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 5.2.0
When upgrading from 5.0.1 to 5.2.0 RC3 I notice that there were no cache
entries and the cache had 0 bytes. I was able to reproduce this on my
development box.
Running 5.0.1:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.0.1 [cHs f ])
[Jan 6 14:34:50.967] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver 256M
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), ns-vol_num=0
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 268435456,
blocks = 32768, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:50.982] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 33554432,
blocks = 4096, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:51.006] Server {0xff85000} DEBUG: (cache_init) Cache::open -
proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:34:51.008] Server {0xff85000} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
build_vol_hash_table index 0 mapped to 0 requested 32707 got 32707
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - theCache, total_size = 32766 = 255 MB
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - caches_ready=0x3, gnvol=1
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - cache_config_ram_cache_size ==
AUTO_SIZE_RAM_CACHE
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - ram_cache_bytes = 352256 = 0Mb
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - total_cache_bytes = 268066816 = 255Mb
[Jan 6 14:34:52.937] Server {0xf567000} DEBUG: (cache_new) new 0x7fdaa2842c60
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read) Read complete on
fragment 0B9EF20BA07FE10DE08A3C04FAC4F722. Length: data payload=18104 this
fragment=21016 total doc=18104 prefix=2912
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read)
CacheReadStartHead - read 0B9EF20BA07FE10DE08A3C04FAC4F722 target
AE93D67FD96B9386253B02F1DA044B54 - single 21016 of 18104 bytes, 0 fragments
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_free) free
0x7fdaa2842c6
{code}
Running 5.2.0:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.2.0 [cMsSfW])
[Jan 6 14:35:54.684] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), forced volume=-1
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=268435456, blocks=32768,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=33554432, blocks=4096,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.788] Server {0x7fff7b295300} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:35:54.790] Server {0x7fff7b295300} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[jira] [Assigned] (TS-3293) Need to review various protocol accept objects and make them more widely available
[ https://issues.apache.org/jira/browse/TS-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-3293: -- Assignee: Susan Hinrichs Need to review various protocol accept objects and make them more widely available -- Key: TS-3293 URL: https://issues.apache.org/jira/browse/TS-3293 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs Assignee: Susan Hinrichs This came up most recently in propagating tr-pass information for TS-3292 The early configuration is being duplicated in too many objects. The information is being propagated differently for HTTP and SSL (who knows what is happening with SPDY). We should take a step back to review and unify this information. Alan took a first pass on this review with his Early Intervention talk from the Fall 2014 summit https://www.dropbox.com/s/4vw91czj41rdxjo/ATS-Early-Intervention.pptx?dl=0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3292) Make tr-pass work for SSL port
[ https://issues.apache.org/jira/browse/TS-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3292: --- Assignee: Lev Stipakov Make tr-pass work for SSL port -- Key: TS-3292 URL: https://issues.apache.org/jira/browse/TS-3292 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Lev Stipakov Assignee: Lev Stipakov As discussed some time ago on IRC, it would be nice to have tr-pass functionality for SSL port. If SSLAccept returns an error and: * tr-pass is set * first byte is not ClientHello we activate blind tunnel. If I understand correctly, the only packet we expect in sslServerHandShakeEvent is ClientHello, so it is safe to assume that if first byte is not handshake code (0x16), traffic is not SSL. I also think that we should start tunnel for all errors, not only SSL_ERROR_SSL, because if first packet is smaller than expected ClientHello, SSLAccept returns SSL_ERROR_WANT_READ. Subsequent packets will surely generate SSL_ERROR_SSL, but I don't think it is necessary to wait for those. https://github.com/apache/trafficserver/pull/162 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3292) Make tr-pass work for SSL port
[ https://issues.apache.org/jira/browse/TS-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-3292. -- Resolution: Fixed Fix Version/s: 5.3.0 Make tr-pass work for SSL port -- Key: TS-3292 URL: https://issues.apache.org/jira/browse/TS-3292 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Lev Stipakov Assignee: Lev Stipakov Fix For: 5.3.0 As discussed some time ago on IRC, it would be nice to have tr-pass functionality for SSL port. If SSLAccept returns an error and: * tr-pass is set * first byte is not ClientHello we activate blind tunnel. If I understand correctly, the only packet we expect in sslServerHandShakeEvent is ClientHello, so it is safe to assume that if first byte is not handshake code (0x16), traffic is not SSL. I also think that we should start tunnel for all errors, not only SSL_ERROR_SSL, because if first packet is smaller than expected ClientHello, SSLAccept returns SSL_ERROR_WANT_READ. Subsequent packets will surely generate SSL_ERROR_SSL, but I don't think it is necessary to wait for those. https://github.com/apache/trafficserver/pull/162 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3292) Make tr-pass work for SSL port
[ https://issues.apache.org/jira/browse/TS-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277447#comment-14277447 ] ASF subversion and git services commented on TS-3292: - Commit 2b3dcf6eb4862e6293c91e0427e1e1a8cfe46116 in trafficserver's branch refs/heads/master from [~lstipakov] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2b3dcf6 ] TS-3292: Make tr-pass work for SSL port. This closes #162 Make tr-pass work for SSL port -- Key: TS-3292 URL: https://issues.apache.org/jira/browse/TS-3292 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Lev Stipakov Assignee: Lev Stipakov As discussed some time ago on IRC, it would be nice to have tr-pass functionality for SSL port. If SSLAccept returns an error and: * tr-pass is set * first byte is not ClientHello we activate blind tunnel. If I understand correctly, the only packet we expect in sslServerHandShakeEvent is ClientHello, so it is safe to assume that if first byte is not handshake code (0x16), traffic is not SSL. I also think that we should start tunnel for all errors, not only SSL_ERROR_SSL, because if first packet is smaller than expected ClientHello, SSLAccept returns SSL_ERROR_WANT_READ. Subsequent packets will surely generate SSL_ERROR_SSL, but I don't think it is necessary to wait for those. https://github.com/apache/trafficserver/pull/162 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3262) Build failure using clang on Fedora 21
[
https://issues.apache.org/jira/browse/TS-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277866#comment-14277866
]
ASF subversion and git services commented on TS-3262:
-
Commit 9e2a4729114d92019a0ef9d3f4bc89da7ac434a2 in trafficserver's branch
refs/heads/4.2.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9e2a472 ]
TS-3262 Check _hostname[0], which seems correct
(cherry picked from commit 29e58ea4ef4884ddc3e3606cac2e4aba3400fdcf)
Build failure using clang on Fedora 21
--
Key: TS-3262
URL: https://issues.apache.org/jira/browse/TS-3262
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 5.2.0
{code}
../../proxy/CoreUtils.cc:266:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:266:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
../../proxy/CoreUtils.cc:305:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:305:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:348:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:348:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:652:20: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
int nto_copy = abs((char *) copy_start - free_start);
^
../../proxy/CoreUtils.cc:652:20: note: use function 'std::abs' instead
int nto_copy = abs((char *) copy_start - free_start);
^~~
std::abs
../../proxy/CoreUtils.cc:794:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:794:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-898) Fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277934#comment-14277934 ] ASF subversion and git services commented on TS-898: Commit 7cf27625b2e04ff5422dd6b99452eaa58e628fad in trafficserver's branch refs/heads/4.2.x from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7cf2762 ] TS-898: remove pointless NULL check on array cl.origin_list is an array do the NULL check is pointless. Also simplify the code around origiin set initialization so that the origin set is always allocated. Coverity #1200013. (cherry picked from commit b90a731d4e2d31fbb1e958bde76250a3994fb690) Conflicts: CHANGES Fix potential problems from coverity scan - Key: TS-898 URL: https://issues.apache.org/jira/browse/TS-898 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Environment: RHEL5 Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.2.0 Ran Coverity over the code and it reported 856 potential problems with the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3294) 5.3.0 Coverity Fixes
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277968#comment-14277968 ] ASF subversion and git services commented on TS-3294: - Commit eaf53d5e81d065c89ad2a282834b07a675e9b4ab in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=eaf53d5 ] [TS-3294]: Add null pointer check after strtok_r Coverity CID#1238928 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to normal : tsqa-master #27
See https://ci.trafficserver.apache.org/job/tsqa-master/27/
[jira] [Commented] (TS-3294) 5.3.0 Coverity Fixes
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277960#comment-14277960 ] ASF subversion and git services commented on TS-3294: - Commit 1cbed93f44e68388af72c5f16a20c604587832a2 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1cbed93 ] [TS-3294]: remove logically dead code Coverity CID#1242010 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3294) 5.3.0 Coverity Fixes
Sudheer Vinukonda created TS-3294: - Summary: 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3294) 5.3.0 Coverity Fixes
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277989#comment-14277989 ] ASF subversion and git services commented on TS-3294: - Commit 2b021b0807cae5ee1dea820a27b1cf6cba4ed43d in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2b021b0 ] [TS-3294]: Add null pointer check Coverity CID#1226153 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3262) Build failure using clang on Fedora 21
[
https://issues.apache.org/jira/browse/TS-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277842#comment-14277842
]
ASF subversion and git services commented on TS-3262:
-
Commit 5b35e087c98bfe71090cef26cc7f849694d0e4fb in trafficserver's branch
refs/heads/4.2.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5b35e08 ]
TS-3262 Change abs() to std::abs(), avoid compiler errors
(cherry picked from commit 6ef1ad858a4459e7dd7f4641013732f74a94325e)
Build failure using clang on Fedora 21
--
Key: TS-3262
URL: https://issues.apache.org/jira/browse/TS-3262
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Blocker
Fix For: 5.2.0
{code}
../../proxy/CoreUtils.cc:266:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:266:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
../../proxy/CoreUtils.cc:305:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:305:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:348:19: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t off2 = abs(vadd - framep);
^
../../proxy/CoreUtils.cc:348:19: note: use function 'std::abs' instead
intptr_t off2 = abs(vadd - framep);
^~~
std::abs
../../proxy/CoreUtils.cc:652:20: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
int nto_copy = abs((char *) copy_start - free_start);
^
../../proxy/CoreUtils.cc:652:20: note: use function 'std::abs' instead
int nto_copy = abs((char *) copy_start - free_start);
^~~
std::abs
../../proxy/CoreUtils.cc:794:22: error: absolute value function 'abs' given
an argument of type 'long' but has parameter of type 'int' which may cause
truncation of value [-Werror,-Wabsolute-value]
intptr_t offset2 = abs(vaddr - vadd);
^
../../proxy/CoreUtils.cc:794:22: note: use function 'std::abs' instead
intptr_t offset2 = abs(vaddr - vadd);
^~~
std::abs
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3294) 5.3.0 Coverity Fixes
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277978#comment-14277978 ] ASF subversion and git services commented on TS-3294: - Commit c22266848846a696b081bd98f1b4c4dcce7e9aa2 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c222668 ] [TS-3294]: Move dereference after null check Coverity CID#1237321 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278045#comment-14278045 ] ASF subversion and git services commented on TS-3287: - Commit a477ad72196d40041f85772dd19be9e76cc31ddf in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a477ad7 ] TS-3287 Add a consistency check on cache initialization. This is probably something that can't happen, but the test is reasonable, and makes Coverity #CID 1022176 happy. Coverity fixes for v5.3.0 by zwoop -- Key: TS-3287 URL: https://issues.apache.org/jira/browse/TS-3287 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.0 This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3294) 5.3.0 Coverity Fixes
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277976#comment-14277976 ] ASF subversion and git services commented on TS-3294: - Commit 0e88a2f7d0f895a1b0854617f9729a05a4262915 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0e88a2f ] [TS-3294]: Fix unchecked return value coverity defect Coverity CID#1237970 5.3.0 Coverity Fixes Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3295) Remove Comptability.h
[
https://issues.apache.org/jira/browse/TS-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278271#comment-14278271
]
ASF subversion and git services commented on TS-3295:
-
Commit c1c680459bc69d0e2293eb64fff92485e8dd06f9 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c1c6804 ]
TS-3295: remove obsolete Compatability.h
Remove Comptability.h
-
Key: TS-3295
URL: https://issues.apache.org/jira/browse/TS-3295
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Remove the obsolete {{Compatability.h}} header. It has few useful definitions
and it is spelled wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3295) Remove Comptability.h
[
https://issues.apache.org/jira/browse/TS-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3295.
-
Resolution: Fixed
Fix Version/s: 5.3.0
Assignee: James Peach
Remove Comptability.h
-
Key: TS-3295
URL: https://issues.apache.org/jira/browse/TS-3295
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Assignee: James Peach
Fix For: 5.3.0
Remove the obsolete {{Compatability.h}} header. It has few useful definitions
and it is spelled wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3296) Use Regex.h to find PCRE headers
[
https://issues.apache.org/jira/browse/TS-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278279#comment-14278279
]
ASF subversion and git services commented on TS-3296:
-
Commit 7052d85c3850f795f1cfd9fad865deae022c2503 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7052d85 ]
TS-3296: use Regex.h in preference to raw PCRE headers
Use Regex.h to find PCRE headers
Key: TS-3296
URL: https://issues.apache.org/jira/browse/TS-3296
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
We should use {{Regex.h}} to include the PRCE headers, so that we don't
duplicate the PCRE inclusion boilerplate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3296) Use Regex.h to find PCRE headers
[
https://issues.apache.org/jira/browse/TS-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3296.
-
Resolution: Fixed
Fix Version/s: 5.3.0
Assignee: James Peach
Use Regex.h to find PCRE headers
Key: TS-3296
URL: https://issues.apache.org/jira/browse/TS-3296
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Assignee: James Peach
Fix For: 5.3.0
We should use {{Regex.h}} to include the PRCE headers, so that we don't
duplicate the PCRE inclusion boilerplate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3297) encapsulate parse errors
James Peach created TS-3297: --- Summary: encapsulate parse errors Key: TS-3297 URL: https://issues.apache.org/jira/browse/TS-3297 Project: Traffic Server Issue Type: New Feature Components: Configuration, Core Reporter: James Peach The core configuration file parsing routines often (but not always) return an allocated error message on error. Start replacing this with a parse error object so that the memory management is more robust. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3297) encapsulate parse errors
[ https://issues.apache.org/jira/browse/TS-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-3297: Issue Type: Improvement (was: New Feature) encapsulate parse errors Key: TS-3297 URL: https://issues.apache.org/jira/browse/TS-3297 Project: Traffic Server Issue Type: Improvement Components: Configuration, Core Reporter: James Peach The core configuration file parsing routines often (but not always) return an allocated error message on error. Start replacing this with a parse error object so that the memory management is more robust. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2482) Problems with SOCKS
[ https://issues.apache.org/jira/browse/TS-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-2482: -- Assignee: weijin Problems with SOCKS --- Key: TS-2482 URL: https://issues.apache.org/jira/browse/TS-2482 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Radim Kolar Assignee: weijin Fix For: sometime There are several problems with using SOCKS. I am interested in case when TF is sock client. Client sends HTTP request and TF uses SOCKS server to make connection to internet. a/ - not documented enough in default configs From default configs comments it seems that for running TF 4.1.2 as socks client, it is sufficient to add one line to socks.config: dest_ip=0.0.0.0-255.255.255.255 parent=10.0.0.7:9050 but socks proxy is not used. If i run tcpdump sniffing packets TF never tries to connect to that SOCKS. From source code - https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it looks that is needed to set proxy.config.socks.socks_needed to activate socks support. This should be documented in both sample files: socks.config and record.config b/ after enabling socks, i am hit by this assert: Assertion failed: (ats_is_ip4(target_addr)), function init, file Socks.cc, line 65. i run on dual stack system (ip4,ip6). This code is setting default destination for SOCKS request? Can not you use just 127.0.0.1 for case if client gets connected over IP6? https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2482) Problems with SOCKS
[ https://issues.apache.org/jira/browse/TS-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278227#comment-14278227 ] Zhao Yongming commented on TS-2482: --- we have a patch that will fix the problem, I think. it works on turning ATS into a SOCSK5 server, but still pending to full testing with parent socks feature. the problem here is not only the assert, but also the HTTP transactions. Problems with SOCKS --- Key: TS-2482 URL: https://issues.apache.org/jira/browse/TS-2482 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Radim Kolar Fix For: sometime There are several problems with using SOCKS. I am interested in case when TF is sock client. Client sends HTTP request and TF uses SOCKS server to make connection to internet. a/ - not documented enough in default configs From default configs comments it seems that for running TF 4.1.2 as socks client, it is sufficient to add one line to socks.config: dest_ip=0.0.0.0-255.255.255.255 parent=10.0.0.7:9050 but socks proxy is not used. If i run tcpdump sniffing packets TF never tries to connect to that SOCKS. From source code - https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it looks that is needed to set proxy.config.socks.socks_needed to activate socks support. This should be documented in both sample files: socks.config and record.config b/ after enabling socks, i am hit by this assert: Assertion failed: (ats_is_ip4(target_addr)), function init, file Socks.cc, line 65. i run on dual stack system (ip4,ip6). This code is setting default destination for SOCKS request? Can not you use just 127.0.0.1 for case if client gets connected over IP6? https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3296) Use Regex.h to find PCRE headers
James Peach created TS-3296:
---
Summary: Use Regex.h to find PCRE headers
Key: TS-3296
URL: https://issues.apache.org/jira/browse/TS-3296
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
We should use {{Regex.h}} to include the PRCE headers, so that we don't
duplicate the PCRE inclusion boilerplate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3297) encapsulate parse errors
[ https://issues.apache.org/jira/browse/TS-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278297#comment-14278297 ] ASF subversion and git services commented on TS-3297: - Commit 70cc2d4ce1762b182dd52f43a6313c61772c3a8a in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70cc2d4 ] TS-3297: encapsulate configuration parse errors Rather than returning malloc'ed strings, return and error object that contains a formatted message. Coverity CID #1242340 Coverity CID #1196486 encapsulate parse errors Key: TS-3297 URL: https://issues.apache.org/jira/browse/TS-3297 Project: Traffic Server Issue Type: Improvement Components: Configuration, Core Reporter: James Peach The core configuration file parsing routines often (but not always) return an allocated error message on error. Start replacing this with a parse error object so that the memory management is more robust. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3297) encapsulate parse errors
[ https://issues.apache.org/jira/browse/TS-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-3297. - Resolution: Fixed Fix Version/s: 5.3.0 Assignee: James Peach encapsulate parse errors Key: TS-3297 URL: https://issues.apache.org/jira/browse/TS-3297 Project: Traffic Server Issue Type: Improvement Components: Configuration, Core Reporter: James Peach Assignee: James Peach Fix For: 5.3.0 The core configuration file parsing routines often (but not always) return an allocated error message on error. Start replacing this with a parse error object so that the memory management is more robust. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3272) TS_SSL_SNI_HOOK continuously called
[ https://issues.apache.org/jira/browse/TS-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277011#comment-14277011 ] Lev Stipakov commented on TS-3272: -- Just noticed that if thread function calls only TSVConnReenable (and not TSVConnTunnel), TS_SSL_SNI_HOOK gets called again. It starts / pushes task to a thread, which calls TSVConnReenable and we're in a loop. It does not happen if TSVConnReenable is called directly from TS_SSL_SNI_HOOK. TS_SSL_SNI_HOOK continuously called Key: TS-3272 URL: https://issues.apache.org/jira/browse/TS-3272 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Lev Stipakov Assignee: Susan Hinrichs Fix For: 5.3.0 Attachments: SSLNetVConnection.patch, plugin.cc, ts-3272-2.diff, ts-3272-3.diff, ts-3272-4.diff, ts-3272-master.diff, ts-3272.diff I have created a simple plugin with TS_SSL_SNI_HOOK handler. Handler starts thread. Thread function has small sleep and after that calls TSVConnTunnel. The problem is that during sleep duration TS_SSL_SNI_HOOK handler gets continuously called. I would expect that TS_SSL_SNI_HOOK handler should be called just once. See plugin code in attach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build is back to normal : freebsd_10-master ยป clang,freebsd_10,debug #645
See https://ci.trafficserver.apache.org/job/freebsd_10-master/compiler=clang,label=freebsd_10,type=debug/645/
[jira] [Created] (TS-3295) Remove Comptability.h
James Peach created TS-3295:
---
Summary: Remove Comptability.h
Key: TS-3295
URL: https://issues.apache.org/jira/browse/TS-3295
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Remove the obsolete {{Compatability.h}} header. It has few useful definitions
and it is spelled wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-3276) Cache incompatible between 5.0.1 and 5.2.0
[
https://issues.apache.org/jira/browse/TS-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reopened TS-3276:
Cache incompatible between 5.0.1 and 5.2.0
--
Key: TS-3276
URL: https://issues.apache.org/jira/browse/TS-3276
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Bryan Call
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 5.2.0
When upgrading from 5.0.1 to 5.2.0 RC3 I notice that there were no cache
entries and the cache had 0 bytes. I was able to reproduce this on my
development box.
Running 5.0.1:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.0.1 [cHs f ])
[Jan 6 14:34:50.967] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver 256M
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), ns-vol_num=0
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 268435456,
blocks = 32768, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:50.982] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 33554432,
blocks = 4096, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:51.006] Server {0xff85000} DEBUG: (cache_init) Cache::open -
proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:34:51.008] Server {0xff85000} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
build_vol_hash_table index 0 mapped to 0 requested 32707 got 32707
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - theCache, total_size = 32766 = 255 MB
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - caches_ready=0x3, gnvol=1
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - cache_config_ram_cache_size ==
AUTO_SIZE_RAM_CACHE
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - ram_cache_bytes = 352256 = 0Mb
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - total_cache_bytes = 268066816 = 255Mb
[Jan 6 14:34:52.937] Server {0xf567000} DEBUG: (cache_new) new 0x7fdaa2842c60
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read) Read complete on
fragment 0B9EF20BA07FE10DE08A3C04FAC4F722. Length: data payload=18104 this
fragment=21016 total doc=18104 prefix=2912
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read)
CacheReadStartHead - read 0B9EF20BA07FE10DE08A3C04FAC4F722 target
AE93D67FD96B9386253B02F1DA044B54 - single 21016 of 18104 bytes, 0 fragments
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_free) free
0x7fdaa2842c6
{code}
Running 5.2.0:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.2.0 [cMsSfW])
[Jan 6 14:35:54.684] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), forced volume=-1
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=268435456, blocks=32768,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=33554432, blocks=4096,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.788] Server {0x7fff7b295300} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:35:54.790] Server {0x7fff7b295300} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[Jan 6 14:35:54.797] Server {0x113fd000} DEBUG: (cache_init)
build_vol_hash_table index 0 mapped to 0 requested 32707 got 32707
[Jan 6 14:35:54.797]
[jira] [Commented] (TS-3276) Cache incompatible between 5.0.1 and 5.2.0
[
https://issues.apache.org/jira/browse/TS-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277299#comment-14277299
]
Bryan Call commented on TS-3276:
I am still seeing cache being cleared when upgrading from 5.0.1 to 5.2.0 RC5.
Cache incompatible between 5.0.1 and 5.2.0
--
Key: TS-3276
URL: https://issues.apache.org/jira/browse/TS-3276
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Bryan Call
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 5.2.0
When upgrading from 5.0.1 to 5.2.0 RC3 I notice that there were no cache
entries and the cache had 0 bytes. I was able to reproduce this on my
development box.
Running 5.0.1:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.0.1 [cHs f ])
[Jan 6 14:34:50.967] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver 256M
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), ns-vol_num=0
[Jan 6 14:34:50.968] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 268435456,
blocks = 32768, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:50.982] Server {0x7fff7b295300} DEBUG: (cache_init) Span::init
- /usr/local/var/trafficserver hw_sector_size = 1048576 size = 33554432,
blocks = 4096, disk_id = 16777220, file_pathname = 0
[Jan 6 14:34:51.006] Server {0xff85000} DEBUG: (cache_init) Cache::open -
proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:34:51.008] Server {0xff85000} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
build_vol_hash_table index 0 mapped to 0 requested 32707 got 32707
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - theCache, total_size = 32766 = 255 MB
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - caches_ready=0x3, gnvol=1
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - cache_config_ram_cache_size ==
AUTO_SIZE_RAM_CACHE
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - ram_cache_bytes = 352256 = 0Mb
[Jan 6 14:34:51.016] Server {0xfb79000} DEBUG: (cache_init)
CacheProcessor::cacheInitialized - total_cache_bytes = 268066816 = 255Mb
[Jan 6 14:34:52.937] Server {0xf567000} DEBUG: (cache_new) new 0x7fdaa2842c60
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read) Read complete on
fragment 0B9EF20BA07FE10DE08A3C04FAC4F722. Length: data payload=18104 this
fragment=21016 total doc=18104 prefix=2912
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_read)
CacheReadStartHead - read 0B9EF20BA07FE10DE08A3C04FAC4F722 target
AE93D67FD96B9386253B02F1DA044B54 - single 21016 of 18104 bytes, 0 fragments
[Jan 6 14:34:52.938] Server {0xf567000} DEBUG: (cache_free) free
0x7fdaa2842c6
{code}
Running 5.2.0:
{code}
curl -D - -o /dev/null -s -x 127.0.0.1:8080
'http://l1.ycs.vip.lax.yahoo.com/17k.gif'
Via: (ApacheTrafficServer/5.2.0 [cMsSfW])
[Jan 6 14:35:54.684] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config, fd = -1, /usr/local/etc/trafficserver/storage.config
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config: var/trafficserver
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
Store::read_config - ns = new Span;
ns-init(/usr/local/var/trafficserver,268435456), forced volume=-1
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.685] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=268435456, blocks=32768,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init) initialized
span '/usr/local/var/trafficserver'
[Jan 6 14:35:54.698] Server {0x7fff7b295300} DEBUG: (cache_init)
hw_sector_size=1048576, size=33554432, blocks=4096,
disk_id=16777220/45700045, file_pathname=0
[Jan 6 14:35:54.788] Server {0x7fff7b295300} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 8000
[Jan 6 14:35:54.790] Server {0x7fff7b295300} DEBUG: (cache_init) allocating
352256 directory bytes for a 268419072 byte volume (0.131234%)
[Jan 6 14:35:54.797]
[jira] [Created] (TS-3293) Need to review various protocol accept objects and make them more widely available
Susan Hinrichs created TS-3293: -- Summary: Need to review various protocol accept objects and make them more widely available Key: TS-3293 URL: https://issues.apache.org/jira/browse/TS-3293 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs This came up most recently in propagating tr-pass information for TS-3292 The early configuration is being duplicated in too many objects. The information is being propagated differently for HTTP and SSL (who knows what is happening with SPDY). We should take a step back to review and unify this information. Alan took a first pass on this review with his Early Intervention talk from the Fall 2014 summit https://www.dropbox.com/s/4vw91czj41rdxjo/ATS-Early-Intervention.pptx?dl=0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3293) Need to review various protocol accept objects and make them more widely available
[ https://issues.apache.org/jira/browse/TS-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277403#comment-14277403 ] ASF GitHub Bot commented on TS-3293: Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/162#issuecomment-69966381 As it turns, out the records.config processing already checks that tr-in is set if you are trying to set tr-pass. I filled TS-3293 to track the issue of cleaning up the propagation for flags through various accept and netvc. Will pull Lev's latest patch, and get it merged up. Need to review various protocol accept objects and make them more widely available -- Key: TS-3293 URL: https://issues.apache.org/jira/browse/TS-3293 Project: Traffic Server Issue Type: Bug Reporter: Susan Hinrichs This came up most recently in propagating tr-pass information for TS-3292 The early configuration is being duplicated in too many objects. The information is being propagated differently for HTTP and SSL (who knows what is happening with SPDY). We should take a step back to review and unify this information. Alan took a first pass on this review with his Early Intervention talk from the Fall 2014 summit https://www.dropbox.com/s/4vw91czj41rdxjo/ATS-Early-Intervention.pptx?dl=0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Build failed in Jenkins: tsqa-master #26
See https://ci.trafficserver.apache.org/job/tsqa-master/26/ -- Started by timer Building remotely on QA1 (qa) in workspace https://ci.trafficserver.apache.org/job/tsqa-master/ws/ /usr/bin/git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository /usr/bin/git config remote.origin.url https://github.com/apache/trafficserver.git # timeout=10 Cleaning workspace /usr/bin/git rev-parse --verify HEAD # timeout=10 Resetting working tree /usr/bin/git reset --hard # timeout=10 ERROR: Error fetching remote repo 'origin' ERROR: Error fetching remote repo 'origin'
[jira] [Created] (TS-3292) Make tr-pass work for SSL port
Lev Stipakov created TS-3292: Summary: Make tr-pass work for SSL port Key: TS-3292 URL: https://issues.apache.org/jira/browse/TS-3292 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Lev Stipakov As discussed some time ago on IRC, it would be nice to have tr-pass functionality for SSL port. If SSLAccept returns an error and: * tr-pass is set * first byte is not ClientHello we activate blind tunnel. If I understand correctly, the only packet we expect in sslServerHandShakeEvent is ClientHello, so it is safe to assume that if first byte is not handshake code (0x16), traffic is not SSL. I also think that we should start tunnel for all errors, not only SSL_ERROR_SSL, because if first packet is smaller than expected ClientHello, SSLAccept returns SSL_ERROR_WANT_READ. Subsequent packets will surely generate SSL_ERROR_SSL, but I don't think it is necessary to wait for those. https://github.com/apache/trafficserver/pull/162 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
