Re: [jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
John: the patch was just a temporary solution and I did not take into account this situation you mentioned (even did not know). So if you have any ideas about it, tell me. On Thu, 2012-04-19 at 03:51 +, John Plevyak (Commented) (JIRA) wrote: [ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257197#comment-13257197 ] John Plevyak commented on TS-621: - weijin, your patch relies on the Content-Length: header. That is probably safe and covers most situations, but I don't know that it will work in all situations. Old school servers (1.0) which don't use Content-Length: will not benefit. I have to admit that it does finesse the compatibility issues, but I was hoping for a complete solution. Perhaps we can look at using some combination of the patches whereby we use the API changes I am proposing and verify that we are doing the right thing with the Content-Length and perhaps use your flag? I'll look into it as well. writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: weijin Fix For: 3.1.4 Attachments: TS-621_cluster_zero_size_objects.patch, force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257302#comment-13257302 ] weijin commented on TS-621: --- John: the patch was just a temporary solution and I did not take into account this situation you mentioned (even did not know). So if you have any ideas about it, tell me. On Thu, 2012-04-19 at 03:51 +, John Plevyak (Commented) (JIRA) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: weijin Fix For: 3.1.4 Attachments: TS-621_cluster_zero_size_objects.patch, force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1203) Crash report: HdrHeap::duplicate_str, in host_set
[
https://issues.apache.org/jira/browse/TS-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257476#comment-13257476
]
weijin commented on TS-1203:
It is similar as TS-996. We will back port it and test again.
Crash report: HdrHeap::duplicate_str, in host_set
-
Key: TS-1203
URL: https://issues.apache.org/jira/browse/TS-1203
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: 3.0.x, new crashes
Reporter: Zhao Yongming
Assignee: weijin
Priority: Critical
Fix For: 3.1.4
we get some new crashes in the production:
{code}
warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x727fd000
Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
#4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url=value
optimized out) at HTTP.cc:1484
#5 0x0055dc69 in RemapProcessor::setup_for_remap (this=value
optimized out, s=0x2aae268f83c8) at RemapProcessor.cc:130
#6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
run_inline=true) at HttpSM.cc:3666
#7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
HttpSM.cc:6392
#8 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#10 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#12 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#13 0x00520f21 in HttpSM::state_read_client_request_header
(this=0x2aae268f8360, event=100, data=value optimized out)
at HttpSM.cc:783
#14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360,
event=100, data=0x2aae68aee6e0) at HttpSM.cc:2456
#15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010)
at ../../iocore/eventsystem/I_Continuation.h:146
#16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:138
#17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:320
#18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
event=value optimized out, e=0x2b8ed028) at UnixNet.cc:389
#19 0x00691c8f in EThread::process_event (this=0x2b104010,
e=0x35681c0, calling_code=5) at I_Continuation.h:146
#20 0x0069259c in EThread::execute (this=0x2b104010) at
UnixEThread.cc:263
#21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
#22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
#23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
344 memcpy(new_str, str, nbytes);
(gdb) p str
$1 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) p nbytes
$2 = 21
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
3034 s_str = heap-duplicate_str(s_str, s_len);
(gdb) p s_str
$3 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) f 3
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
541 url_host_set(m_heap, m_url_impl, value, length, true);
(gdb) p value
$4 = value optimized out
(gdb) p length
$5 = value optimized out
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out
[jira] [Commented] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257996#comment-13257996 ] Leif Hedstrom commented on TS-1130: --- Looks good to me. I couldn't see any other places where we use the atomic CAS on an ink_time_t, so this should be fine. Wei Jin, I'd say commit it! (Assuming you've tested it). ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Attachments: TS-1130.diff Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1212) can not limit ram cache
can not limit ram cache
---
Key: TS-1212
URL: https://issues.apache.org/jira/browse/TS-1212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 2.1.3
Environment: we are on v3.0.x but maybe affected v3.1 and later too.
Reporter: Zhao Yongming
ram cache limit is not activate at sometime:
{code}
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=12884901886
proxy.process.cache.volume_0.ram_cache.total_bytes=-7301066
proxy.process.cache.ram_cache.bytes_used=11840122880
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1212) can not limit ram cache
[
https://issues.apache.org/jira/browse/TS-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258003#comment-13258003
]
Zhao Yongming commented on TS-1212:
---
when you traffic_line -L restart the server, the total_bytes whill change:
{code}
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=10737418239
proxy.process.cache.volume_0.ram_cache.total_bytes=-79456895011
proxy.process.cache.ram_cache.bytes_used=0
proxy.process.cache.ram_cache.hits=0
proxy.process.cache.ram_cache.misses=0
proxy.process.cache.ram.read.success=0
proxy.process.cache.volume_0.ram_cache.bytes_used=0
proxy.process.cache.volume_0.ram_cache.hits=0
proxy.process.cache.volume_0.ram_cache.misses=0
proxy.process.cache.volume_0.ram.read.success=0
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=10737418239
proxy.process.cache.volume_0.ram_cache.total_bytes=-85899345956
proxy.process.cache.ram_cache.bytes_used=0
proxy.process.cache.ram_cache.hits=0
proxy.process.cache.ram_cache.misses=0
proxy.process.cache.ram.read.success=0
proxy.process.cache.volume_0.ram_cache.bytes_used=0
proxy.process.cache.volume_0.ram_cache.hits=0
proxy.process.cache.volume_0.ram_cache.misses=0
proxy.process.cache.volume_0.ram.read.success=0
{code}
can not limit ram cache
---
Key: TS-1212
URL: https://issues.apache.org/jira/browse/TS-1212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 2.1.3
Environment: we are on v3.0.x but maybe affected v3.1 and later too.
Reporter: Zhao Yongming
ram cache limit is not activate at sometime:
{code}
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=12884901886
proxy.process.cache.volume_0.ram_cache.total_bytes=-7301066
proxy.process.cache.ram_cache.bytes_used=11840122880
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1212) can not limit ram cache
[
https://issues.apache.org/jira/browse/TS-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258033#comment-13258033
]
Zhao Yongming commented on TS-1212:
---
in the codes:
{code}
static void reg_int(const char *str, int stat, RecRawStatBlock *rsb, const char
*prefix, RecRawStatSyncCb sync_cb=RecRawStatSyncSum) {
char stat_str[256];
snprintf(stat_str, sizeof(stat_str), %s.%s, prefix, str);
RecRegisterRawStat(rsb, RECT_PROCESS, stat_str, RECD_INT,
RECP_NON_PERSISTENT, stat, sync_cb);
DOCACHE_CLEAR_DYN_STAT(stat)
}
#define REG_INT(_str, _stat) reg_int(_str, (int)_stat, rsb, prefix)
// Register Stats
void
register_cache_stats(RecRawStatBlock *rsb, const char *prefix)
{
char stat_str[256];
// Special case for this sucker, since it uses its own aggregator.
reg_int(bytes_used, cache_bytes_used_stat, rsb, prefix,
cache_stats_bytes_used_cb);
REG_INT(bytes_total, cache_bytes_total_stat);
snprintf(stat_str, sizeof(stat_str), %s.%s, prefix,
ram_cache.total_bytes);
RecRegisterRawStat(rsb, RECT_PROCESS, stat_str, RECD_INT, RECP_NULL, (int)
cache_ram_cache_bytes_total_stat, RecRawStatSyncSum);
REG_INT(ram_cache.bytes_used, cache_ram_cache_bytes_stat);
REG_INT(ram_cache.hits, cache_ram_cache_hits_stat);
REG_INT(ram_cache.misses, cache_ram_cache_misses_stat);
REG_INT(pread_count, cache_pread_count_stat);
{code}
the ram_cache.total_bytes with prefix, is registered with RECP_NULL, while
others are RECP_NON_PERSISTENT, what does that mean?
from the codes, I think
RECP_NULL,
RECP_PERSISTENT,
are treat as RECP_PERSISTENT, and will be persistent between restart. why we
put here a RECP_NULL ??
can not limit ram cache
---
Key: TS-1212
URL: https://issues.apache.org/jira/browse/TS-1212
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 2.1.3
Environment: we are on v3.0.x but maybe affected v3.1 and later too.
Reporter: Zhao Yongming
ram cache limit is not activate at sometime:
{code}
[yonghao@cache177 ~]$ links -dump http://localhost:8080/stat/ | grep ram
proxy.config.cache.ram_cache.size=10737418240
proxy.config.cache.ram_cache_cutoff=131072
proxy.config.cache.ram_cache.algorithm=1
proxy.config.cache.ram_cache.compress=0
proxy.config.cache.ram_cache.ssd_percent=25
proxy.config.cache.ram_cache.compress_percent=90
proxy.process.cache.ram_cache.total_bytes=12884901886
proxy.process.cache.volume_0.ram_cache.total_bytes=-7301066
proxy.process.cache.ram_cache.bytes_used=11840122880
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1213) Crash report: update will crash at HttpTransact::process_quick_http_filter
Crash report: update will crash at HttpTransact::process_quick_http_filter
--
Key: TS-1213
URL: https://issues.apache.org/jira/browse/TS-1213
Project: Traffic Server
Issue Type: Bug
Environment: git master with update enabled.
Reporter: Zhao Yongming
the new ip_allow quick filter may affect the scheduled update functions:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/opt/ats/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x10bc0)[0x2ab9e4318bc0]
/opt/ats/bin/traffic_server(HttpTransact::process_quick_http_filter(HttpTransact::State*,
int)+0x3b)[0x5501db]
/opt/ats/bin/traffic_server(HttpTransact::EndRemapRequest(HttpTransact::State*)+0x3a1)[0x55ed91]
/opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x530202]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x54a)[0x54031a]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
/opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec]
/opt/ats/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x18f)[0x53b2df]
/opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x53c288]
/opt/ats/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x1c7)[0x576d97]
/opt/ats/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x197)[0x4fbd77]
/opt/ats/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x378)[0x4f7198]
/opt/ats/bin/traffic_server(EThread::process_event(Event*, int)+0x90)[0x6b0250]
/opt/ats/bin/traffic_server(EThread::execute()+0x5eb)[0x6b0e0b]
/opt/ats/bin/traffic_server[0x6af042]
/lib64/libpthread.so.0(+0x8e2c)[0x2ab9e4310e2c]
/lib64/libc.so.6(clone+0x6d)[0x2ab9e6beb35d]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
