[jira] [Reopened] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-3156:
---
Backport to Version: 5.2.0
This causes very frequent crashes, in the TLS session manager.
{code}
#0 Mutex_lock (t=0x306, m=0x0) at ../../iocore/eventsystem/I_Lock.h:391
#1 acquire (t=0x306, this=0x2b4c654c64c0) at
../../iocore/eventsystem/I_Lock.h:517
#2 SSLSessionBucket::getSession (this=this@entry=0x28b9c08, id=...,
sess=sess@entry=0x2b4c654c65b0) at SSLSessionCache.cc:160
#3 0x007463bf in SSLSessionCache::getSession (this=,
sid=..., sess=sess@entry=0x2b4c654c65b0)
at SSLSessionCache.cc:63
#4 0x007242f9 in ssl_get_cached_session (ssl=0x21324200, id=, len=, copy=)
at SSLUtils.cc:194
#5 0x2b4c5edcc602 in ssl_get_prev_session (s=s@entry=0x21324200,
session_id=0x213c8027
"\340\250\\\347\363N\020\024\066(\257#>\027\234\206\345\316.\313\347?\257GM\310@\356\316\002\031-",
len=len@entry=32, limit=limit@entry=0x213c80a2 "") at ssl_sess.c:528
#6 0x2b4c5eda2953 in ssl3_get_client_hello (s=s@entry=0x21324200) at
s3_srvr.c:1017
#7 0x2b4c5eda73dd in ssl3_accept (s=0x21324200) at s3_srvr.c:357
#8 0x2b4c5edb4e58 in ssl23_accept (s=0x21324200) at s23_srvr.c:210
#9 0x00729499 in SSLAccept (ssl=0x21324200) at SSLUtils.cc:1829
#10 0x0071ecbd in SSLNetVConnection::sslServerHandShakeEvent
(this=this@entry=0x4350f50, err=@0x2b4c654c6c40: 70681056)
at SSLNetVConnection.cc:954
#11 0x0071f641 in SSLNetVConnection::sslStartHandShake (this=0x4350f50,
event=, err=@0x2b4c654c6c40: 70681056)
at SSLNetVConnection.cc:873
#12 0x0072110e in SSLNetVConnection::net_read_io (this=0x4350f50,
nh=0x3063ac0, lthread=0x306) at SSLNetVConnection.cc:433
#13 0x0072b8e2 in NetHandler::mainNetEvent (this=0x3063ac0,
event=, e=) at UnixNet.cc:399
#14 0x0075aa0a in handleEvent (data=0x22752e0, event=5, this=) at I_Continuation.h:146
#15 process_event (calling_code=5, e=0x22752e0, this=0x306) at
UnixEThread.cc:144
#16 EThread::execute (this=0x306) at UnixEThread.cc:268
#17 0x0075947a in spawn_thread_internal (a=0x1c3e870) at Thread.cc:88
#18 0x2b4c6087eee5 in start_thread (arg=0x2b4c654c7700) at
pthread_create.c:309
#19 0x2b4c6191ab8d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) frame 1
#1 acquire (t=0x306, this=0x2b4c654c64c0) at
../../iocore/eventsystem/I_Lock.h:517
517 MUTEX_TAKE_LOCK(m.m_ptr, t);
(gdb) print m
$10 = {m_ptr = 0x0}
{code}
> Mutex[Try]Lock bool() operator change and unused API removal
>
>
> Key: TS-3156
> URL: https://issues.apache.org/jira/browse/TS-3156
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Powell Molleti
>Assignee: James Peach
>Priority: Minor
> Labels: review
> Fix For: 5.2.0
>
> Attachments: MutexLock-ats.patch, MutexLock-ats.patch,
> Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch
>
>
> Removed unused constructor in MutexLock along with set_and_take() method, had
> to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
> default bool and ! operator from both MutexLock and MutexTryLock with
> is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
> base.
> Ran make test will be performing more system testing. Posted before for early
> comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219433#comment-14219433
]
Leif Hedstrom commented on TS-3156:
---
I reverted these two commits on docs.trafficserver.apache.org, which made the
crashes stop
{code}
53e56ffc7499648bc096d63f9c0f9da0ea9212ba
1fc0fd0fe9bca2802543ae0a55bb80e8817a6e31
{code}
> Mutex[Try]Lock bool() operator change and unused API removal
>
>
> Key: TS-3156
> URL: https://issues.apache.org/jira/browse/TS-3156
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Powell Molleti
>Assignee: James Peach
>Priority: Minor
> Labels: review
> Fix For: 5.2.0
>
> Attachments: MutexLock-ats.patch, MutexLock-ats.patch,
> Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch
>
>
> Removed unused constructor in MutexLock along with set_and_take() method, had
> to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
> default bool and ! operator from both MutexLock and MutexTryLock with
> is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
> base.
> Ran make test will be performing more system testing. Posted before for early
> comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[ https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219573#comment-14219573 ] ASF subversion and git services commented on TS-3156: - Commit 74d29be0ed7c925b39cfea9d2e347b6a71b12c16 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=74d29be ] TS-3156: use a proxy allocated mutex > Mutex[Try]Lock bool() operator change and unused API removal > > > Key: TS-3156 > URL: https://issues.apache.org/jira/browse/TS-3156 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Powell Molleti >Assignee: James Peach >Priority: Minor > Labels: review > Fix For: 5.2.0 > > Attachments: MutexLock-ats.patch, MutexLock-ats.patch, > Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch > > > Removed unused constructor in MutexLock along with set_and_take() method, had > to change FORCE_PLUGIN_MUTEX() for that. Removed release() method. > default bool and ! operator from both MutexLock and MutexTryLock with > is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code > base. > Ran make test will be performing more system testing. Posted before for early > comments / feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2633: --- Assignee: Sudheer Vinukonda (was: Bryan Call) > 406 negative responses being cached for too long > > > Key: TS-2633 > URL: https://issues.apache.org/jira/browse/TS-2633 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 4.0.2 >Reporter: David Carlin >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.2.0 > > > Settings: > proxy.config.http.negative_caching_enabled = 1 > proxy.config.http.negative_caching_lifetime = 500 > 406 response is being cached, but lifetime isn't being adhered to. They are > cached for much longer, perhaps indefinitely. I have seen Age: increase to > several hours. > With proxy.config.http.negative_caching_enabled = 0 then 406 responses are > not cached. > Bryan pointed out that the docs don't list 406 as one of the cached negative > responses: > http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html > The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on > this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2633: --- Fix Version/s: (was: 5.2.0) 5.3.0 > 406 negative responses being cached for too long > > > Key: TS-2633 > URL: https://issues.apache.org/jira/browse/TS-2633 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 4.0.2 >Reporter: David Carlin >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.3.0 > > > Settings: > proxy.config.http.negative_caching_enabled = 1 > proxy.config.http.negative_caching_lifetime = 500 > 406 response is being cached, but lifetime isn't being adhered to. They are > cached for much longer, perhaps indefinitely. I have seen Age: increase to > several hours. > With proxy.config.http.negative_caching_enabled = 0 then 406 responses are > not cached. > Bryan pointed out that the docs don't list 406 as one of the cached negative > responses: > http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html > The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on > this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2644) TOS (DSCP)
[ https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2644: --- Fix Version/s: (was: 5.2.0) 5.3.0 > TOS (DSCP) > --- > > Key: TS-2644 > URL: https://issues.apache.org/jira/browse/TS-2644 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, Network >Reporter: Faysal Banna >Assignee: Phil Sorber > Labels: review > Fix For: 5.3.0 > > Attachments: domain_tos.cc > > > Hi Guys > I wonder if it would be possible to have a plugin that we can assign TOS/DSCP > bits to the objects that are being a cache HIT or maybe object type of > video/audio. > such a plugin would give us better performance and control on how to > distribute the output of the cache towards clients. > example : > suppose i set traffic to clients each of different bandwidth. > on a router on a link somewhere on some roof top building i can say this > client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the > cache. > this way if this client is getting a cached object he would get it in 1Mbit/s > while his non cached requests would be of 512Kbit/s > hope whoever does this patch plugin takes into consideration the mime type or > url of the object being retrieved maybe i want to set audio/video being > cached or not to have 768Kbit/s while windows updates and android/iphone apps > should take no more than 512kbit/s > bear in mind that this has nothing to do with Origin servers throttling > feature request. this is just client side feature set. > much regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2645) Crash in HttpTunnel
[ https://issues.apache.org/jira/browse/TS-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2645: --- Fix Version/s: (was: 5.2.0) 5.3.0 > Crash in HttpTunnel > --- > > Key: TS-2645 > URL: https://issues.apache.org/jira/browse/TS-2645 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Peter Walsh > Fix For: 5.3.0 > > > Occasionally we are seeing crashes after the event > TS_EVENT_HTTP_SEND_RESPONSE_HDR. We are working on trying to reproduce this, > however because it happens only every couple days we have so far not > identified the cause. I will update this ticket as I gather more > information. > /usr/local/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3f8380eca0] > /usr/local/bin/traffic_server(HttpTunnel::producer_run(HttpTunnelProducer*)+0x630)[0x573fb0] > /usr/local/bin/traffic_server(HttpTunnel::tunnel_run(HttpTunnelProducer*)+0xd6)[0x574b96] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x90)[0x52e020] > /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x9e)[0x5311ae] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2645) Crash in HttpTunnel
[ https://issues.apache.org/jira/browse/TS-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2645: -- Assignee: Susan Hinrichs > Crash in HttpTunnel > --- > > Key: TS-2645 > URL: https://issues.apache.org/jira/browse/TS-2645 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Peter Walsh >Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > Occasionally we are seeing crashes after the event > TS_EVENT_HTTP_SEND_RESPONSE_HDR. We are working on trying to reproduce this, > however because it happens only every couple days we have so far not > identified the cause. I will update this ticket as I gather more > information. > /usr/local/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3f8380eca0] > /usr/local/bin/traffic_server(HttpTunnel::producer_run(HttpTunnelProducer*)+0x630)[0x573fb0] > /usr/local/bin/traffic_server(HttpTunnel::tunnel_run(HttpTunnelProducer*)+0xd6)[0x574b96] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x90)[0x52e020] > /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x9e)[0x5311ae] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2653) SSL Error message cleanup
[
https://issues.apache.org/jira/browse/TS-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2653:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> SSL Error message cleanup
> -
>
> Key: TS-2653
> URL: https://issues.apache.org/jira/browse/TS-2653
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, SSL
>Reporter: Bryan Call
>Assignee: Susan Hinrichs
> Fix For: 5.3.0
>
>
> We see a lot of SSL error messages in production. It would be good to
> determine if these are really errors or remove logging of some of these
> errors:
> {code}
> -bash-4.1$ tail -10 diags.log | cut -f4-20 -d : | grep SSL | sort | uniq
> -c | sort -rn
>3108 SSL::36:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3079 SSL::32:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3068 SSL::27:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3051 SSL::44:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3043 SSL::24:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::47:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::38:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3040 SSL::46:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::34:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::25:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3021 SSL::31:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3011 SSL::42:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3006 SSL::39:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3004 SSL::29:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3000 SSL::30:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2996 SSL::43:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2993 SSL::45:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2977 SSL::40:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2976 SSL::33:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::41:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2974 SSL::28:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2958 SSL::37:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2947 SSL::35:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2922 SSL::26:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
> 28 SSL::36:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 26 SSL::24:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::44:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 25 SSL::27:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::34:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 24 SSL::30:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::39:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::33:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 23 SSL::32:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert number 45
> 22 SSL::44:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
> unknown ca:s3_pkt.c:1256:SSL alert number 48
> 21 SSL::38:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate expired:s3_pkt.c:1256:SSL alert
[jira] [Updated] (TS-2668) need a way to fetch from the cluster when doing cluster local caching
[ https://issues.apache.org/jira/browse/TS-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2668: -- Assignee: Zhao Yongming (was: weijin) > need a way to fetch from the cluster when doing cluster local caching > - > > Key: TS-2668 > URL: https://issues.apache.org/jira/browse/TS-2668 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache, Clustering >Reporter: Zhao Yongming >Assignee: Zhao Yongming > Fix For: sometime > > > this is the TS-2184 #2 feature subtask. > when you want do local caching in cluster env, you must tell cache to write > done to the local disk when cluster hit. we need a good way to handle this. > maybe a new API or similar API changes. > be aware, the #2 feature may harms, and should be co-working with the other > features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2655) about traffic server clients prohibited by ip-allow policy log
[ https://issues.apache.org/jira/browse/TS-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219652#comment-14219652 ] Susan Hinrichs commented on TS-2655: Log rotation will make this issue less bad. > about traffic server clients prohibited by ip-allow policy log > -- > > Key: TS-2655 > URL: https://issues.apache.org/jira/browse/TS-2655 > Project: Traffic Server > Issue Type: Improvement >Reporter: skylander > Fix For: sometime > > > 现在日志是写在了diags.log，不合理。 > 日志最好是能自己定义写到哪个目录，这样如果不想要这日志的，就可以写到/dev/null了。 > 如果实施起来很麻烦的话，也可以在日志目录下独立一个文件来存放这样的日志。如：var/log/trafficserver/ip_allow.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2668) need a way to fetch from the cluster when doing cluster local caching
[ https://issues.apache.org/jira/browse/TS-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2668: --- Assignee: (was: Zhao Yongming) > need a way to fetch from the cluster when doing cluster local caching > - > > Key: TS-2668 > URL: https://issues.apache.org/jira/browse/TS-2668 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache, Clustering >Reporter: Zhao Yongming > Fix For: sometime > > > this is the TS-2184 #2 feature subtask. > when you want do local caching in cluster env, you must tell cache to write > done to the local disk when cluster hit. we need a good way to handle this. > maybe a new API or similar API changes. > be aware, the #2 feature may harms, and should be co-working with the other > features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2680) Occasional crash in HdrHeap
[ https://issues.apache.org/jira/browse/TS-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219663#comment-14219663 ] Susan Hinrichs commented on TS-2680: [~peter.wa...@disney.com] could you try 5.x and see if the fix that Sudheer mentions fixes this for you? > Occasional crash in HdrHeap > --- > > Key: TS-2680 > URL: https://issues.apache.org/jira/browse/TS-2680 > Project: Traffic Server > Issue Type: Bug >Reporter: Peter Walsh > Labels: crash > Fix For: sometime > > > Every few days we are seeing a crash in HdrHeap. We have not been able to > reproduce in test environments, but will attach additional information when > we do. > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/local/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3583c0eca0] > /usr/local/bin/traffic_server(HdrHeap::attach_block(IOBufferBlock*, char > const*)+0x80)[0x5c13f0] > /usr/local/bin/traffic_server(HTTPHdr::parse_resp(HTTPParser*, > IOBufferReader*, int*, bool)+0x15d)[0x5c15fd] > /usr/local/bin/traffic_server(HttpSM::state_read_server_response_header(int, > void*)+0x138)[0x52eea8] > /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xdc)[0x530fec] > /usr/local/bin/traffic_server[0x69415b] > /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int, > Event*)+0x479)[0x68a2c9] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x22f)[0x6b9bbf] > /usr/local/bin/traffic_server(EThread::execute()+0x5bc)[0x6ba4cc] > /usr/local/bin/traffic_server[0x6b900e] > /lib64/libpthread.so.0[0x3583c0683d] > /lib64/libc.so.6(clone+0x6d)[0x35834d526d] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2681) Crash in MIOBuffer write_avail
[ https://issues.apache.org/jira/browse/TS-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219666#comment-14219666 ] Susan Hinrichs commented on TS-2681: [~peter.wa...@disney.com] have you seen any more on this? Or tried this with a later build? If not, could we close this? > Crash in MIOBuffer write_avail > -- > > Key: TS-2681 > URL: https://issues.apache.org/jira/browse/TS-2681 > Project: Traffic Server > Issue Type: Bug >Reporter: Peter Walsh > Labels: crash > Fix For: sometime > > > We have only seen this happen once but since it is a crasher I wanted to > document it as a bug. I will update this ticket as I gather additional data. > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/local/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3583c0eca0] > /usr/local/bin/traffic_server(MIOBuffer::write_avail()+0x30)[0x696090] > /usr/local/bin/traffic_server(write_to_net_io(NetHandler*, > UnixNetVConnection*, EThread*)+0x9e3)[0x692353] > /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int, > Event*)+0x460)[0x68a2b0] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x22f)[0x6b9bbf] > /usr/local/bin/traffic_server(EThread::execute()+0x5bc)[0x6ba4cc] > /usr/local/bin/traffic_server[0x6b900e] > /lib64/libpthread.so.0[0x3583c0683d] > /lib64/libc.so.6(clone+0x6d)[0x35834d526d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-2682. --- Resolution: Fixed Resolved. > Add per remap configuration / activation to background_fetch > > > Key: TS-2682 > URL: https://issues.apache.org/jira/browse/TS-2682 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-2683. --- Resolution: Fixed Resolved. > Add some control for which content to activate the background_fetch plugin > -- > > Key: TS-2683 > URL: https://issues.apache.org/jira/browse/TS-2683 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > > This would be both in global and per-remap configurations. Such as, only > trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2685) TSHttpEventNameLookup can't lookup TSEvent values
[
https://issues.apache.org/jira/browse/TS-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2685:
---
Assignee: Meera Mosale Nataraja
> TSHttpEventNameLookup can't lookup TSEvent values
> -
>
> Key: TS-2685
> URL: https://issues.apache.org/jira/browse/TS-2685
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: Meera Mosale Nataraja
> Fix For: sometime
>
>
> {{TSHttpEventNameLookup}} can't look up {{TSEvent}} values, see the
> implementation of {{HttpDebugNames::get_event_name}}.
> It would also be pretty neat if it formatted the event class if it didn't
> know about the specific event, e.g. {{ICP_EVENT_EVENTS_START+22}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1015: --- Assignee: Meera Mosale Nataraja > TSEvent is widely declared as int > - > > Key: TS-1015 > URL: https://issues.apache.org/jira/browse/TS-1015 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: Nick Kew >Assignee: Meera Mosale Nataraja >Priority: Minor > Labels: api-change, newbie > Fix For: 5.3.0 > > > TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is > declared as type int. This makes it harder to follow/debug using tools like > *trace or gdb. > This may usefully be fixed as and when people encounter instances of it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2685) TSHttpEventNameLookup can't lookup TSEvent values
[
https://issues.apache.org/jira/browse/TS-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2685:
---
Fix Version/s: (was: sometime)
5.3.0
> TSHttpEventNameLookup can't lookup TSEvent values
> -
>
> Key: TS-2685
> URL: https://issues.apache.org/jira/browse/TS-2685
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: Meera Mosale Nataraja
> Fix For: 5.3.0
>
>
> {{TSHttpEventNameLookup}} can't look up {{TSEvent}} values, see the
> implementation of {{HttpDebugNames::get_event_name}}.
> It would also be pretty neat if it formatted the event class if it didn't
> know about the specific event, e.g. {{ICP_EVENT_EVENTS_START+22}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2697) We should "version" the apichecker.pl script
[
https://issues.apache.org/jira/browse/TS-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2697:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> We should "version" the apichecker.pl script
>
>
> Key: TS-2697
> URL: https://issues.apache.org/jira/browse/TS-2697
> Project: Traffic Server
> Issue Type: Improvement
> Components: Tools, TS API
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.3.0
>
>
> We should have two data sets:
> {code}
> v2tov3
> v4tov5
> {code}
> and the default is to use the last one, with an option to use another (or
> both). The way the script works, it's not useful for most people to see the
> old v2tov3 API changes.
> As part of this, we should also assure that all API changes that have already
> gone into v5.0.0 has appropriate configuration in the v4tov5 data set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2703) Add a text log feature for the escalate plugin
[ https://issues.apache.org/jira/browse/TS-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2703: -- Fix Version/s: (was: 6.0.0) 5.3.0 > Add a text log feature for the escalate plugin > -- > > Key: TS-2703 > URL: https://issues.apache.org/jira/browse/TS-2703 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2721) atscppapi: add support for CACHE_LOOKUP_COMPLETE hook
[ https://issues.apache.org/jira/browse/TS-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2721: --- Fix Version/s: (was: sometime) 5.3.0 > atscppapi: add support for CACHE_LOOKUP_COMPLETE hook > - > > Key: TS-2721 > URL: https://issues.apache.org/jira/browse/TS-2721 > Project: Traffic Server > Issue Type: Wish > Components: TS API >Reporter: Kit Chan >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > I would like to see support for CACHE_LOOKUP_COMPLETE hook getting added to > atscppapi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2721) atscppapi: add support for CACHE_LOOKUP_COMPLETE hook
[ https://issues.apache.org/jira/browse/TS-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2721: --- Assignee: Alan M. Carroll (was: Susan Hinrichs) > atscppapi: add support for CACHE_LOOKUP_COMPLETE hook > - > > Key: TS-2721 > URL: https://issues.apache.org/jira/browse/TS-2721 > Project: Traffic Server > Issue Type: Wish > Components: TS API >Reporter: Kit Chan >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > I would like to see support for CACHE_LOOKUP_COMPLETE hook getting added to > atscppapi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2721) atscppapi: add support for CACHE_LOOKUP_COMPLETE hook
[ https://issues.apache.org/jira/browse/TS-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2721: -- Assignee: Susan Hinrichs > atscppapi: add support for CACHE_LOOKUP_COMPLETE hook > - > > Key: TS-2721 > URL: https://issues.apache.org/jira/browse/TS-2721 > Project: Traffic Server > Issue Type: Wish > Components: TS API >Reporter: Kit Chan >Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > I would like to see support for CACHE_LOOKUP_COMPLETE hook getting added to > atscppapi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2724) purge waste memory
[
https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2724:
---
Fix Version/s: (was: sometime)
6.0.0
> purge waste memory
> --
>
> Key: TS-2724
> URL: https://issues.apache.org/jira/browse/TS-2724
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: bettydramit
> Fix For: 6.0.0
>
>
> I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
> records.config
> {code}
> proxy.config.cache.target_fragment_size INT 1048576
> {code}
> I use curl to get them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null
> http://www.test.com/testdir/$i.mp4; done
> {code}
> every file just get once, i can see ats memory usage is 138M
> After use curl to purge them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
> http://www.test.com/testdir/$i.mp4; done
> {code}
> I can see ats memory usage is 246M
> every file removed from ats, why the memory usage enlarge about 100M
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2730) proxy.config.cache.enable_read_while_writer
[ https://issues.apache.org/jira/browse/TS-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2730. -- Resolution: Fixed Fix Version/s: (was: sometime) 5.0.0 > proxy.config.cache.enable_read_while_writer > > > Key: TS-2730 > URL: https://issues.apache.org/jira/browse/TS-2730 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Configuration >Reporter: Faysal Banna > Fix For: 5.0.0 > > > Hi Guys > ATS version 4.2.0 > I have enabled proxy.config.cache.enable_read_while_writer and made sure the > background fill threshold and timeout set to proper values and did some tests > that will show u here below : > two terminals opened: > On terminal 1 : > wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' > --2014-04-18 15:41:47-- http://www.golang-book.com/assets/pdf/gobook.pdf > Connecting to 212.98.152.163:8080... connected. > Proxy request sent, awaiting response... > HTTP/1.1 200 OK > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > Content-Type: application/pdf > Accept-Ranges: bytes > Date: Fri, 18 Apr 2014 12:37:46 GMT > Server: ATS/4.2.0 > Alternate-Protocol: 80:quic,80:quic > Content-Length: 2893557 > Age: 28758 > Proxy-Connection: keep-alive > Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Length: 2893557 (2.8M) [application/pdf] > Saving to: ‘gobook.pdf’ > 20% [=> > ] 602,463 18.7KB/s > eta 2m 5s > after waiting couple of seconds i opened terminal 2 and issued : > wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' > --2014-04-18 15:41:59-- http://www.golang-book.com/assets/pdf/gobook.pdf > Connecting to 212.98.152.163:8080... connected. > Proxy request sent, awaiting response... > HTTP/1.1 200 OK > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > Content-Type: application/pdf > Accept-Ranges: bytes > Date: Fri, 18 Apr 2014 12:37:46 GMT > Server: ATS/4.2.0 > Alternate-Protocol: 80:quic,80:quic > Content-Length: 2893557 > Age: 28772 > Proxy-Connection: keep-alive > Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScMsSf pSeN:t > cCMi p sS]) > Length: 2893557 (2.8M) [application/pdf] > Saving to: ‘gobook.pdf’ > 11% [=> > ] 325,864 18.5KB/s > eta 2m 53s > and thus as it shows the read_while_writer is not working as it is supposed > the least i should get the first already downloaded chunks in network speed > and that didn't happen. > second thing is that and i confirm that after aborting both terminals before > any of them would even complete and waited couple of moments i issued on a > new terminal the same request > wget -S -c --delete-after 'http://www.golang-book.com/assets/pdf/gobook.pdf' > --2014-04-18 15:52:08-- http://www.golang-book.com/assets/pdf/gobook.pdf > Connecting to 212.98.152.163:8080... connected. > Proxy request sent, awaiting response... > HTTP/1.1 206 Partial Content > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > Content-Type: application/pdf > Accept-Ranges: bytes > Date: Fri, 18 Apr 2014 12:37:46 GMT > Server: ATS/4.2.0 > Alternate-Protocol: 80:quic,80:quic > Content-Length: 2566130 > Age: 29379 > Content-Range: bytes 327427-2893556/2893557 > Proxy-Connection: keep-alive > Via: http/1.1 UB1-UTU3-170413 (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) > Length: 2893557 (2.8M), 2566130 (2.4M) remaining [application/pdf] > Saving to: ‘gobook.pdf’ > 100%[++>] > 2,893,557 2.03MB/s in 1.2s > 2014-04-18 15:52:09 (2.03 MB/s) - ‘gobook.pdf’ saved [2893557/2893557] > which means that the background fill works as intended but read while_writer > does not at all. > much regards > i am going to install 4.2.1 and see if the same behavior happens again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2731) Range request crash
[
https://issues.apache.org/jira/browse/TS-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-2731.
--
Resolution: Duplicate
Fix Version/s: (was: sometime)
> Range request crash
> ---
>
> Key: TS-2731
> URL: https://issues.apache.org/jira/browse/TS-2731
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Chaokovsky Lee
>Priority: Critical
> Labels: crash
>
> I have updated trafficserver from 4.1.2 to 4.2.0, but the range request crash
> bug even appear.
> I use "read while writer" feature in my configuration, Maybe the feature
> cause crash ?
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> {code}
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3a8300f4a0]
> /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*,
> HTTPHdr*)+0x255)[0x533295]
> /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*)+0x2c8)[0x533638]
> /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x460)[0x533b40]
> /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x7d)[0x53a2dd]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x28)[0x50b268]
> /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
> void*)+0xed)[0x514b4d]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x70)[0x51feb0]
> /usr/bin/traffic_server(TransformTerminus::handle_event(int,
> void*)+0x1d6)[0x4df8d6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x66d37f]
> /usr/bin/traffic_server(EThread::execute()+0x61b)[0x66deab]
> /usr/bin/traffic_server[0x66c89a]
> /lib64/libpthread.so.0[0x3a830077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3a82ce570d]
> {code}
> Thank for your excellent work, the trafficserver is so great!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2734) The development process docs is not up to date
[ https://issues.apache.org/jira/browse/TS-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2734: -- Assignee: Phil Sorber (was: Leif Hedstrom) > The development process docs is not up to date > -- > > Key: TS-2734 > URL: https://issues.apache.org/jira/browse/TS-2734 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Phil Sorber > Fix For: Docs > > > https://cwiki.apache.org/confluence/display/TS/Development+Process > The back port section is definitely out of date, and maybe other areas too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2748) session hooks don't work with SPDY
[
https://issues.apache.org/jira/browse/TS-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-2748.
--
Resolution: Won't Fix
HTTP2 will soon replace SPDY. Not worth the effort at this point.
> session hooks don't work with SPDY
> --
>
> Key: TS-2748
> URL: https://issues.apache.org/jira/browse/TS-2748
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: James Peach
> Fix For: sometime
>
>
> SPDY does not support the session hooks, {{TS_HTTP_SSN_START_HOOK}} and
> {{TS_HTTP_SSN_CLOSE_HOOK}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2749) rfc5861 errors
[ https://issues.apache.org/jira/browse/TS-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2749. -- Resolution: Duplicate Fix Version/s: (was: sometime) > rfc5861 errors > > > Key: TS-2749 > URL: https://issues.apache.org/jira/browse/TS-2749 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Plugins >Reporter: Faysal Banna >Assignee: Phil Sorber > > Good Day. > I been playing around with Plugins and found this one to cause some errors > which illustrated below. > FATAL: InkAPI.cc:2669: failed assert `sdk_sanity_check_mbuffer(bufp) == > TS_SUCCESS` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.4(+0x1ecf7)[0x2aafcbbddcf7] > /usr/local/lib/libtsutil.so.4(+0x1dc3f)[0x2aafcbbdcc3f] > /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ae1bf] > /usr/local/libexec/trafficserver/rfc5861.so(+0x301a)[0x2aafd6c8001a] > /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x6adda0] > > /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6f3)[0x6ae833] > /usr/local/bin/traffic_server[0x6ad6da] > /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2aafccff6f6e] > /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2aafcdd289cd] > [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local' > which after disabling rfc5861 plugin these errors didn't occur anymore > CoreDumps and stack traces are available for debugging if needed > much regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2761) Weird behavior of read-while-write
[ https://issues.apache.org/jira/browse/TS-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2761: -- Assignee: Susan Hinrichs > Weird behavior of read-while-write > --- > > Key: TS-2761 > URL: https://issues.apache.org/jira/browse/TS-2761 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Performance, Quality >Reporter: Faysal Banna >Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > Hello. > There is an issue with read-while-write stuff in ATS that is explained as > follows : > If a client starts a file download lets say 10MB file, and after couple of > seconds another client coincidentally requests this same file. > When client1 terminates the file download for any reason, supposedly client2 > should take over and continue the download till it gets saved, yet > whats happening here is that client2 gets connection interrupted after > whatever is configured in proxy.config.http.background_fill_active_timeout. > And then re-initiates another request in a Range header and thus the file is > never saved. > isn't this unpleasant to deal with read_while_revalidate and cache saving > process ? > Imagine a 200MB windows update file, defenetly we need that saved in the > cache. > look at the situation where You have 10 clients watching a movie that am > happy that my server is caching it .. suddenly first client who initially > requested the movie aborts all the remaining 9 clients would get interrupted > and each one requests a new file with range header > and thus now i shall be getting 9 different requests for the same movie with > range header which is never cached and thus instead of saving bandwidth you > shall be consuming bandwidth for the same file(object) 9 times. > In my opinion background fill should take over only if no one is consuming > the connection(request) anymore, and thus it may timeout with whatever > timeout it holds in config. > Much Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2759) SPDY: replace TS API with internal API
[ https://issues.apache.org/jira/browse/TS-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2759. -- Resolution: Fixed Fix Version/s: (was: sometime) Judging by the commits, we assume this has been fixed. > SPDY: replace TS API with internal API > -- > > Key: TS-2759 > URL: https://issues.apache.org/jira/browse/TS-2759 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Yunkai Zhang > > SPDY in core was migrated from Taobao SPDY plugin, so it use many TS API that > should be replaced with internal API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2761) Weird behavior of read-while-write
[ https://issues.apache.org/jira/browse/TS-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2761: --- Fix Version/s: (was: sometime) 5.3.0 > Weird behavior of read-while-write > --- > > Key: TS-2761 > URL: https://issues.apache.org/jira/browse/TS-2761 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Performance, Quality >Reporter: Faysal Banna > Fix For: 5.3.0 > > > Hello. > There is an issue with read-while-write stuff in ATS that is explained as > follows : > If a client starts a file download lets say 10MB file, and after couple of > seconds another client coincidentally requests this same file. > When client1 terminates the file download for any reason, supposedly client2 > should take over and continue the download till it gets saved, yet > whats happening here is that client2 gets connection interrupted after > whatever is configured in proxy.config.http.background_fill_active_timeout. > And then re-initiates another request in a Range header and thus the file is > never saved. > isn't this unpleasant to deal with read_while_revalidate and cache saving > process ? > Imagine a 200MB windows update file, defenetly we need that saved in the > cache. > look at the situation where You have 10 clients watching a movie that am > happy that my server is caching it .. suddenly first client who initially > requested the movie aborts all the remaining 9 clients would get interrupted > and each one requests a new file with range header > and thus now i shall be getting 9 different requests for the same movie with > range header which is never cached and thus instead of saving bandwidth you > shall be consuming bandwidth for the same file(object) 9 times. > In my opinion background fill should take over only if no one is consuming > the connection(request) anymore, and thus it may timeout with whatever > timeout it holds in config. > Much Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2761) Weird behavior of read-while-write
[ https://issues.apache.org/jira/browse/TS-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2761: --- Assignee: Alan M. Carroll (was: Susan Hinrichs) > Weird behavior of read-while-write > --- > > Key: TS-2761 > URL: https://issues.apache.org/jira/browse/TS-2761 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Performance, Quality >Reporter: Faysal Banna >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > Hello. > There is an issue with read-while-write stuff in ATS that is explained as > follows : > If a client starts a file download lets say 10MB file, and after couple of > seconds another client coincidentally requests this same file. > When client1 terminates the file download for any reason, supposedly client2 > should take over and continue the download till it gets saved, yet > whats happening here is that client2 gets connection interrupted after > whatever is configured in proxy.config.http.background_fill_active_timeout. > And then re-initiates another request in a Range header and thus the file is > never saved. > isn't this unpleasant to deal with read_while_revalidate and cache saving > process ? > Imagine a 200MB windows update file, defenetly we need that saved in the > cache. > look at the situation where You have 10 clients watching a movie that am > happy that my server is caching it .. suddenly first client who initially > requested the movie aborts all the remaining 9 clients would get interrupted > and each one requests a new file with range header > and thus now i shall be getting 9 different requests for the same movie with > range header which is never cached and thus instead of saving bandwidth you > shall be consuming bandwidth for the same file(object) 9 times. > In my opinion background fill should take over only if no one is consuming > the connection(request) anymore, and thus it may timeout with whatever > timeout it holds in config. > Much Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2768) Eliminate STL from SPDY in the core / critical path
[ https://issues.apache.org/jira/browse/TS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2768. -- Resolution: Won't Fix Fix Version/s: (was: sometime) SDPY soon to be replaced by HTTP2. Not reasonable to do enhancements at this point in time. > Eliminate STL from SPDY in the core / critical path > --- > > Key: TS-2768 > URL: https://issues.apache.org/jira/browse/TS-2768 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Leif Hedstrom > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2773) rewrite SSL certificate configuration
[
https://issues.apache.org/jira/browse/TS-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2773:
---
Fix Version/s: (was: sometime)
6.0.0
> rewrite SSL certificate configuration
> -
>
> Key: TS-2773
> URL: https://issues.apache.org/jira/browse/TS-2773
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, SSL
>Reporter: James Peach
> Fix For: 6.0.0
>
>
> Currently, SSL certificate configuration is split across {{records.config}}
> and {{ssl-multicert.config}}. This leads to awkward situations where you
> can't enable client certificate validation for a particular server
> certificate, and you can't add a SSL key passphrase dialog globally.
> I'd like to unify the SSL configuration by pushing all the configuration
> parameters down to {{records.config}} and allowing {{ssl-multicert.config}}
> to override those settings. This would be logically similar to how
> overridable configurations work for the TS API.
> I plan to retain backwards compatibility with 4.x {{ssl-multicert.config}}
> syntax. You would still need {{ssl-multicert.config}} to be able to configure
> multiple SSL certificates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2773) rewrite SSL certificate configuration
[
https://issues.apache.org/jira/browse/TS-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-2773:
--
Assignee: Susan Hinrichs
> rewrite SSL certificate configuration
> -
>
> Key: TS-2773
> URL: https://issues.apache.org/jira/browse/TS-2773
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
> Currently, SSL certificate configuration is split across {{records.config}}
> and {{ssl-multicert.config}}. This leads to awkward situations where you
> can't enable client certificate validation for a particular server
> certificate, and you can't add a SSL key passphrase dialog globally.
> I'd like to unify the SSL configuration by pushing all the configuration
> parameters down to {{records.config}} and allowing {{ssl-multicert.config}}
> to override those settings. This would be logically similar to how
> overridable configurations work for the TS API.
> I plan to retain backwards compatibility with 4.x {{ssl-multicert.config}}
> syntax. You would still need {{ssl-multicert.config}} to be able to configure
> multiple SSL certificates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2790) remove deprecated VConnection::do_io
[
https://issues.apache.org/jira/browse/TS-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2790:
--
Assignee: Phil Sorber
> remove deprecated VConnection::do_io
>
>
> Key: TS-2790
> URL: https://issues.apache.org/jira/browse/TS-2790
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: Phil Sorber
> Labels: compatibility
> Fix For: 6.0.0
>
>
> {{VConnection::do_io}} is marked as deprecated and has probably been
> deprecated forever. We should remove this code and fix all the callers to use
> the more specific API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2790) remove deprecated VConnection::do_io
[
https://issues.apache.org/jira/browse/TS-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2790:
--
Labels: compatibility (was: )
> remove deprecated VConnection::do_io
>
>
> Key: TS-2790
> URL: https://issues.apache.org/jira/browse/TS-2790
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
> Labels: compatibility
> Fix For: 6.0.0
>
>
> {{VConnection::do_io}} is marked as deprecated and has probably been
> deprecated forever. We should remove this code and fix all the callers to use
> the more specific API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2790) remove deprecated VConnection::do_io
[
https://issues.apache.org/jira/browse/TS-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2790:
--
Fix Version/s: (was: 5.2.0)
6.0.0
> remove deprecated VConnection::do_io
>
>
> Key: TS-2790
> URL: https://issues.apache.org/jira/browse/TS-2790
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
> Labels: compatibility
> Fix For: 6.0.0
>
>
> {{VConnection::do_io}} is marked as deprecated and has probably been
> deprecated forever. We should remove this code and fix all the callers to use
> the more specific API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2781) orphan log Unreasonable when first logserver down at runtime
[ https://issues.apache.org/jira/browse/TS-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2781. -- Resolution: Duplicate Fix Version/s: (was: sometime) > orphan log Unreasonable when first logserver down at runtime > - > > Key: TS-2781 > URL: https://issues.apache.org/jira/browse/TS-2781 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.2.0 >Reporter: bettydramit > > my logs_xml.config > > 172.16.2.53 is down > 172.16.10.53 is alive > When start ats, 172.16.2.53 orphan log write to local disk. > The diags.log shown > 172.16.10.53 log up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2798) SSL client configuration is not really reloadable
[ https://issues.apache.org/jira/browse/TS-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2798: -- Assignee: Susan Hinrichs > SSL client configuration is not really reloadable > - > > Key: TS-2798 > URL: https://issues.apache.org/jira/browse/TS-2798 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, SSL >Reporter: Greg Henry >Assignee: Susan Hinrichs > Fix For: sometime > > > Cannot reload SSL client config. It appears to but does not work. > Made changes to reflect a Cert file. It would not work without a complete > restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2796) Leaking CacheVConnections
[ https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2796: --- Fix Version/s: (was: 5.2.0) 5.3.0 > Leaking CacheVConnections > - > > Key: TS-2796 > URL: https://issues.apache.org/jira/browse/TS-2796 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 4.2.1, 5.0.0 >Reporter: Brian Geffon >Assignee: Brian Geffon > Labels: yahoo > Fix For: 5.3.0 > > > It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking > CacheVConnections resulting in IOBufAllocator leaking also, here is an > example: > allocated |in-use | type size | free list name >67108864 | 0 |2097152 | > memory/ioBufAllocator[14] >67108864 | 19922944 |1048576 | > memory/ioBufAllocator[13] > 4798283776 | 14155776 | 524288 | > memory/ioBufAllocator[12] > 7281311744 | 98304000 | 262144 | > memory/ioBufAllocator[11] > 1115684864 | 148242432 | 131072 | > memory/ioBufAllocator[10] > 497544 | 379977728 | 65536 | > memory/ioBufAllocator[9] > 9902751744 | 5223546880 | 32768 | > memory/ioBufAllocator[8] > 14762901504 |14762311680 | 16384 | > memory/ioBufAllocator[7] > 6558056448 | 6557859840 | 8192 | > memory/ioBufAllocator[6] >41418752 | 30502912 | 4096 | > memory/ioBufAllocator[5] > 524288 | 0 | 2048 | > memory/ioBufAllocator[4] > 0 | 0 | 1024 | > memory/ioBufAllocator[3] > 0 | 0 |512 | > memory/ioBufAllocator[2] > 32768 | 0 |256 | > memory/ioBufAllocator[1] > 0 | 0 |128 | > memory/ioBufAllocator[0] > 2138112 |2124192 |928 | > memory/cacheVConnection > [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x. > The code path in CacheVC that is allocating the IoBuffers is > memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom > the real issue here is the leaking CacheVC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2798) SSL client configuration is not really reloadable
[ https://issues.apache.org/jira/browse/TS-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2798: --- Fix Version/s: (was: sometime) 6.0.0 > SSL client configuration is not really reloadable > - > > Key: TS-2798 > URL: https://issues.apache.org/jira/browse/TS-2798 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, SSL >Reporter: Greg Henry >Assignee: Susan Hinrichs > Fix For: 6.0.0 > > > Cannot reload SSL client config. It appears to but does not work. > Made changes to reflect a Cert file. It would not work without a complete > restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2806) map tunnel:// does not seem to work
[
https://issues.apache.org/jira/browse/TS-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2806:
---
Assignee: Leif Hedstrom
> map tunnel:// does not seem to work
>
>
> Key: TS-2806
> URL: https://issues.apache.org/jira/browse/TS-2806
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: sometime
>
>
> When trying to setup a remap rule with e.g.
> {code}
> map tunnel://example.com ...
> {code}
> it always fails inserting this into the remap rules, and hence, aborts. It
> *looks* like it's trying to insert the entries twice, but I'm not quite sure
> yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2809) Make various header sizes configurable (instead of fixed)
[
https://issues.apache.org/jira/browse/TS-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2809:
---
Fix Version/s: (was: sometime)
6.0.0
> Make various header sizes configurable (instead of fixed)
> -
>
> Key: TS-2809
> URL: https://issues.apache.org/jira/browse/TS-2809
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core, HTTP
>Reporter: Leif Hedstrom
> Fix For: 6.0.0
>
>
> It'd be swell if [~amc] could make some of the currently static buffer sizes
> runtime configurable. Ideally even overridable. For example
> {code}
> proxy/hdrs/HdrHeap.h:#define HDR_HEAP_DEFAULT_SIZE 2048
> proxy/hdrs/HdrHeap.h:#define HDR_STR_HEAP_DEFAULT_SIZE 2048
> proxy/http/HttpSM.h:#define HTTP_HEADER_BUFFER_SIZE 2048
> {code}
> There might be several others :). I imagine a site using ATS could have some
> reasonable knowledge of their typical header sizes, and size these
> accordingly for optimal performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2809) Make various header sizes configurable (instead of fixed)
[
https://issues.apache.org/jira/browse/TS-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2809:
---
Assignee: Alan M. Carroll
> Make various header sizes configurable (instead of fixed)
> -
>
> Key: TS-2809
> URL: https://issues.apache.org/jira/browse/TS-2809
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 6.0.0
>
>
> It'd be swell if [~amc] could make some of the currently static buffer sizes
> runtime configurable. Ideally even overridable. For example
> {code}
> proxy/hdrs/HdrHeap.h:#define HDR_HEAP_DEFAULT_SIZE 2048
> proxy/hdrs/HdrHeap.h:#define HDR_STR_HEAP_DEFAULT_SIZE 2048
> proxy/http/HttpSM.h:#define HTTP_HEADER_BUFFER_SIZE 2048
> {code}
> There might be several others :). I imagine a site using ATS could have some
> reasonable knowledge of their typical header sizes, and size these
> accordingly for optimal performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2794) Build failure related to header requirements of atscppapi
[
https://issues.apache.org/jira/browse/TS-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2794:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> Build failure related to header requirements of atscppapi
> -
>
> Key: TS-2794
> URL: https://issues.apache.org/jira/browse/TS-2794
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Reporter: Ryo Okubo
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: extend-tsxs.diff, shared_ptr_h_in.patch
>
>
> When I built my plugin outside of trafficserver source tree, I found build
> failure related to header requirements of atscppapi as below logs.
> {noformat}
> # I set /usr/local/trafficserver/ as prefix.
> In file included from
> /usr/local/trafficserver/include/atscppapi/Transaction.h:30:
> /usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
> 'ink_autoconf.h' file not found
> #include "ink_autoconf.h"
> ^
> 1 error generated.
> {noformat}
> The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
> exist in destination directory. so I've already posted Pull-Request on GitHub
> to fix it. please review, and show me better solution if you have.
> https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2819) Add configuration and APIs to disable loop detection
[ https://issues.apache.org/jira/browse/TS-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2819: --- Assignee: Bryan Call > Add configuration and APIs to disable loop detection > > > Key: TS-2819 > URL: https://issues.apache.org/jira/browse/TS-2819 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: sometime > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-2843:
--
Assignee: Susan Hinrichs
> Buffer overflow in SSL error messages
> -
>
> Key: TS-2843
> URL: https://issues.apache.org/jira/browse/TS-2843
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: sometime
>
>
> With a bad TLS config, I was getting the following errors, which looks like
> it's reading buffers beyond "EOL".
> {code}
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:06065064:digital envelope
> routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
> decrypt:pem_lib.c:483���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2836) TS attempt to connect to dead server at least once
[ https://issues.apache.org/jira/browse/TS-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2836: --- Fix Version/s: (was: 5.2.0) sometime > TS attempt to connect to dead server at least once > -- > > Key: TS-2836 > URL: https://issues.apache.org/jira/browse/TS-2836 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.2, 5.0.0 >Reporter: Masakazu Kitajo > Fix For: sometime > > > Even if I set proxy.config.http.connect_attempts_max_retries_dead_server to > 0, Traffic Server attempt to connect to dead server. > || The configuration value || Number of times TS attempt to connect || > | 0 | 1 | > | 1 | 1 | > | 2 | 2 | > | 3 | 3 | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2843:
---
Fix Version/s: (was: sometime)
6.0.0
> Buffer overflow in SSL error messages
> -
>
> Key: TS-2843
> URL: https://issues.apache.org/jira/browse/TS-2843
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: newbie
> Fix For: 6.0.0
>
>
> With a bad TLS config, I was getting the following errors, which looks like
> it's reading buffers beyond "EOL".
> {code}
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:06065064:digital envelope
> routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
> decrypt:pem_lib.c:483���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2843:
---
Assignee: (was: Susan Hinrichs)
> Buffer overflow in SSL error messages
> -
>
> Key: TS-2843
> URL: https://issues.apache.org/jira/browse/TS-2843
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 6.0.0
>
>
> With a bad TLS config, I was getting the following errors, which looks like
> it's reading buffers beyond "EOL".
> {code}
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:06065064:digital envelope
> routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
> decrypt:pem_lib.c:483���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2843:
---
Labels: newbie (was: )
> Buffer overflow in SSL error messages
> -
>
> Key: TS-2843
> URL: https://issues.apache.org/jira/browse/TS-2843
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Labels: newbie
> Fix For: 6.0.0
>
>
> With a bad TLS config, I was getting the following errors, which looks like
> it's reading buffers beyond "EOL".
> {code}
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:06065064:digital envelope
> routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
> decrypt:pem_lib.c:483���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2848) ATS crash in HttpSM::release_server_session
[
https://issues.apache.org/jira/browse/TS-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2848:
---
Assignee: Alan M. Carroll (was: Susan Hinrichs)
> ATS crash in HttpSM::release_server_session
> ---
>
> Key: TS-2848
> URL: https://issues.apache.org/jira/browse/TS-2848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Feifei Cai
>Assignee: Alan M. Carroll
> Labels: crash, yahoo
> Fix For: sometime
>
> Attachments: TS-2848.diff
>
>
> We deploy ATS on production hosts, and noticed crashes with the following
> stack trace. This happens not very frequently, about 1 week or even longer.
> It crashes repeatedly in the last 2 months, however, the root cause is not
> found and we can not reproduce the crash as wish, only wait for it happens.
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x321e60f500)[0x2b69adf8f500]
> /home/y/bin/traffic_server(_ZN6HttpSM22release_server_sessionEb+0x35)[0x529eb5]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x2db)[0x5362bb]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x282)[0x51e422]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xbad)[0x536b8d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x52ff8e]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1b2)[0x50bef2]
> /home/y/bin/traffic_server(_ZN7CacheVC8callcontEi+0x53)[0x5f0a93]
> /home/y/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7cf)[0x65934f]
> /home/y/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x383)[0x656373]
> /home/y/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x633a6d]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x50b944]
> /home/y/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x51d893]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x722)[0x536702]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x49d)[0x53546d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x85d)[0x53683d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_rewrite.so(+0x1288d)[0x2b69c36d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x398)[0x530828]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server[0x68606b]
> /home/y/bin/traffic_server[0x688a14]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x681582]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a89bf]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a93a3]
> /home/y/bin/traffic_server[0x6a785a]
> /lib64/libpthread.
[jira] [Assigned] (TS-2848) ATS crash in HttpSM::release_server_session
[
https://issues.apache.org/jira/browse/TS-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-2848:
--
Assignee: Susan Hinrichs
> ATS crash in HttpSM::release_server_session
> ---
>
> Key: TS-2848
> URL: https://issues.apache.org/jira/browse/TS-2848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Feifei Cai
>Assignee: Susan Hinrichs
> Labels: crash, yahoo
> Fix For: sometime
>
> Attachments: TS-2848.diff
>
>
> We deploy ATS on production hosts, and noticed crashes with the following
> stack trace. This happens not very frequently, about 1 week or even longer.
> It crashes repeatedly in the last 2 months, however, the root cause is not
> found and we can not reproduce the crash as wish, only wait for it happens.
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x321e60f500)[0x2b69adf8f500]
> /home/y/bin/traffic_server(_ZN6HttpSM22release_server_sessionEb+0x35)[0x529eb5]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x2db)[0x5362bb]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x282)[0x51e422]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xbad)[0x536b8d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x52ff8e]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1b2)[0x50bef2]
> /home/y/bin/traffic_server(_ZN7CacheVC8callcontEi+0x53)[0x5f0a93]
> /home/y/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7cf)[0x65934f]
> /home/y/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x383)[0x656373]
> /home/y/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x633a6d]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x50b944]
> /home/y/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x51d893]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x722)[0x536702]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x49d)[0x53546d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x85d)[0x53683d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_rewrite.so(+0x1288d)[0x2b69c36d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x398)[0x530828]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server[0x68606b]
> /home/y/bin/traffic_server[0x688a14]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x681582]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a89bf]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a93a3]
> /home/y/bin/traffic_server[0x6a785a]
> /lib64/libpthread.so.0(+0x321e607851
[jira] [Closed] (TS-2847) cpu usage like a roller coaster occasionally
[ https://issues.apache.org/jira/browse/TS-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2847. -- Resolution: Incomplete Fix Version/s: (was: sometime) Need some more information to investigate. > cpu usage like a roller coaster occasionally > > > Key: TS-2847 > URL: https://issues.apache.org/jira/browse/TS-2847 > Project: Traffic Server > Issue Type: Test > Components: Network >Reporter: lei.xu > > The data of tsar is shown below: > Time ---cpu-- ---mem-- ---tcp-- -traffic > 27/05/14-08:05 6.7470.56 5.48 1.2M5.4M > 27/05/14-08:10 5.3570.63 5.41 890.9K4.4M > 27/05/14-08:15 4.5770.76 5.88 990.8K4.9M > 27/05/14-08:20 4.5170.88 7.10 833.0K5.2M > 27/05/14-08:25 9.9371.08 6.59 779.6K4.1M > 27/05/14-08:30 6.6071.12 6.02 865.8K4.8M > 27/05/14-08:35 42.0271.5212.89 582.1K1.9M > 27/05/14-08:40 43.4119.3013.48 989.3K1.4M > 27/05/14-08:45 4.6621.08 6.61 1.0M4.9M > 27/05/14-08:50 4.9721.72 6.12 1.0M5.7M > 27/05/14-08:55 4.6722.27 5.58 1.0M5.3M > 27/05/14-09:00 4.7722.90 7.58 938.2K4.9M > 27/05/14-09:05 4.8223.17 7.04 1.0M5.3M > 27/05/14-09:10 4.4323.62 5.84 977.4K4.8M > 27/05/14-09:15 4.2324.10 6.28 948.8K4.8M > 27/05/14-09:20 4.0924.59 5.23 966.8K4.9M > 27/05/14-09:25 3.9625.02 5.98 767.5K4.3M > 27/05/14-09:30 4.0725.44 6.79 768.7K4.8M > 27/05/14-09:35 4.1825.87 6.40 904.9K4.9M > May 27 08:38:00 traffic_cop[28952]: server heartbeat failed [2] > when the cpu usage is increasing suddenly, gdb the process of traffic_server. > 182 pthread_cond_timedwait@@GLIBC_2.3.2 > 27 epoll_wait > 8 nanosleep > 4 accept > 2 pread64 > 1 msync > when the cpu usage is normal, gdb the process of traffic_server. > 91 pthread_cond_timedwait@@GLIBC_2.3.2 > 14 epoll_wait > 4 nanosleep > 2 accept > 1 pread64 > My English is poor, sorry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2848) ATS crash in HttpSM::release_server_session
[
https://issues.apache.org/jira/browse/TS-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2848:
---
Fix Version/s: (was: sometime)
5.3.0
> ATS crash in HttpSM::release_server_session
> ---
>
> Key: TS-2848
> URL: https://issues.apache.org/jira/browse/TS-2848
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Feifei Cai
>Assignee: Alan M. Carroll
> Labels: crash, yahoo
> Fix For: 5.3.0
>
> Attachments: TS-2848.diff
>
>
> We deploy ATS on production hosts, and noticed crashes with the following
> stack trace. This happens not very frequently, about 1 week or even longer.
> It crashes repeatedly in the last 2 months, however, the root cause is not
> found and we can not reproduce the crash as wish, only wait for it happens.
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x321e60f500)[0x2b69adf8f500]
> /home/y/bin/traffic_server(_ZN6HttpSM22release_server_sessionEb+0x35)[0x529eb5]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x2db)[0x5362bb]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x282)[0x51e422]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xbad)[0x536b8d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5361d2]
> /home/y/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x52ff8e]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1b2)[0x50bef2]
> /home/y/bin/traffic_server(_ZN7CacheVC8callcontEi+0x53)[0x5f0a93]
> /home/y/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7cf)[0x65934f]
> /home/y/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x383)[0x656373]
> /home/y/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x633a6d]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x50b944]
> /home/y/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x51d893]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x722)[0x536702]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x49d)[0x53546d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x85d)[0x53683d]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53537a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52dbd0]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_rewrite.so(+0x1288d)[0x2b69c36d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x53328b]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b9b14]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2b69c3471d5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x52da34]
> /home/y/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x398)[0x530828]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x533098]
> /home/y/bin/traffic_server[0x68606b]
> /home/y/bin/traffic_server[0x688a14]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x681582]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a89bf]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a93a3]
> /home/y/bin/traffic_server[0x6a785a]
> /lib64/lib
[jira] [Updated] (TS-2861) traffic_line option to find differences from defaults
[ https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2861: --- Assignee: Leif Hedstrom > traffic_line option to find differences from defaults > - > > Key: TS-2861 > URL: https://issues.apache.org/jira/browse/TS-2861 > Project: Traffic Server > Issue Type: Bug > Components: Tools >Reporter: Miles Libbey >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > Whenever someone has an issue with ATS getting to run as expected, the first > troubleshooting question is, 'what are your configs?' which frequently relies > on the user remembering what has been changed. It would be nice to have an > easy way to print out the configs that are different than the defaults to > begin troubleshooting. > Yesterday, someone came with a performance issue -- turned out that the user > had forgotten that he had turned on diagnostic logging, slowing the > performance. Took a while to figure out that it was turned on -- which could > have been avoided if it were easy to figure out the non-default > configurations being used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2861) traffic_line option to find differences from defaults
[ https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2861: Fix Version/s: (was: sometime) 6.0.0 > traffic_line option to find differences from defaults > - > > Key: TS-2861 > URL: https://issues.apache.org/jira/browse/TS-2861 > Project: Traffic Server > Issue Type: Bug > Components: Tools >Reporter: Miles Libbey >Assignee: Leif Hedstrom > Fix For: 6.0.0 > > > Whenever someone has an issue with ATS getting to run as expected, the first > troubleshooting question is, 'what are your configs?' which frequently relies > on the user remembering what has been changed. It would be nice to have an > easy way to print out the configs that are different than the defaults to > begin troubleshooting. > Yesterday, someone came with a performance issue -- turned out that the user > had forgotten that he had turned on diagnostic logging, slowing the > performance. Took a while to figure out that it was turned on -- which could > have been avoided if it were easy to figure out the non-default > configurations being used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2861) traffic_line option to find differences from defaults
[ https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2861: Component/s: Tools > traffic_line option to find differences from defaults > - > > Key: TS-2861 > URL: https://issues.apache.org/jira/browse/TS-2861 > Project: Traffic Server > Issue Type: Bug > Components: Tools >Reporter: Miles Libbey > Fix For: 6.0.0 > > > Whenever someone has an issue with ATS getting to run as expected, the first > troubleshooting question is, 'what are your configs?' which frequently relies > on the user remembering what has been changed. It would be nice to have an > easy way to print out the configs that are different than the defaults to > begin troubleshooting. > Yesterday, someone came with a performance issue -- turned out that the user > had forgotten that he had turned on diagnostic logging, slowing the > performance. Took a while to figure out that it was turned on -- which could > have been avoided if it were easy to figure out the non-default > configurations being used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2862: -- Labels: api-change compatibility (was: api-change) > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Labels: api-change, compatibility > Fix For: 6.0.0 > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2862: -- Fix Version/s: (was: sometime) 6.0.0 > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Labels: api-change, compatibility > Fix For: 6.0.0 > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2862: - Assignee: Leif Hedstrom > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: api-change, compatibility > Fix For: 6.0.0 > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219748#comment-14219748 ] Susan Hinrichs commented on TS-2871: [~jpe...@apache.org] Did your RPC rework fix this? > traffic_line not accepting certain int values > - > > Key: TS-2871 > URL: https://issues.apache.org/jira/browse/TS-2871 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Bryan Call >Assignee: James Peach > Fix For: 5.3.0 > > > traffic_line has problem with accepting values like -1 and 2147483648 for > configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2871: --- Assignee: James Peach > traffic_line not accepting certain int values > - > > Key: TS-2871 > URL: https://issues.apache.org/jira/browse/TS-2871 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Bryan Call >Assignee: James Peach > Fix For: 5.3.0 > > > traffic_line has problem with accepting values like -1 and 2147483648 for > configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2871: --- Fix Version/s: (was: 5.2.0) 5.3.0 > traffic_line not accepting certain int values > - > > Key: TS-2871 > URL: https://issues.apache.org/jira/browse/TS-2871 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Bryan Call > Fix For: 5.3.0 > > > traffic_line has problem with accepting values like -1 and 2147483648 for > configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2883:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> core dump in TSFetchCreate()
>
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Bryan Call
> Labels: crash, yahoo
> Fix For: 5.3.0
>
> Attachments: TS-2883.diff
>
>
> {code}
> (gdb) bt
> #0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
> #1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
> method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at ../lib/ts/Allocator.h:117
> #2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at InkAPI.cc:7289
> #3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
> method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
> #4 0x005f1faa in spdy_process_syn_stream_frame (session= optimized out>, type=, frame=,
> user_data=0x2b86821e2120)
> at SpdyCallbacks.cc:295
> #5 spdy_on_ctrl_recv_callback (session=, type= optimized out>, frame=, user_data=0x2b86821e2120) at
> SpdyCallbacks.cc:335
> #6 0x00738050 in spdylay_session_on_syn_stream_received
> (session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
> #7 0x00738d57 in spdylay_session_process_ctrl_frame
> (session=0x2b865defce10, in=0x2b858f987a90 "\200\003", inlen= out>) at spdylay_session.c:2246
> #8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
> "\200\003", inlen=) at spdylay_session.c:2805
> #9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
> spdylay_session.c:2828
> #10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
> edata=) at SpdyClientSession.cc:279
> #11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
> event=100, edata=) at SpdyClientSession.cc:236
> #12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:146
> #13 read_signal_and_update (this=0x2b86fc1d2cf0, event=)
> at UnixNetVConnection.cc:138
> #14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
> event=) at UnixNetVConnection.cc:914
> #15 0x006fe66f in SSLNetVConnection::net_read_io
> (this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
> SSLNetVConnection.cc:294
> #16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
> event=, e=) at UnixNet.cc:399
> #17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
> calling_code=5) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
> at UnixEThread.cc:145
> #19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
> UnixEThread.cc:269
> #20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
> #21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
> #22 0x00361a0e894d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2890:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callback = 0x5f1ad0
> void*)>,
> before_ctrl_send_callback = 0x5f1010
> spdylay_frame*, void*)>,
> on_ctrl_send_callback = 0x5f14d0
> spdylay_frame*, void*)>,
> on_ctrl_not_send_callback = 0x5f1020
> spdylay_frame*, int, void*)>,
> on_data_send_callback = 0x5f16a0
>
[jira] [Updated] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2890:
---
Assignee: Sudheer Vinukonda
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callback = 0x5f1ad0
> void*)>,
> before_ctrl_send_callback = 0x5f1010
> spdylay_frame*, void*)>,
> on_ctrl_send_callback = 0x5f14d0
> spdylay_frame*, void*)>,
> on_ctrl_not_send_callback = 0x5f1020
> spdylay_frame*, int, void*)>,
> on_data_send_callback = 0
[jira] [Updated] (TS-2894) Spdy slow start..
[ https://issues.apache.org/jira/browse/TS-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2894: --- Assignee: Sudheer Vinukonda (was: Bryan Call) > Spdy slow start.. > - > > Key: TS-2894 > URL: https://issues.apache.org/jira/browse/TS-2894 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Labels: yahoo > Fix For: 5.3.0 > > Attachments: TS-2894.diff > > > When production testing with spdy/5.0.0, we ran into an issue in some of our > systems, where, the spdy hosts would flap constantly due to the flood of > requests. We further noticed that, where the 4.0.x version or 5.0.0 w/ spdy > turned off, would recover quickly following a restart, spdy enabled hosts > would continue to receive flood of requests and continue to flap. During this > time, traffic server is generally busy reading from the disk and can not > handle too many requests, and is made miserable by spdy's support of multiple > concurrent streams. > To handle such a sudden flood of requests, I'm implementing a simple slow > start mechanism with spdy. The idea is to increase the > max_concurrent_streams_in gradually based on a configured timer, rather than > use the configured value right away. The steps I chose to implement are 1, > 25, 50, 75 and 100% of the configured max_concurrent_streams_in. Note that, > currently, > max_concurrent_streams_in only affects new spdy sessions. Existing sessions > (if any) would continue to use their older values. > Not too sure, if everyone would be interested in this..but, thought of still > uploading my patch, incase, someone is interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2894) Spdy slow start..
[ https://issues.apache.org/jira/browse/TS-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2894: --- Fix Version/s: (was: sometime) 5.3.0 > Spdy slow start.. > - > > Key: TS-2894 > URL: https://issues.apache.org/jira/browse/TS-2894 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: yahoo > Fix For: 5.3.0 > > Attachments: TS-2894.diff > > > When production testing with spdy/5.0.0, we ran into an issue in some of our > systems, where, the spdy hosts would flap constantly due to the flood of > requests. We further noticed that, where the 4.0.x version or 5.0.0 w/ spdy > turned off, would recover quickly following a restart, spdy enabled hosts > would continue to receive flood of requests and continue to flap. During this > time, traffic server is generally busy reading from the disk and can not > handle too many requests, and is made miserable by spdy's support of multiple > concurrent streams. > To handle such a sudden flood of requests, I'm implementing a simple slow > start mechanism with spdy. The idea is to increase the > max_concurrent_streams_in gradually based on a configured timer, rather than > use the configured value right away. The steps I chose to implement are 1, > 25, 50, 75 and 100% of the configured max_concurrent_streams_in. Note that, > currently, > max_concurrent_streams_in only affects new spdy sessions. Existing sessions > (if any) would continue to use their older values. > Not too sure, if everyone would be interested in this..but, thought of still > uploading my patch, incase, someone is interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219757#comment-14219757 ] James Peach commented on TS-2871: - Unlikely. > traffic_line not accepting certain int values > - > > Key: TS-2871 > URL: https://issues.apache.org/jira/browse/TS-2871 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Bryan Call >Assignee: James Peach > Fix For: 5.3.0 > > > traffic_line has problem with accepting values like -1 and 2147483648 for > configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2896) update max_concurrent_streams_in for existing sessions
[ https://issues.apache.org/jira/browse/TS-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219762#comment-14219762 ] Susan Hinrichs commented on TS-2896: [~sudheerv] is this really still an issue for you? > update max_concurrent_streams_in for existing sessions > -- > > Key: TS-2896 > URL: https://issues.apache.org/jira/browse/TS-2896 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Sudheer Vinukonda > Fix For: sometime > > > Currently, when the spdy parameter, max_concurrent_streams_in parameter is > updated, it only affects new spdy sessions. Existing sessions continue to use > old setting. This may be undesirable especially, when there's a need to > control/throttle the spdy reqs (refer jira TS-2894). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219766#comment-14219766
]
James Peach commented on TS-2843:
-
This was probably fixed in 3bb54ea825c9e3a310c760d45b5e2e2b97d36c3b.
> Buffer overflow in SSL error messages
> -
>
> Key: TS-2843
> URL: https://issues.apache.org/jira/browse/TS-2843
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 6.0.0
>
>
> With a bad TLS config, I was getting the following errors, which looks like
> it's reading buffers beyond "EOL".
> {code}
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:06065064:digital envelope
> routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
> decrypt:pem_lib.c:483���
> May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
>
> SSL::47870359922944:error:140B0009:SSL
> routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2900: --- Fix Version/s: (was: 5.2.0) 5.3.0 > TSHttpConnect response includes chunk sizes > --- > > Key: TS-2900 > URL: https://issues.apache.org/jira/browse/TS-2900 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Peter Walsh >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins > that use TSHttpConnect. > When the response body is chunked, the response body being returned to my > plugin includes the chunk sizes in the response string. In ATS 4.x, the > plugins received the response body without the chunked sizes as part of it, > meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2900: --- Assignee: Alan M. Carroll > TSHttpConnect response includes chunk sizes > --- > > Key: TS-2900 > URL: https://issues.apache.org/jira/browse/TS-2900 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Peter Walsh >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins > that use TSHttpConnect. > When the response body is chunked, the response body being returned to my > plugin includes the chunk sizes in the response string. In ATS 4.x, the > plugins received the response body without the chunked sizes as part of it, > meaning ATS handled this under the covers so my plugin didn't have to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2897) enable-linux-native-aio X SSL
[
https://issues.apache.org/jira/browse/TS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-2897.
--
Resolution: Won't Fix
Fix Version/s: (was: 5.2.0)
Getting rid of SSL threads for 6.0.0. That will fix this issue.
> enable-linux-native-aio X SSL
> --
>
> Key: TS-2897
> URL: https://issues.apache.org/jira/browse/TS-2897
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Daniel Picolli Biazus
>Assignee: Brian Geffon
> Labels: crash, review
>
> Hi Guys,
> I could notice that ATS 5.0 is crashing when it is compiled with
> --enable-linux-native-aio option and serving over SSL connections.
> I got the following stack trace:
> [alts] alternate #1 (Q = 1) has these request/response hdrs:
> GET http://127.0.0.1:8080/file.mp4?n=1 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3
> zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Accept: */*
> Host: 127.0.0.1:8080
> Client-ip: xxx.xxx.xxx.xxx
> X-Forwarded-For: xxx.xxx.xxx.xxx
> HTTP/1.1 200 OK
> Server: nginx/1.0.15
> Date: Wed, 25 Jun 2014 18:26:39 GMT
> Content-Type: video/mp4
> Content-Length: 9455997
> Last-Modified: Wed, 25 Jun 2014 18:23:52 GMT
> Connection: keep-alive
> Expires: Wed, 25 Jun 2014 18:31:39 GMT
> Cache-Control: max-age=300
> Accept-Ranges: bytes
> [Jun 25 18:26:41.975] Server {0x7f0c05699700} DEBUG: (http_seq)
> [SelectFromAlternates] Chosen alternate # 0
> [alts] and the winner is alternate number 1
> NOTE: Traffic Server received Sig 11: Segmentation fault
> ./bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf710)[0x7f0c0a357710]
> ./bin/traffic_server(_Z12ink_aio_readP11AIOCallbacki+0x26)[0x6f7406]
> ./bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x292)[0x6af1e2]
> ./bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0x336)[0x6d72a6]
> ./bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x91c)[0x6d821c]
> ./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x42c)[0x6b63bc]
> ./bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x363)[0x6db9f3]
> ./bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x6b514d]
> ./bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x581424]
> ./bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x58f543]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x714)[0x5a66c4]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x806)[0x5a67b6]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
> ./bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x225)[0x59f735]
> ./bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5a32b8]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x388)[0x5a83b8]
> ./bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x635)[0x5a4025]
> ./bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x9d)[0x5823ed]
> ./bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionbP9MIOBufferP14IOBufferReader+0x2b7)[0x5846f7]
> ./bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1de)[0x57e7fe]
> ./bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x5be)[0x4e916e]
> ./bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x70b887]
> ./bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xebf)[0x6fc2bf]
> ./bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x703722]
> ./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73012f]
> ./bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x730ad3]
> ./bin/traffic_server[0x72f4da]
> /lib64/libpthread.so.0(+0x79d1)[0x7f0c0a34f9d1]
> /lib64/libc.so.6(clone+0x6d)[0x7f0c096f8b5d]
> Segmentation fault
>
> This behavior is easily reproduced configuring ATS as a reverse proxy with a
> single origin serving over SSL with "--enable-linux-native-aio" enabled.
> Any thoughts ?
> Thanks & Regards,
> Daniel
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2903) Connections are leaked at about 1000 per hour
[ https://issues.apache.org/jira/browse/TS-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2903: -- Assignee: Susan Hinrichs > Connections are leaked at about 1000 per hour > - > > Key: TS-2903 > URL: https://issues.apache.org/jira/browse/TS-2903 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Puneet Dhaliwal >Assignee: Susan Hinrichs > Fix For: sometime > > > For version 3.2.5, with keep alive on for in/out and post out, connections > were leaked at about 1000 per hour. The limit of > proxy.config.net.connections_throttle was reached at 30k and at 60k after > enough time. > CONFIG proxy.config.http.keep_alive_post_out INT 1 > CONFIG proxy.config.http.keep_alive_enabled_in INT 1 > CONFIG proxy.config.http.keep_alive_enabled_out INT 1 > This might also be happening for 4.2.1 and 5.0. > Pls let me know if there is further information required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2903) Connections are leaked at about 1000 per hour
[ https://issues.apache.org/jira/browse/TS-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219779#comment-14219779 ] Susan Hinrichs commented on TS-2903: We've seen similar leaking in 5.x. Need to track down. > Connections are leaked at about 1000 per hour > - > > Key: TS-2903 > URL: https://issues.apache.org/jira/browse/TS-2903 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Puneet Dhaliwal >Assignee: Susan Hinrichs > Fix For: sometime > > > For version 3.2.5, with keep alive on for in/out and post out, connections > were leaked at about 1000 per hour. The limit of > proxy.config.net.connections_throttle was reached at 30k and at 60k after > enough time. > CONFIG proxy.config.http.keep_alive_post_out INT 1 > CONFIG proxy.config.http.keep_alive_enabled_in INT 1 > CONFIG proxy.config.http.keep_alive_enabled_out INT 1 > This might also be happening for 4.2.1 and 5.0. > Pls let me know if there is further information required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2908) Parents with SSL certificate
[ https://issues.apache.org/jira/browse/TS-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2908. -- Resolution: Duplicate Fix Version/s: (was: sometime) Seems that TS-2773 covers the same issue. > Parents with SSL certificate > - > > Key: TS-2908 > URL: https://issues.apache.org/jira/browse/TS-2908 > Project: Traffic Server > Issue Type: New Feature > Components: Core, SSL >Reporter: Luca Rea > > Feature request for support parents that require to use a specific > certificate to authenticate -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-2890.
---
Resolution: Fixed
Don't see this issue any more - Will reopen if it happens again.
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callback = 0x5f1ad0
> void*)>,
> before_ctrl_send_callback = 0x5f1010
> spdylay_frame*, void*)>,
> on_ctrl_send_callback = 0x5f14d0
> spdylay_frame*, void*)>,
> on_ctrl_not_send_callback = 0x5f1020
>
[jira] [Closed] (TS-2911) Custom Thread Pools
[ https://issues.apache.org/jira/browse/TS-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2911. --- Resolution: Won't Fix Fix Version/s: (was: sometime) This really seems like it should be continuation priority scheduling instead of separate thread pools. Separate thread pools is going to conflict with future NUMA work that is planned. > Custom Thread Pools > --- > > Key: TS-2911 > URL: https://issues.apache.org/jira/browse/TS-2911 > Project: Traffic Server > Issue Type: New Feature > Components: Core, Performance >Reporter: Luca Rea > > Request feature to support adding new thread pools and assign them to groups > of inbound listeners and oubound parents or domains -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet
[ https://issues.apache.org/jira/browse/TS-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2914: --- Fix Version/s: (was: 5.2.0) 5.3.0 > LogField cquuh does not work for TSSkipRemappingSet > --- > > Key: TS-2914 > URL: https://issues.apache.org/jira/browse/TS-2914 > Project: Traffic Server > Issue Type: Bug > Components: Logging, TS API >Reporter: xiongzongtao > Fix For: 5.3.0 > > > if cquuh is set in logs_xml.config and TSSkipRemappingSet called in plugin > log entry related to that plugin is not correct and not readable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2918) collapsed_connection Plugin Errors
[ https://issues.apache.org/jira/browse/TS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-2918: -- Assignee: Susan Hinrichs > collapsed_connection Plugin Errors > --- > > Key: TS-2918 > URL: https://issues.apache.org/jira/browse/TS-2918 > Project: Traffic Server > Issue Type: Bug > Components: Performance, Plugins >Reporter: Faysal Banna >Assignee: Susan Hinrichs > Labels: crash > Fix For: sometime > > > Hi Guys. > I been using trafficserver for over a year with all the good stuff it holds > still there are bugs that are yet not fixed > one of the common bug in a plugin experimental called collapsed_connection > and here's the output > FATAL: InkAPI.cc:989: failed assert `!"Plugin tries to use a continuation > which is deleted"` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.5(+0x1e897)[0x2b587580c897] > /usr/local/lib/libtsutil.so.5(+0x1d84f)[0x2b587580b84f] > /usr/local/bin/traffic_server[0x4b73b3] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x102)[0x5ae762] > /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int, > void*)+0x170)[0x5af510] > /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x5b319d] > /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, > void*)+0x156)[0x5910c6] > /usr/local/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, > HTTPHdr*, CacheLookupHttpConfig*, CacheFragType, char*, int)+0x642)[0x6dfd12] > /usr/local/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, > bool, HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x9b)[0x6beecb] > /usr/local/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, > CacheLookupHttpConfig*, long)+0x81)[0x591381] > /usr/local/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x5a163b] > /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x7aa)[0x5b3c2a] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x2c0)[0x5ae920] > /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x82)[0x5b3382] > /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4c9c34] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x2edf)[0x2b587b651edf] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4714)[0x2b587b653714] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4b90)[0x2b587b653b90] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x73e030] > /usr/local/bin/traffic_server(EThread::execute()+0x7e1)[0x73ec51] > /usr/local/bin/traffic_server[0x73d94a] > each time this happens the server is being restarted > much regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2917) luajit ignores --disable-silent-rules
[
https://issues.apache.org/jira/browse/TS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2917:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> luajit ignores --disable-silent-rules
> -
>
> Key: TS-2917
> URL: https://issues.apache.org/jira/browse/TS-2917
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Arno Toell
>Assignee: Arno Toell
>Priority: Minor
> Fix For: 5.3.0
>
>
> When compiling ATS with --disable-silent-rules the luajit tree ignores that
> configure flag. Excerpt:
> {code}
> ./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver
> --libdir=/usr/lib/trafficserver --with-user=root --with-group=root
> --disable-silent-rules --enable-experimental-plugins
> --enable-reclaimable-freelist CFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security" FCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4" FFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" GCJFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" LDFLAGS="-Wl,-z,relro" OBJCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> OBJCXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security" --enable-wccp --enable-linux-native-aio
> ...
> make[3]: Entering directory
> '/home/arno/trafficserver/trafficserver/iocore/eventsystem'
> depbase=`echo EventSystem.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records
> -I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1
> -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.6
> -I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe
> -Wall -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -mcx16 -MT EventSystem.o -MD -MP -MF $depbase.Tpo -c -o
> EventSystem.o EventSystem.cc &&\
> mv -f $depbase.Tpo $depbase.Po
> ...
> make[4]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit'
> Building LuaJIT 2.0.3
> make -C src
> make[5]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit/src'
> HOSTCChost/minilua.o
> HOSTLINK host/minilua
> DYNASMhost/buildvm_arch.h
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2918) collapsed_connection Plugin Errors
[ https://issues.apache.org/jira/browse/TS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2918: --- Fix Version/s: (was: sometime) 5.3.0 > collapsed_connection Plugin Errors > --- > > Key: TS-2918 > URL: https://issues.apache.org/jira/browse/TS-2918 > Project: Traffic Server > Issue Type: Bug > Components: Performance, Plugins >Reporter: Faysal Banna >Assignee: Alan M. Carroll > Labels: crash > Fix For: 5.3.0 > > > Hi Guys. > I been using trafficserver for over a year with all the good stuff it holds > still there are bugs that are yet not fixed > one of the common bug in a plugin experimental called collapsed_connection > and here's the output > FATAL: InkAPI.cc:989: failed assert `!"Plugin tries to use a continuation > which is deleted"` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.5(+0x1e897)[0x2b587580c897] > /usr/local/lib/libtsutil.so.5(+0x1d84f)[0x2b587580b84f] > /usr/local/bin/traffic_server[0x4b73b3] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x102)[0x5ae762] > /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int, > void*)+0x170)[0x5af510] > /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x5b319d] > /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, > void*)+0x156)[0x5910c6] > /usr/local/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, > HTTPHdr*, CacheLookupHttpConfig*, CacheFragType, char*, int)+0x642)[0x6dfd12] > /usr/local/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, > bool, HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x9b)[0x6beecb] > /usr/local/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, > CacheLookupHttpConfig*, long)+0x81)[0x591381] > /usr/local/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x5a163b] > /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x7aa)[0x5b3c2a] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x2c0)[0x5ae920] > /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x82)[0x5b3382] > /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4c9c34] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x2edf)[0x2b587b651edf] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4714)[0x2b587b653714] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4b90)[0x2b587b653b90] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x73e030] > /usr/local/bin/traffic_server(EThread::execute()+0x7e1)[0x73ec51] > /usr/local/bin/traffic_server[0x73d94a] > each time this happens the server is being restarted > much regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2918) collapsed_connection Plugin Errors
[ https://issues.apache.org/jira/browse/TS-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2918: --- Assignee: Alan M. Carroll (was: Susan Hinrichs) > collapsed_connection Plugin Errors > --- > > Key: TS-2918 > URL: https://issues.apache.org/jira/browse/TS-2918 > Project: Traffic Server > Issue Type: Bug > Components: Performance, Plugins >Reporter: Faysal Banna >Assignee: Alan M. Carroll > Labels: crash > Fix For: 5.3.0 > > > Hi Guys. > I been using trafficserver for over a year with all the good stuff it holds > still there are bugs that are yet not fixed > one of the common bug in a plugin experimental called collapsed_connection > and here's the output > FATAL: InkAPI.cc:989: failed assert `!"Plugin tries to use a continuation > which is deleted"` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.5(+0x1e897)[0x2b587580c897] > /usr/local/lib/libtsutil.so.5(+0x1d84f)[0x2b587580b84f] > /usr/local/bin/traffic_server[0x4b73b3] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x102)[0x5ae762] > /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int, > void*)+0x170)[0x5af510] > /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x5b319d] > /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, > void*)+0x156)[0x5910c6] > /usr/local/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, > HTTPHdr*, CacheLookupHttpConfig*, CacheFragType, char*, int)+0x642)[0x6dfd12] > /usr/local/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, > bool, HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x9b)[0x6beecb] > /usr/local/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*, > CacheLookupHttpConfig*, long)+0x81)[0x591381] > /usr/local/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x5a163b] > /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x7aa)[0x5b3c2a] > /usr/local/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x2c0)[0x5ae920] > /usr/local/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x82)[0x5b3382] > /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4c9c34] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x2edf)[0x2b587b651edf] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4714)[0x2b587b653714] > /usr/local/libexec/trafficserver/collapsed_connection.so(+0x4b90)[0x2b587b653b90] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x73e030] > /usr/local/bin/traffic_server(EThread::execute()+0x7e1)[0x73ec51] > /usr/local/bin/traffic_server[0x73d94a] > each time this happens the server is being restarted > much regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2896) update max_concurrent_streams_in for existing sessions
[ https://issues.apache.org/jira/browse/TS-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219789#comment-14219789 ] Sudheer Vinukonda commented on TS-2896: --- [~shinrich] : Yes, it would be nice to be able to apply the max_streams for already active sessions as well, since, applying it only on new connections alone doesn't reduce the volume of the traffic being received. Would it be okay to leave this open for now, I will try to work on this in the coming days? > update max_concurrent_streams_in for existing sessions > -- > > Key: TS-2896 > URL: https://issues.apache.org/jira/browse/TS-2896 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Sudheer Vinukonda > Fix For: sometime > > > Currently, when the spdy parameter, max_concurrent_streams_in parameter is > updated, it only affects new spdy sessions. Existing sessions continue to use > old setting. This may be undesirable especially, when there's a need to > control/throttle the spdy reqs (refer jira TS-2894). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2920) Stale_While_revalidate
[ https://issues.apache.org/jira/browse/TS-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2920: --- Fix Version/s: (was: sometime) 5.3.0 > Stale_While_revalidate > -- > > Key: TS-2920 > URL: https://issues.apache.org/jira/browse/TS-2920 > Project: Traffic Server > Issue Type: Bug > Components: Performance, Plugins >Reporter: Faysal Banna >Assignee: Alan M. Carroll > Labels: crash > Fix For: 5.3.0 > > > trafficserver 5.0.0 release version > FATAL: InkAPI.cc:2670: failed assert `sdk_sanity_check_mbuffer(bufp) == > TS_SUCCESS` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] > /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] > /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] > /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] > /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] > /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x737210] > /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] > /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] > /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] > /usr/local/bin/traffic_server[0x736b5a] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x737210] > /lib64/libpthread.so.0(+0x7f33)[0x2b6db60a2f33] > /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] > /lib64/libc.so.6(clone+0x6d)[0x2b6db713eded] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2920) Stale_While_revalidate
[ https://issues.apache.org/jira/browse/TS-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2920: --- Assignee: Alan M. Carroll > Stale_While_revalidate > -- > > Key: TS-2920 > URL: https://issues.apache.org/jira/browse/TS-2920 > Project: Traffic Server > Issue Type: Bug > Components: Performance, Plugins >Reporter: Faysal Banna >Assignee: Alan M. Carroll > Labels: crash > Fix For: 5.3.0 > > > trafficserver 5.0.0 release version > FATAL: InkAPI.cc:2670: failed assert `sdk_sanity_check_mbuffer(bufp) == > TS_SUCCESS` > /usr/local/bin/traffic_server - STACK TRACE: > /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] > /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] > /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] > /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] > /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] > /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x737210] > /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] > /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] > /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] > /usr/local/bin/traffic_server[0x736b5a] > /usr/local/bin/traffic_server(EThread::process_event(Event*, > int)+0x170)[0x737210] > /lib64/libpthread.so.0(+0x7f33)[0x2b6db60a2f33] > /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] > /lib64/libc.so.6(clone+0x6d)[0x2b6db713eded] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2928) SPDY should use the ATS atomic methods and not gcc atomic builtins directly
[ https://issues.apache.org/jira/browse/TS-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2928. -- Resolution: Won't Fix Fix Version/s: (was: 5.2.0) SPDY is soon to be replaced by HTTP2. Not worth making incremental fixes on SPDY at this point. > SPDY should use the ATS atomic methods and not gcc atomic builtins directly > --- > > Key: TS-2928 > URL: https://issues.apache.org/jira/browse/TS-2928 > Project: Traffic Server > Issue Type: Bug > Components: Core, SPDY >Reporter: Brian Geffon >Assignee: Phil Sorber > > SPDY should use the ATS atomic methods and gcc builtins directly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2937) conf_remap plugin returns an error if the file is empty
[ https://issues.apache.org/jira/browse/TS-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2937: --- Fix Version/s: (was: 5.2.0) 5.3.0 > conf_remap plugin returns an error if the file is empty > --- > > Key: TS-2937 > URL: https://issues.apache.org/jira/browse/TS-2937 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, Plugins >Reporter: Craig Forbes >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > If the conf_remap plugin config file does not have at least one CONFIG line > an error occurs and traffic_server exits with an error. For example if the > config file is empty or has only comments. > Also related, if the file does have at least one CONFIG line all other errors > are reported but ignored and does not trigger an error and exit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2936) Comments and line continuations in remap.config is bad mojo
[
https://issues.apache.org/jira/browse/TS-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2936:
---
Labels: newbie (was: )
> Comments and line continuations in remap.config is bad mojo
> ---
>
> Key: TS-2936
> URL: https://issues.apache.org/jira/browse/TS-2936
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Core
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 5.3.0
>
>
> If you do a line continuation on a commented out line in remap.config, it'll
> still suck up the following line into the comment. This is less than ideal.
> As an example, this does not work
> {code}
> map http://example.com http://real.example.com \
> # @plugin=conf_remap.so @pparam= ... \
> @plugin=header_rewrite.so @pparam= ...
> {code}
> The issue being that the second plugin line gets sucked into the comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2941) ATS not closing TLS connection properly
[
https://issues.apache.org/jira/browse/TS-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-2941:
--
Assignee: Susan Hinrichs
> ATS not closing TLS connection properly
> ---
>
> Key: TS-2941
> URL: https://issues.apache.org/jira/browse/TS-2941
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Alexey Ivanov
>Assignee: Susan Hinrichs
> Fix For: sometime
>
>
> We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
> {code}
> 20:31:42.861752 IP client-ip.56898 > www.linkedin.com.https: Flags [S], seq
> 2989744105, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val
> 1060727394 ecr 0,sackOK,eol], length 0
> 20:31:42.861760 IP www.linkedin.com.https > client-ip.56898: Flags [S.], seq
> 441157858, ack 2989744106, win 14480, options [mss 1460,sackOK,TS val
> 579955489 ecr 1060727394,nop,wscale 7], length 0
> 20:31:43.005735 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1, win 8235, options [nop,nop,TS val 1060727553 ecr 579955489], length 0
> 20:31:43.012094 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 1:216, ack 1, win 8235, options [nop,nop,TS val 1060727555 ecr 579955489],
> length 215
> 20:31:43.012115 IP www.linkedin.com.https > client-ip.56898: Flags [.], ack
> 216, win 122, options [nop,nop,TS val 579955639 ecr 1060727555], length 0
> 20:31:43.012400 IP www.linkedin.com.https > client-ip.56898: Flags [P.], seq
> 1:186, ack 216, win 122, options [nop,nop,TS val 579955640 ecr 1060727555],
> length 185
> 20:31:43.157903 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 186, win 8223, options [nop,nop,TS val 1060727703 ecr 579955640], length 0
> 20:31:43.157919 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 216:222, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
> 579955640], length 6
> 20:31:43.163988 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 222:307, ack 186, win 8223, options [nop,nop,TS val 1060727704 ecr
> 579955640], length 85
> 20:31:43.164096 IP www.linkedin.com.https > client-ip.56898: Flags [.], ack
> 307, win 122, options [nop,nop,TS val 579955791 ecr 1060727704], length 0
> 20:31:43.164650 IP client-ip.56898 > www.linkedin.com.https: Flags [.], seq
> 307:1755, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
> 579955640], length 1448
> 20:31:43.164668 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 1755:2472, ack 186, win 8223, options [nop,nop,TS val 1060727705 ecr
> 579955640], length 717
> 20:31:43.164677 IP www.linkedin.com.https > client-ip.56898: Flags [.], ack
> 2472, win 167, options [nop,nop,TS val 579955792 ecr 1060727705], length 0
> 20:31:43.504019 IP www.linkedin.com.https > client-ip.56898: Flags [P.], seq
> 186:1167, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
> 1060727705], length 981
> 20:31:43.504043 IP www.linkedin.com.https > client-ip.56898: Flags [P.], seq
> 1167:1764, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
> 1060727705], length 597
> 20:31:43.504101 IP www.linkedin.com.https > client-ip.56898: Flags [.], seq
> 1764:3212, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
> 1060727705], length 1448
> 20:31:43.504118 IP www.linkedin.com.https > client-ip.56898: Flags [.], seq
> 3212:4660, ack 2472, win 167, options [nop,nop,TS val 579956131 ecr
> 1060727705], length 1448
> 20:31:43.504150 IP www.linkedin.com.https > client-ip.56898: Flags [.], seq
> 4660:6108, ack 2472, win 167, options [nop,nop,TS val 579956132 ecr
> 1060727705], length 1448
> 20:31:43.743945 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1167, win 8162, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
> 20:31:43.743966 IP www.linkedin.com.https > client-ip.56898: Flags [P.], seq
> 6108:6126, ack 2472, win 167, options [nop,nop,TS val 579956371 ecr
> 1060728286], length 18
> 20:31:43.743987 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 4660, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131], length 0
> 20:31:43.743994 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 6108, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
> 20:31:43.895889 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 6126, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
> 20:31:54.189610 IP www.linkedin.com.https > client-ip.56898: Flags [F.], seq
> 6126, ack 2472, win 167, options [nop,nop,TS val 579966817 ecr 1060728437],
> length 0
> 20:31:54.305500 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 6127, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
> 20:31:54.775695 IP client-ip.56898 > www.linkedin.com.https: Flags [
[jira] [Updated] (TS-2946) Core dump in snprintf
[
https://issues.apache.org/jira/browse/TS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2946:
---
Fix Version/s: (was: 5.2.0)
6.0.0
> Core dump in snprintf
> -
>
> Key: TS-2946
> URL: https://issues.apache.org/jira/browse/TS-2946
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
> Labels: crash
> Fix For: 6.0.0
>
>
> While fixing TS-2938, ran into another core dump with the below stack trace.
> server_request object seems corrupted even in this stack trace, just like
> TS-2938. Investigating further.
> {code}
> (gdb) #0 0x003ca2044283 in vfprintf () from /lib64/libc.so.6
> #1 0x003ca206f9d2 in vsnprintf () from /lib64/libc.so.6
> #2 0x003ca204f4a3 in snprintf () from /lib64/libc.so.6
> #3 0x00648724 in ink_fast_ltoa (heap=0x2b7682cd0010,
> mh=0x2b7682cd00c8, field=0x2b7682cd0298, value=) at
> ../../lib/ts/ink_string.h:449
> #4 mime_format_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
> field=0x2b7682cd0298, value=) at MIME.cc:2810
> #5 mime_field_value_set_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
> field=0x2b7682cd0298, value=) at MIME.cc:2064
> #6 0x005de7f0 in value_set_int64 (request_sent_time=1405317978,
> response_received_time=1405317978, now=1405663927, base= out>, outgoing=0x2b7679272418)
> at ../../proxy/hdrs/MIME.h:817
> #7 value_set_int64 (request_sent_time=1405317978,
> response_received_time=1405317978, now=1405663927, base= out>, outgoing=0x2b7679272418) at ../../proxy/hdrs/MIME.h:1334
> #8 set_age (request_sent_time=1405317978, response_received_time=1405317978,
> now=1405663927, base=, outgoing=0x2b7679272418) at
> ../../proxy/hdrs/MIME.h:1548
> #9 HttpTransactHeaders::insert_time_and_age_headers_in_response
> (request_sent_time=1405317978, response_received_time=1405317978,
> now=1405663927, base=,
> outgoing=0x2b7679272418) at HttpTransactHeaders.cc:754
> #10 0x005c0aca in HttpTransact::build_response (s=0x2b7679271d38,
> base_response=0x2b777d8b90b8, outgoing_response=0x2b7679272418,
> outgoing_version=,
> status_code=HTTP_STATUS_NONE, reason_phrase=0x755b4b "None") at
> HttpTransact.cc:7772
> #11 0x005d4b84 in HttpTransact::build_response_from_cache
> (s=0x2b7679271d38, warning_code=HTTP_WARNING_CODE_NONE) at
> HttpTransact.cc:2869
> #12 0x005d6858 in HttpTransact::HandleCacheOpenReadHit
> (s=0x2b7679271d38) at HttpTransact.cc:2755
> #13 0x005922a6 in HttpSM::call_transact_and_set_next_state
> (this=0x2b7679271cd0, f=) at HttpSM.cc:6788
> #14 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #15 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #16 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
> HttpSM.cc:6830
> #17 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #18 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #19 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
> HttpSM.cc:6830
> #20 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #21 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #22 0x005a7810 in do_api_callout (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:444
> #23 setup_cache_lookup_complete_api (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:2403
> #24 HttpSM::state_cache_open_read (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:2459
> #25 0x005a7518 in HttpSM::main_handler (this=0x2b7679271cd0,
> event=1103, data=0xb050) at HttpSM.cc:2501
> #26 0x00585882 in handleEvent (this=0x2b76792736a0, event=1103,
> data=0xb050) at ../../iocore/eventsystem/I_Continuation.h:146
> #27 HttpCacheSM::state_cache_open_read (this=0x2b76792736a0, event=1103,
> data=0xb050) at HttpCacheSM.cc:137
> #28 0x006dc0ee in Cache::open_read (this=,
> cont=0x2b76792736a0, key=, request=0x2b76792723d8,
> params=0x2b7679271db0,
> type=,
> hostname=0x2b7659b96150
> "ads.unister-gmbh.denewsletter_img/aidude/template/countdown/stdblue/countdown63.gifin-den-urlaub-deals.de%2Ftime_2014-07-09_2014-07-16_H_stdblue.gif&t=1405663926&ttl=4492800&sig=DtpLmS6SPFs7BWU7bvb5IA"...,
> host_len=19) at CacheRead.cc:143
> #29 0x006bcd2d in open_read (this=,
> cont=0x2b76792736a0, url=0x2b76792723f0, cluster_cache_local= out>, request=0x2b76792723d8,
> params=0x2b7679271db0, pin
[jira] [Updated] (TS-2961) Expires: 0 and Expires: past date being temporarily cached
[
https://issues.apache.org/jira/browse/TS-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2961:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> Expires: 0 and Expires: past date being temporarily cached
> --
>
> Key: TS-2961
> URL: https://issues.apache.org/jira/browse/TS-2961
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 5.0.1
>Reporter: Nick Muerdter
>Priority: Minor
> Fix For: 5.3.0
>
>
> While doing some integration testing with TrafficServer, I noticed some
> seemingly odd behavior: If my origin server returns "{{Expires: 0}}" or
> "{{Expires: SOME_PAST_DATE}}" headers, TrafficServer appears to cache these
> responses for about 1 second. This would seem to run counter to the
> [documentation|https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html?highlight=expires#origin-server-directives]:
> {quote}
> By default, Traffic Server does not cache objects with the following response
> headers:
> - Expires: header with value of 0 (zero) or a past date
> {quote}
> I was able to reproduce this with a stock TrafficServer 5.0.1 installation
> pointing at an origin server that returns a random, unique output on each
> call. If the origin server returns a "{{Expires: 0}}" or "{{Expires:
> SOME_PAST_DATE}}" header, then TrafficServer appears to cache the first
> response briefly (around 1 second).
> I do not experience this same temporary cache when testing the other
> scenarios outlined in the documentation of what's not cached (for example,
> when the origin server responds with "{{Cache-Control: no-store}}" or
> "{{Set-Cookie}}").
> This isn't a huge deal for my use case personally, but the behavior I'm
> seeing does seem to run counter to the documentation, so I thought it was a
> bit odd.
> Here's some details demonstrating the cached response when requests are made
> in quick succession:
> {code}
> $ curl -v "http://localhost:8081/cacheable-expires-0/1"; && curl -v
> "http://localhost:8081/cacheable-expires-0/1";
> * About to connect() to localhost port 8081 (#0)
> * Trying ::1... Connection refused
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 8081 (#0)
> > GET /cacheable-expires-0/1 HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost:8081
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < X-Powered-By: Express
> < Expires: 0
> < Date: Mon, 28 Jul 2014 01:49:45 GMT
> < Age: 0
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Server: ATS/5.0.1
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> 36780-926573328-0.49593452527187765
> * About to connect() to localhost port 8081 (#0)
> * Trying ::1... Connection refused
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 8081 (#0)
> > GET /cacheable-expires-0/1 HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost:8081
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < X-Powered-By: Express
> < Expires: 0
> < Date: Mon, 28 Jul 2014 01:49:45 GMT
> < Age: 0
> < Content-Length: 35
> < Connection: keep-alive
> < Server: ATS/5.0.1
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> 36780-926573328-0.49593452527187765
> {code}
> In this case, the origin server only gets called once (note the response
> bodies are identical, which should not be happening since the origin is
> returning a unique response body on each call). If I add in a sleep of around
> 0.8 seconds between calls, then TrafficServer's cached copy appears to go
> away:
> {code}
> $ curl -v "http://localhost:8081/cacheable-expires-0/1"; && sleep 0.8 && curl
> -v "http://localhost:8081/cacheable-expires-0/1";
> * About to connect() to localhost port 8081 (#0)
> * Trying ::1... Connection refused
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 8081 (#0)
> > GET /cacheable-expires-0/1 HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
> > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: localhost:8081
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < X-Powered-By: Express
> < Expires: 0
> < Date: Mon, 28 Jul 2014 01:51:16 GMT
> < Age: 0
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Server: ATS/5.0.1
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> 36871-310090571-0.9994140579365194
> * About to connect() to localhost port 8081 (#0)
> * Trying ::1... Connection refused
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 8081 (#0)
[jira] [Resolved] (TS-2946) Core dump in snprintf
[
https://issues.apache.org/jira/browse/TS-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-2946.
---
Resolution: Fixed
Don't see this core anymore. Marking it Resolved; will reopen if I see it again.
> Core dump in snprintf
> -
>
> Key: TS-2946
> URL: https://issues.apache.org/jira/browse/TS-2946
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
> Labels: crash
> Fix For: 6.0.0
>
>
> While fixing TS-2938, ran into another core dump with the below stack trace.
> server_request object seems corrupted even in this stack trace, just like
> TS-2938. Investigating further.
> {code}
> (gdb) #0 0x003ca2044283 in vfprintf () from /lib64/libc.so.6
> #1 0x003ca206f9d2 in vsnprintf () from /lib64/libc.so.6
> #2 0x003ca204f4a3 in snprintf () from /lib64/libc.so.6
> #3 0x00648724 in ink_fast_ltoa (heap=0x2b7682cd0010,
> mh=0x2b7682cd00c8, field=0x2b7682cd0298, value=) at
> ../../lib/ts/ink_string.h:449
> #4 mime_format_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
> field=0x2b7682cd0298, value=) at MIME.cc:2810
> #5 mime_field_value_set_int64 (heap=0x2b7682cd0010, mh=0x2b7682cd00c8,
> field=0x2b7682cd0298, value=) at MIME.cc:2064
> #6 0x005de7f0 in value_set_int64 (request_sent_time=1405317978,
> response_received_time=1405317978, now=1405663927, base= out>, outgoing=0x2b7679272418)
> at ../../proxy/hdrs/MIME.h:817
> #7 value_set_int64 (request_sent_time=1405317978,
> response_received_time=1405317978, now=1405663927, base= out>, outgoing=0x2b7679272418) at ../../proxy/hdrs/MIME.h:1334
> #8 set_age (request_sent_time=1405317978, response_received_time=1405317978,
> now=1405663927, base=, outgoing=0x2b7679272418) at
> ../../proxy/hdrs/MIME.h:1548
> #9 HttpTransactHeaders::insert_time_and_age_headers_in_response
> (request_sent_time=1405317978, response_received_time=1405317978,
> now=1405663927, base=,
> outgoing=0x2b7679272418) at HttpTransactHeaders.cc:754
> #10 0x005c0aca in HttpTransact::build_response (s=0x2b7679271d38,
> base_response=0x2b777d8b90b8, outgoing_response=0x2b7679272418,
> outgoing_version=,
> status_code=HTTP_STATUS_NONE, reason_phrase=0x755b4b "None") at
> HttpTransact.cc:7772
> #11 0x005d4b84 in HttpTransact::build_response_from_cache
> (s=0x2b7679271d38, warning_code=HTTP_WARNING_CODE_NONE) at
> HttpTransact.cc:2869
> #12 0x005d6858 in HttpTransact::HandleCacheOpenReadHit
> (s=0x2b7679271d38) at HttpTransact.cc:2755
> #13 0x005922a6 in HttpSM::call_transact_and_set_next_state
> (this=0x2b7679271cd0, f=) at HttpSM.cc:6788
> #14 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #15 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #16 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
> HttpSM.cc:6830
> #17 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #18 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #19 0x005aa402 in HttpSM::set_next_state (this=0x2b7679271cd0) at
> HttpSM.cc:6830
> #20 0x005ac562 in HttpSM::handle_api_return (this=0x2b7679271cd0) at
> HttpSM.cc:1505
> #21 0x005a49e0 in HttpSM::state_api_callout (this=0x2b7679271cd0,
> event=0, data=0x0) at HttpSM.cc:1437
> #22 0x005a7810 in do_api_callout (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:444
> #23 setup_cache_lookup_complete_api (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:2403
> #24 HttpSM::state_cache_open_read (this=0x2b7679271cd0, event= optimized out>, data=0xb050) at HttpSM.cc:2459
> #25 0x005a7518 in HttpSM::main_handler (this=0x2b7679271cd0,
> event=1103, data=0xb050) at HttpSM.cc:2501
> #26 0x00585882 in handleEvent (this=0x2b76792736a0, event=1103,
> data=0xb050) at ../../iocore/eventsystem/I_Continuation.h:146
> #27 HttpCacheSM::state_cache_open_read (this=0x2b76792736a0, event=1103,
> data=0xb050) at HttpCacheSM.cc:137
> #28 0x006dc0ee in Cache::open_read (this=,
> cont=0x2b76792736a0, key=, request=0x2b76792723d8,
> params=0x2b7679271db0,
> type=,
> hostname=0x2b7659b96150
> "ads.unister-gmbh.denewsletter_img/aidude/template/countdown/stdblue/countdown63.gifin-den-urlaub-deals.de%2Ftime_2014-07-09_2014-07-16_H_stdblue.gif&t=1405663926&ttl=4492800&sig=DtpLmS6SPFs7BWU7bvb5IA"...,
> host_len=19) at CacheRead.cc:143
> #29 0x006bcd2d in open_read (this=,
> cont=0x2b76792736a0, url=0x2b76792723f0, cluster_cache_local= out>, reques
[jira] [Closed] (TS-2966) Update Feature not working
[ https://issues.apache.org/jira/browse/TS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-2966. -- Resolution: Won't Fix Fix Version/s: (was: sometime) Removing prefetch feature gets rid of this issue. > Update Feature not working > -- > > Key: TS-2966 > URL: https://issues.apache.org/jira/browse/TS-2966 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Core >Reporter: Thomas Stinner >Assignee: Zhao Yongming > Attachments: traffic.out, trafficserver.patch > > > I had a problem using the update feature. I recevied a SegFault in > do_host_db_lookup which was caused by accessing ua_session which was not > initialized (see attached patch). > After fixing that i no longer get an SegFault, but the files that are > retrieved by recursion are not placed into the cache. They are requested in > every schedule. > Only the starting file is placed correctly into the cache. > When retrieving the files with a client, caching works as expected. So i > don't think this is a configuration error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2967:
---
Fix Version/s: (was: 5.2.0)
5.3.0
> failed assert if ssl_multicert.config doesn't exist
> ---
>
> Key: TS-2967
> URL: https://issues.apache.org/jira/browse/TS-2967
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Jack Bates
>Assignee: Jack Bates
> Fix For: 5.3.0
>
>
> If an ssl_multicert.config file doesn't exist then
> SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
> and SSLCertificateConfig::reconfigure() doesn't initialize configid
> (SSLConfig.cc line 333)
> Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
> (SSLUtils.cc line 502)
> it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
> and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
> One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
> SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
> (configid !=0)
> Another way might be if SSLCertificateConfig::reconfigure() initialized
> configid with configProcessor.set(configid, NULL) if
> SSLParseCertificateConfiguration() returns false?
> Or SSLParseCertificateConfiguration() could treat a nonexistent
> ssl_multicert.config the same as it treats a blank file? ({{touch
> ssl_multicert.config}} makes the failed assert go away.)
> Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
