[jira] [Updated] (TS-1443) add enable-gzip option for gzip plugin
[
https://issues.apache.org/jira/browse/TS-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Conan Wang updated TS-1443:
---
Attachment: gzip_enable_option.patch
> add enable-gzip option for gzip plugin
> --
>
> Key: TS-1443
> URL: https://issues.apache.org/jira/browse/TS-1443
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Plugins
>Reporter: Conan Wang
> Fix For: 3.3.1
>
> Attachments: gzip_enable_option.patch
>
>
> gzip plugin is global enabled. adding 'enable-gzip' option allows us to
> enable/disable the plugin for certain host.
> {code}
> #global config (here we disable gzip)
> enable-gzip false
> remove-accept-encoding false
> cache false
> compressible-content-type text/*
> disallow /notthis/*.js
> #override the global configuration for a host.⋅
> #www.foo.nl does NOT inherit anything
> [www.foo.nl]
> # (enable gzip in this host)
> enable-gzip true
> remove-accept-encoding true
> cache true
> compressible-content-type text/*
> compressible-content-type application/json
> compressible-content-type application/x-javascript
> {code}
--
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-1443) add enable-gzip option for gzip plugin
Conan Wang created TS-1443:
--
Summary: add enable-gzip option for gzip plugin
Key: TS-1443
URL: https://issues.apache.org/jira/browse/TS-1443
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, Plugins
Reporter: Conan Wang
Fix For: 3.3.1
gzip plugin is global enabled. adding 'enable-gzip' option allows us to
enable/disable the plugin for certain host.
{code}
#global config (here we disable gzip)
enable-gzip false
remove-accept-encoding false
cache false
compressible-content-type text/*
disallow /notthis/*.js
#override the global configuration for a host.⋅
#www.foo.nl does NOT inherit anything
[www.foo.nl]
# (enable gzip in this host)
enable-gzip true
remove-accept-encoding true
cache true
compressible-content-type text/*
compressible-content-type application/json
compressible-content-type application/x-javascript
{code}
--
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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450257#comment-13450257 ] weijin commented on TS-1405: @John, yes, the current code can ensure free a cancelled event in 5 seconds, but the patch can not ensure that, it may left in the PriorityEventQueue for a long time. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: kuotai >Assignee: kuotai > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- 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-1416) Heartbeat increases Cache Misses count
[
https://issues.apache.org/jira/browse/TS-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450172#comment-13450172
]
Phil Sorber commented on TS-1416:
-
02024e4 TS-1416: Do not do cache lookup if cop_test_page is true to stop
artificial increase of cache misses.
> Heartbeat increases Cache Misses count
> --
>
> Key: TS-1416
> URL: https://issues.apache.org/jira/browse/TS-1416
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.2.0
> Environment: Centos 6.3
>Reporter: Jon Cowie
>Priority: Minor
> Fix For: 3.3.1
>
> Attachments: cop_no_cache_lookup.diff
>
>
> With no network traffic going to the TS box, the following increase in Read
> Misses can be seen:
> {code}
> trafficserver> show:cache-stats
> Bytes Used --- 0 GB
> Cache Size --- 9 GB
> --RAM Cache--
> Total Bytes -- 10737418240
> Bytes Used --- 0
> Hits - 0
> Misses --- 0
> --Lookups--
> In Progress -- 0
> Hits - 0
> Misses --- 0
> --Reads--
> In Progress -- 0
> Hits - 0
> Misses --- 35
> --Writes--
> In Progress -- 0
> Hits - 0
> Misses --- 0
> --Updates--
> In Progress -- 0
> Hits - 0
> Misses --- 0
> --Removes--
> In Progress -- 0
> Hits - 0
> Misses --- 0
> {code}
> After discussion with PSUdaemon, he identified this as occurring as follows:
> {code}
> in iocore/cache/CacheRead.cc
> CACHE_INCREMENT_DYN_STAT(cache_read_failure_stat);
> {code}
> This isn't a particularly serious bug, but it does mean that when testing the
> box the Cache Miss count is artificially high.
--
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-1442) assertion fails when there is a transformation plugin active and lots of disconnects are done
[ https://issues.apache.org/jira/browse/TS-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf closed TS-1442. --- Resolution: Invalid sorry, closing this. i cannot reproduce this anymore. i think i had an incorrect build. > assertion fails when there is a transformation plugin active and lots of > disconnects are done > - > > Key: TS-1442 > URL: https://issues.apache.org/jira/browse/TS-1442 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.3.1 >Reporter: Otto van der Schaaf >Priority: Critical > > stack trace: > [Switching to Thread 0x73d7f700 (LWP 25497)] > 0x75a02445 in __GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0x75a02445 in __GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x75a05bab in __GI_abort () at abort.c:91 > #2 0x77bad734 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x77bad815 in ink_fatal_va(int, const char *, typedef > __va_list_tag __va_list_tag *) (return_code=1, > message_format=0x77bc99e0 "%s:%d: failed assert `%s`", > ap=0x73d7a848) at ink_error.cc:65 > #4 0x77bad8ce in ink_fatal (return_code=1, > message_format=0x77bc99e0 "%s:%d: failed assert `%s`") at ink_error.cc:73 > #5 0x77bac71c in _ink_assert (expression=0x70f490 "server_entry->vc > == c->producer->vc", file=0x70dae5 "HttpSM.cc", > line=2976) at ink_assert.cc:38 > #6 0x0056e12c in HttpSM::tunnel_handler_ua (this=0x7fffe2ec6eb0, > event=104, c=0x7fffe2ec8b58) at HttpSM.cc:2976 > #7 0x005b3a99 in HttpTunnel::consumer_handler (this=0x7fffe2ec8a38, > event=104, c=0x7fffe2ec8b58) at HttpTunnel.cc:1243 > #8 0x005b41f3 in HttpTunnel::main_handler (this=0x7fffe2ec8a38, > event=104, data=0x7fffdc0159c0) at HttpTunnel.cc:1467 > #9 0x004e36ee in Continuation::handleEvent (this=0x7fffe2ec8a38, > event=104, data=0x7fffdc0159c0) > at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x00566d1e in HttpSM::state_watch_for_client_abort > (this=0x7fffe2ec6eb0, event=104, data=0x7fffdc015950) at HttpSM.cc:873 > #11 0x0056c296 in HttpSM::main_handler (this=0x7fffe2ec6eb0, > event=104, data=0x7fffdc015950) at HttpSM.cc:2444 > #12 0x004e36ee in Continuation::handleEvent (this=0x7fffe2ec6eb0, > event=104, data=0x7fffdc015950) > at ../iocore/eventsystem/I_Continuation.h:146 > #13 0x006c17f4 in read_signal_and_update (event=104, > vc=0x7fffdc015840) at UnixNetVConnection.cc:138 > #14 0x006c19a6 in read_signal_done (event=104, nh=0x741871e8, > vc=0x7fffdc015840) at UnixNetVConnection.cc:168 > #15 0x006c1f1e in read_from_net (nh=0x741871e8, > vc=0x7fffdc015840, thread=0x74184010) at UnixNetVConnection.cc:291 > #16 0x006c3d27 in UnixNetVConnection::net_read_io > (this=0x7fffdc015840, nh=0x741871e8, lthread=0x74184010) > at UnixNetVConnection.cc:816 > #17 0x006be5e9 in NetHandler::mainNetEvent (this=0x741871e8, > event=5, e=0x10ac160) at UnixNet.cc:372 > #18 0x004e36ee in Continuation::handleEvent (this=0x741871e8, > event=5, data=0x10ac160) > at ../iocore/eventsystem/I_Continuation.h:146 > #19 0x006e427a in EThread::process_event (this=0x74184010, > e=0x10ac160, calling_code=5) at UnixEThread.cc:142 > #20 0x006e481c in EThread::execute (this=0x74184010) at > UnixEThread.cc:264 > #21 0x006e34c2 in spawn_thread_internal (a=0x10a6560) at Thread.cc:88 > #22 0x7797be9a in start_thread (arg=0x73d7f700) at > pthread_create.c:308 > #23 0x75abe4bd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #24 0x in ?? () -- 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-1442) assertion fails when there is a transformation plugin active and lots of disconnects are done
[ https://issues.apache.org/jira/browse/TS-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf updated TS-1442: Description: stack trace: [Switching to Thread 0x73d7f700 (LWP 25497)] 0x75a02445 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x75a02445 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x75a05bab in __GI_abort () at abort.c:91 #2 0x77bad734 in ink_die_die_die (retval=1) at ink_error.cc:43 #3 0x77bad815 in ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) (return_code=1, message_format=0x77bc99e0 "%s:%d: failed assert `%s`", ap=0x73d7a848) at ink_error.cc:65 #4 0x77bad8ce in ink_fatal (return_code=1, message_format=0x77bc99e0 "%s:%d: failed assert `%s`") at ink_error.cc:73 #5 0x77bac71c in _ink_assert (expression=0x70f490 "server_entry->vc == c->producer->vc", file=0x70dae5 "HttpSM.cc", line=2976) at ink_assert.cc:38 #6 0x0056e12c in HttpSM::tunnel_handler_ua (this=0x7fffe2ec6eb0, event=104, c=0x7fffe2ec8b58) at HttpSM.cc:2976 #7 0x005b3a99 in HttpTunnel::consumer_handler (this=0x7fffe2ec8a38, event=104, c=0x7fffe2ec8b58) at HttpTunnel.cc:1243 #8 0x005b41f3 in HttpTunnel::main_handler (this=0x7fffe2ec8a38, event=104, data=0x7fffdc0159c0) at HttpTunnel.cc:1467 #9 0x004e36ee in Continuation::handleEvent (this=0x7fffe2ec8a38, event=104, data=0x7fffdc0159c0) at ../iocore/eventsystem/I_Continuation.h:146 #10 0x00566d1e in HttpSM::state_watch_for_client_abort (this=0x7fffe2ec6eb0, event=104, data=0x7fffdc015950) at HttpSM.cc:873 #11 0x0056c296 in HttpSM::main_handler (this=0x7fffe2ec6eb0, event=104, data=0x7fffdc015950) at HttpSM.cc:2444 #12 0x004e36ee in Continuation::handleEvent (this=0x7fffe2ec6eb0, event=104, data=0x7fffdc015950) at ../iocore/eventsystem/I_Continuation.h:146 #13 0x006c17f4 in read_signal_and_update (event=104, vc=0x7fffdc015840) at UnixNetVConnection.cc:138 #14 0x006c19a6 in read_signal_done (event=104, nh=0x741871e8, vc=0x7fffdc015840) at UnixNetVConnection.cc:168 #15 0x006c1f1e in read_from_net (nh=0x741871e8, vc=0x7fffdc015840, thread=0x74184010) at UnixNetVConnection.cc:291 #16 0x006c3d27 in UnixNetVConnection::net_read_io (this=0x7fffdc015840, nh=0x741871e8, lthread=0x74184010) at UnixNetVConnection.cc:816 #17 0x006be5e9 in NetHandler::mainNetEvent (this=0x741871e8, event=5, e=0x10ac160) at UnixNet.cc:372 #18 0x004e36ee in Continuation::handleEvent (this=0x741871e8, event=5, data=0x10ac160) at ../iocore/eventsystem/I_Continuation.h:146 #19 0x006e427a in EThread::process_event (this=0x74184010, e=0x10ac160, calling_code=5) at UnixEThread.cc:142 #20 0x006e481c in EThread::execute (this=0x74184010) at UnixEThread.cc:264 #21 0x006e34c2 in spawn_thread_internal (a=0x10a6560) at Thread.cc:88 #22 0x7797be9a in start_thread (arg=0x73d7f700) at pthread_create.c:308 #23 0x75abe4bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x in ?? () > assertion fails when there is a transformation plugin active and lots of > disconnects are done > - > > Key: TS-1442 > URL: https://issues.apache.org/jira/browse/TS-1442 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.3.1 >Reporter: Otto van der Schaaf >Priority: Critical > > stack trace: > [Switching to Thread 0x73d7f700 (LWP 25497)] > 0x75a02445 in __GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0x75a02445 in __GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x75a05bab in __GI_abort () at abort.c:91 > #2 0x77bad734 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x77bad815 in ink_fatal_va(int, const char *, typedef > __va_list_tag __va_list_tag *) (return_code=1, > message_format=0x77bc99e0 "%s:%d: failed assert `%s`", > ap=0x73d7a848) at ink_error.cc:65 > #4 0x77bad8ce in ink_fatal (return_code=1, > message_format=0x77bc99e0 "%s:%d: failed assert `%s`") at ink_error.cc:73 > #5 0x77bac71c in _ink_assert (expression=0x70f490 "server_entry->vc > == c->producer->vc", file=0x70dae5 "HttpSM.cc", > line=2976) at ink_assert.cc:38 > #6 0x0056e12c in HttpSM::tunnel_handler_ua (this=0x7fffe2ec6eb0, > event=104, c=0x7fffe2ec8b58) at HttpSM.cc:
[jira] [Created] (TS-1442) assertion fails when there is a transformation plugin active and lots of disconnects are done
Otto van der Schaaf created TS-1442: --- Summary: assertion fails when there is a transformation plugin active and lots of disconnects are done Key: TS-1442 URL: https://issues.apache.org/jira/browse/TS-1442 Project: Traffic Server Issue Type: Bug Affects Versions: 3.3.1 Reporter: Otto van der Schaaf Priority: Critical -- 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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449953#comment-13449953 ] John Plevyak commented on TS-1405: -- weijin: I don't know that freeing it as soon as possible is as big a goal as race conditions are a problem :) The current code can take up to 5 seconds to free a cancelled event, so this code is much better in that regard, even if we have to wait for the next time the event loop runs. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: kuotai >Assignee: kuotai > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- 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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449950#comment-13449950 ] John Plevyak commented on TS-1405: -- There is a race between the adding into the atomic list in the cancelling thread, getting dequeued in the controlling thread, and the setting of the cancelled flag in the cancelling thread. One solution is to take the mutex lock in the check_ready code as the cancelling thread must be holding that lock over the insert into the atomic list and setting the cancelled flag. Note, you could set the cancelled flag before adding to the atomic list and then just ignore it in process_thread() (and any other place) counting on it getting free'd eventually via the atomic list. > apply time-wheel scheduler about event system > -- > > Key: TS-1405 > URL: https://issues.apache.org/jira/browse/TS-1405 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.2.0 >Reporter: kuotai >Assignee: kuotai > Fix For: 3.3.1 > > Attachments: linux_time_wheel.patch > > > when have more and more event in event system scheduler, it's worse. This is > the reason why we use inactivecop to handler keepalive. the new scheduler is > time-wheel. It's have better time complexity(O(1)) -- 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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449909#comment-13449909
]
David Carlin commented on TS-1330:
--
This time I got a core dump!
Here is stack trace from traffic.out - looks same/similar as those above:
[Sep 6 18:00:00.008] Server {0x2ba8bbf7a700} STATUS: The logfile
/home/y/logs/trafficserver/error.log was rolled to
/home/y/logs/trafficserver/error.log_l12.ycs.a4e.yahoo.com.20120906.15h59m55s-20120906.18h00m00s.old.
[Sep 6 18:00:00.008] Server {0x2ba8bbf7a700} STATUS: The logfile
/home/y/logs/trafficserver/squid.blog was rolled to
/home/y/logs/trafficserver/squid.blog_l12.ycs.a4e.yahoo.com.20120906.16h00m00s-20120906.18h00m00s.old.
[Sep 6 18:00:52.595] Server {0x2ba894b0a700} NOTE: Traffic Server is skipping
the current log entry for squid.blog because its size (26344) exceeds the
maximum payload space in a log buffer
[Sep 6 18:02:00.938] Server {0x2ba894c0b700} NOTE: Traffic Server is skipping
the current log entry for squid.blog because its size (26336) exceeds the
maximum payload space in a log buffer
[Sep 6 18:06:13.471] Server {0x2ba895211700} NOTE: Traffic Server is skipping
the current log entry for squid.blog because its size (26496) exceeds the
maximum payload space in a log buffer
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x359c60f490]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/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[0x359c6077e1]
/lib64/libc.so.6(clone+0x6d)[0x359c2e577d]
Backtrace:
#0 LogBuffer::checkout_write (this=,
write_offset=0x2ba894c0a888, write_size=) at
LogBuffer.cc:289
#1 0x005a64c8 in LogObject::_checkout_write (this=0x346e580,
write_offset=0x2ba894c0a888, bytes_needed=488) at LogObject.cc:424
#2 0x005a7e30 in LogObject::log (this=0x346e580, lad=0x2ba894c0aa70,
text_entry=0x0) at LogObject.cc:579
#3 0x0058f506 in log (lad=0x2ba894c0aa70) at LogObject.h:395
#4 Log::access (lad=0x2ba894c0aa70) at Log.cc:1117
#5 0x00526c50 in HttpSM::update_stats (this=0x2baa37537430) at
HttpSM.cc:6340
#6 0x0052b548 in HttpSM::kill_this (this=0x2baa37537430) at
HttpSM.cc:6301
#7 0x0052b868 in HttpSM::main_handler (this=0x2baa37537430,
event=2301, data=0x2baa37538fa0) at HttpSM.cc:2460
#8 0x0056c3ee in handleEvent (this=0x2baa37538fa0, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#9 HttpTunnel::main_handler (this=0x2baa37538fa0, event=,
data=) at HttpTunnel.cc:1479
#10 0x00673871 in handleEvent (event=,
nh=0x2ba8940031e8, vc=0x2ba94c2edd40) at
../../iocore/eventsystem/I_Continuation.h:146
#11 write_signal_and_update (event=, nh=0x2ba8940031e8,
vc=0x2ba94c2edd40) at UnixNetVConnection.cc:153
#12 write_signal_done (event=, nh=0x2ba8940031e8,
vc=0x2ba94c2edd40) at UnixNetVConnection.cc:180
#13 0x006756e7 in write_to_net_io (nh=0x2ba8940031e8,
vc=0x2ba94c2edd40, thread=) at UnixNetVConnection.cc:479
#14 0x0066e076 in NetHandler::mainNetEvent (this=0x2ba8940031e8,
event=, e=) at UnixNet.cc:397
#15 0x00696ce4 in handleEvent (this=0x2ba89410, e=0x3165680,
calling_code=5) at I_Continuation.h:146
#16 EThread::process_event (this=0x2ba89410, e=0x3165680, calling_code=5)
at UnixEThread.cc:142
#17 0x00697673 in EThread::execute (this=0x2ba89410) at
UnixEThread.cc:264
#18 0x00695cb2 in spawn_thread_internal (a=0x30fb350) at Thread.cc:88
#19 0x00359c6077e1 in start_thread () from /lib64/libpthread.so.0
#20 0x00359c2e577d in clone () from /lib64/libc.so.6
> Logging related segfault in 3.2.0
> -
>
> Key: TS-1330
> URL: https://issues.apache.org/jira/browse/TS-1330
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment:
[jira] [Updated] (TS-1441) fix possible null reference to configuration in gzip plugin
[ https://issues.apache.org/jira/browse/TS-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf updated TS-1441: Attachment: gzip (3).diff > fix possible null reference to configuration in gzip plugin > --- > > Key: TS-1441 > URL: https://issues.apache.org/jira/browse/TS-1441 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: 3.3.1 > > Attachments: gzip (3).diff > > -- 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-1441) fix possible null reference to configuration in gzip plugin
Otto van der Schaaf created TS-1441: --- Summary: fix possible null reference to configuration in gzip plugin Key: TS-1441 URL: https://issues.apache.org/jira/browse/TS-1441 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 3.3.1 -- 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-1316) ATS connection refused once cache direntries exhausted
[
https://issues.apache.org/jira/browse/TS-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449797#comment-13449797
]
David Carlin commented on TS-1316:
--
Still seeing this issue occasionally crop up even with
proxy.config.cache.min_average_object_size = 8000
No core dump was created.
[Sep 6 15:44:16.271] Server {0x2ae640dc7860} WARNING: cache directory overflow
on '/dev/dm-4' segment 365, purging...
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x332ce0f500]
/home/y/lib64/libtsutil.so.3(ink_atomiclist_popall+0x64)[0x2ae64030bbb4]
/home/y/bin/traffic_server(_ZN16LogBufferManager13flush_buffersEP13LogBufferSink+0x1f)[0x5a6fef]
/home/y/bin/traffic_server(_ZN16LogObjectManager13flush_buffersEv+0x28)[0x5a7ac8]
/home/y/bin/traffic_server(_ZN3Log17flush_thread_mainEPv+0xaa)[0x58fdca]
/home/y/bin/traffic_server(_ZN24LoggingFlushContinuation9mainEventEiPv+0xb)[0x5932bb]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0xb86)[0x697d36]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x332ce07851]
/lib64/libc.so.6(clone+0x6d)[0x332cae767d]
> ATS connection refused once cache direntries exhausted
> --
>
> Key: TS-1316
> URL: https://issues.apache.org/jira/browse/TS-1316
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 3.2.0
> Environment: RHEL 6.2 x86_64
>Reporter: David Carlin
> Fix For: 3.3.1
>
>
> We had a pair of ATS 3.2.0 boxes that stopped passing traffic simultaneously.
> Here are the traffic.out msgs we saw on both boxes:
> [Jun 22 05:53:27.637] Server {0x2b6b6d9da700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 36, purging...
> [Jun 22 05:56:05.542] Server {0x2b6b6d2d3700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 85, purging...
> [Jun 22 05:56:07.434] Server {0x2b6b6d4d5700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 71, purging...
> [Jun 22 05:58:24.743] Server {0x2b6b6d8d9700} WARNING: cache directory
> overflow on '/dev/dm-4' segment 33, purging...
> Those messages went on for a couple minutes, then traffic apparently ceased -
> our monitoring system saw connection refused for port 80 on ATS from then on.
> The connection refused state went on for many hours until ATS was restarted.
> There were no traffic_cop msgs in /var/log/messages indicating that the
> heartbeat failed.
> Here are the relevant ATS settings/stats:
> proxy.process.cache.bytes_total = 190690320384
> proxy.process.cache.direntries.total = 5817752
> proxy.config.cache.min_average_object_size = 32768
> We previously came up with proxy.config.cache.min_average_object_size by
> waiting for the cache to fill and dividing proxy.process.cache.bytes_used by
> proxy.process.cache.direntries.used - which equals about 34KB.
> We're assuming ATS ran out of direntries and it didn't handle this situation
> gracefully. As a possible workaround, I'm going to lower
> proxy.config.cache.min_average_object_size to 24KB.
> Thanks to Bryan Call for helping me troubleshoot this!
--
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-1064) logging format update
[ https://issues.apache.org/jira/browse/TS-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449549#comment-13449549 ] Daniel Gruno commented on TS-1064: -- Just took a look at Log.cc - shouldn't have done that ;) There is a ton of logging options we haven't documented yet. I'll take a stab at (at least) adding the options to the documentation and the log builder tomorrow, if no one beats me to it. > logging format update > - > > Key: TS-1064 > URL: https://issues.apache.org/jira/browse/TS-1064 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Trivial > Fix For: Doc 3.2 > > > % is not documented so far, we should make sure all those hiding items > documented. -- 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
