[jira] [Created] (TS-2882) Core dump inside spdylay library
Sudheer Vinukonda created TS-2882:
-
Summary: Core dump inside spdylay library
Key: TS-2882
URL: https://issues.apache.org/jira/browse/TS-2882
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
{code}
(gdb) bt
#0 0x0038818328e5 in raise () from /lib64/libc.so.6
#1 0x0038818340c5 in abort () from /lib64/libc.so.6
#2 0x0038818707f7 in __libc_message () from /lib64/libc.so.6
#3 0x003881876126 in malloc_printerr () from /lib64/libc.so.6
#4 0x00739e19 in spdylay_outbound_item_free (item=0x2b7e2000b510) at
spdylay_outbound_item.c:81
#5 0x00737428 in spdylay_session_send (session=0x2b7ed59ae4f0) at
spdylay_session.c:1538
#6 0x005ef26c in spdy_process_write (this=0x2b7f24597800, event=101,
edata=0x2b7e94194cf0) at SpdyClientSession.cc:291
#7 SpdyClientSession::state_session_readwrite (this=0x2b7f24597800, event=101,
edata=0x2b7e94194cf0) at SpdyClientSession.cc:248
#8 0x0070d8bb in handleEvent (event=,
vc=0x2b7e94194b80) at ../../iocore/eventsystem/I_Continuation.h:146
#9 write_signal_and_update (event=, vc=0x2b7e94194b80) at
UnixNetVConnection.cc:153
#10 0x0070fe93 in write_to_net_io (nh=0x2b7d39f6dbc0,
vc=0x2b7e94194b80, thread=0x2b7d39f6a010) at UnixNetVConnection.cc:421
#11 0x00705c43 in NetHandler::mainNetEvent (this=0x2b7d39f6dbc0,
event=, e=) at UnixNet.cc:415
#12 0x0073252f in handleEvent (this=0x2b7d39f6a010, e=0x1e332f0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b7d39f6a010, e=0x1e332f0, calling_code=5)
at UnixEThread.cc:145
#14 0x00732ed3 in EThread::execute (this=0x2b7d39f6a010) at
UnixEThread.cc:269
#15 0x007318da in spawn_thread_internal (a=0x22a0a60) at Thread.cc:88
#16 0x2b7c97400851 in start_thread () from /lib64/libpthread.so.0
#17 0x0038818e894d in clone () from /lib64/libc.so.6
(gdb) quit
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2883) core dump in SpdyNV::SpdyNV
Sudheer Vinukonda created TS-2883:
-
Summary: core dump in SpdyNV::SpdyNV
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
{code}
(gdb) bt
#0 0x0038818328e5 in raise () from /lib64/libc.so.6
#1 0x0038818340c5 in abort () from /lib64/libc.so.6
#2 0x0038818707f7 in __libc_message () from /lib64/libc.so.6
#3 0x003881876126 in malloc_printerr () from /lib64/libc.so.6
#4 0x003881879ba4 in _int_malloc () from /lib64/libc.so.6
#5 0x00388187a951 in malloc () from /lib64/libc.so.6
#6 0x005f046d in SpdyNV::SpdyNV (this=0x2b2368301a00,
fetch_sm=0x2b258e8df7e0) at SpdyCommon.cc:93
#7 0x005ef300 in spdy_process_fetch_header (this=0x2b254c7201b0,
event=-2, edata=0x2b258e8df7e0) at SpdyClientSession.cc:359
#8 spdy_process_fetch (this=0x2b254c7201b0, event=-2, edata=0x2b258e8df7e0) at
SpdyClientSession.cc:321
#9 SpdyClientSession::state_session_readwrite (this=0x2b254c7201b0, event=-2,
edata=0x2b258e8df7e0) at SpdyClientSession.cc:251
#10 0x004a42fa in handleEvent (this=0x2b258e8df7e0, error_event=0) at
../iocore/eventsystem/I_Continuation.h:146
#11 FetchSM::InvokePluginExt (this=0x2b258e8df7e0, error_event=0) at
FetchSM.cc:233
#12 0x004a47d7 in FetchSM::process_fetch_read (this=0x2b258e8df7e0,
event=) at FetchSM.cc:400
#13 0x004a498b in FetchSM::fetch_handler (this=0x2b258e8df7e0,
event=100, edata=0x2b253d6550a8) at FetchSM.cc:449
#14 0x004dd2e5 in PluginVC::process_read_side (this=0x2b253d654fb0,
other_side_call=true) at PluginVC.cc:671
#15 0x004ddc3a in PluginVC::process_write_side (this=0x2b253d655190,
other_side_call=false) at PluginVC.cc:567
#16 0x004df405 in PluginVC::main_handler (this=0x2b253d655190,
event=, data=0x2b25cc556370) at PluginVC.cc:212
#17 0x0073252f in handleEvent (this=0x2b2361df9010, e=0x2b25cc556370,
calling_code=1) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b2361df9010, e=0x2b25cc556370,
calling_code=1) at UnixEThread.cc:145
#19 0x0073305b in EThread::execute (this=0x2b2361df9010) at
UnixEThread.cc:196
#20 0x007318da in spawn_thread_internal (a=0x2ffbfd0) at Thread.cc:88
#21 0x2b235fc7e851 in start_thread () from /lib64/libpthread.so.0
#22 0x0038818e894d in clone () from /lib64/libc.so.6
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2880) Change the permissions on traffic.out to 0644
[
https://issues.apache.org/jira/browse/TS-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021492#comment-14021492
]
ASF GitHub Bot commented on TS-2880:
GitHub user yzlai opened a pull request:
https://github.com/apache/trafficserver/pull/94
TS-2880 Change the permissions on traffic.out to 0644
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/yzlai/trafficserver TS-2880
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/94.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #94
commit 16cdc98e2ef37f01164cb39f4d7dd4823bf60982
Author: Ethan Lai
Date: 2014-06-09T00:21:03Z
TS-2880 Change the permissions on traffic.out to 0644
> Change the permissions on traffic.out to 0644
> -
>
> Key: TS-2880
> URL: https://issues.apache.org/jira/browse/TS-2880
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 5.0.0
>Reporter: Bryan Call
> Fix For: 5.1.0
>
>
> Currently:
> {code}
> [bcall@homer trafficserver]$ ll /usr/local/var/log/trafficserver/traffic.out
> -rw-r- 1 root root 119 Jun 5 15:18
> /usr/local/var/log/trafficserver/traffic.out
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021523#comment-14021523 ] Qiang Li commented on TS-2632: -- hi Leif Hedstrom i set proxy.config.http.cache.range.write enabled and my origin not support range request, it always response he full object (200 ok), so i send a range request to my ats, i get the full object, but the my ats can not cache it. curl -v -o /dev/null -H'Range:bytes=0-100' http://v1.leaderhero.com/basketball.mp4 * About to connect() to v1.leaderhero.com port 80 (#0) * Trying 58.215.133.101... connected * Connected to v1.leaderhero.com (58.215.133.101) port 80 (#0) > GET /basketball.mp4 HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 > zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: v1.leaderhero.com > Accept: */* > Range:bytes=0-100 > < HTTP/1.1 200 Ok < Content-Type: video/mp4 < Last-Modified: Mon, 06 Jan 2014 07:42:51 GMT < Content-Length: 17229714 < Server: ATS/4.1.2 < Powered-By-VeryCDN: MISS from my ats < Cache-Control: max-age=600 < Date: Mon, 09 Jun 2014 02:06:52 GMT < Age: 0 < Connection: keep-alive < Via: http/1.1 utn-cz-1-3-s18p1 (ApacheTrafficServer/5.0.0 [cMsSf ]) < > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021523#comment-14021523 ] Qiang Li edited comment on TS-2632 at 6/9/14 2:27 AM: -- hi Leif Hedstrom i set proxy.config.http.cache.range.write enabled and my origin not support range request, it always response he full object (200 ok), so i send a range request to my ats, i get the full object, but the my ats can not cache it. curl -v -o /dev/null -H'Range:bytes=0-100' http://v1.leaderhero.com/basketball.mp4 * About to connect() to v1.leaderhero.com port 80 (#0) * Trying 58.215.133.101... connected * Connected to v1.leaderhero.com (58.215.133.101) port 80 (#0) > GET /basketball.mp4 HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 > zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: v1.leaderhero.com > Accept: */* > Range:bytes=0-100 > < HTTP/1.1 200 Ok < Content-Type: video/mp4 < Last-Modified: Mon, 06 Jan 2014 07:42:51 GMT < Content-Length: 17229714 < Server: ATS/4.1.2 < Cache-Control: max-age=600 < Date: Mon, 09 Jun 2014 02:06:52 GMT < Age: 0 < Connection: keep-alive < was (Author: tufang14): hi Leif Hedstrom i set proxy.config.http.cache.range.write enabled and my origin not support range request, it always response he full object (200 ok), so i send a range request to my ats, i get the full object, but the my ats can not cache it. curl -v -o /dev/null -H'Range:bytes=0-100' http://v1.leaderhero.com/basketball.mp4 * About to connect() to v1.leaderhero.com port 80 (#0) * Trying 58.215.133.101... connected * Connected to v1.leaderhero.com (58.215.133.101) port 80 (#0) > GET /basketball.mp4 HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 > zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: v1.leaderhero.com > Accept: */* > Range:bytes=0-100 > < HTTP/1.1 200 Ok < Content-Type: video/mp4 < Last-Modified: Mon, 06 Jan 2014 07:42:51 GMT < Content-Length: 17229714 < Server: ATS/4.1.2 < Powered-By-VeryCDN: MISS from my ats < Cache-Control: max-age=600 < Date: Mon, 09 Jun 2014 02:06:52 GMT < Age: 0 < Connection: keep-alive < Via: http/1.1 utn-cz-1-3-s18p1 (ApacheTrafficServer/5.0.0 [cMsSf ]) < > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021539#comment-14021539 ] Leif Hedstrom commented on TS-2632: --- And this worked before this change? > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021542#comment-14021542 ] Qiang Li commented on TS-2632: -- Leif Hedstrom yes, it worked before this change > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021543#comment-14021543
]
Leif Hedstrom commented on TS-2632:
---
Ok, I'll take a look first thing tomorrow. You set
{code}
CONFIG proxy.config.http.cache.range.write INT 1
{code}
right ?
> Range request will always lock object in cache, even thought it's rarely
> cacheable
> --
>
> Key: TS-2632
> URL: https://issues.apache.org/jira/browse/TS-2632
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: range.diff
>
>
> Right now, if a client sends a Range: request, we still lock the URL in the
> cache, under the assumption that it will be written to. Since we don't
> support partial objects, in almost all cases, we'll not write the object and
> therefore release the object.
> I suggest we change this such that we never try to write lock a URL in the
> presence of a Range: header in the client request. This will allow other
> requests to go to origin faster, and better yet, it allows a request without
> a Range: header to properly lock the URL for writing. This turns out to be
> important for implementing e.g. "background filling" as a plugin.
> There is one use case where this might be useful; If the origin does not
> respond with a 206 (partial object), we can now cache the full object.
> However, this is a pretty rare case, and for someone to support this, all you
> have to do is to remove the Range: header on the request.
> I'm opening up this bug right now for discussion, if anyone have any concerns
> about this change, please let me know. It is an "incompatible" change,
> without configuration options, but that should be ok for the v5.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-2632: --- > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021544#comment-14021544 ] Qiang Li commented on TS-2632: -- Leif Hedstrom yes i set CONFIG proxy.config.http.cache.range.write INT 1 in my records.config > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021547#comment-14021547 ] Leif Hedstrom commented on TS-2632: --- Argh, I think this is a botched commit :-/. I initially had the configuration, took it out, and then put it back in again. It looks to me, I think, like I missed putting it back properly. I'll work on it tomorrow. > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
