[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000239#comment-15000239 ] Boaz Reicher commented on TS-4010: -- Hi [~briang], There's already a hook point for TS_HTTP_READ_CACHE_HDR_HOOK: https://github.com/apache/trafficserver/blob/master/lib/atscppapi/src/utils_internal.cc#L130 If it's missing someplace else, can you please point me to it and I'll add it? Thanks, > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3993) Would like a way to mark cache objects as stale
[
https://issues.apache.org/jira/browse/TS-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3993:
--
Fix Version/s: sometime
> Would like a way to mark cache objects as stale
> ---
>
> Key: TS-3993
> URL: https://issues.apache.org/jira/browse/TS-3993
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache
>Reporter: Felicity Tarnell
> Fix For: sometime
>
>
> We use {{stale-if-error}} to return cached content to clients in case of
> origin server failure. However, if an object is removed from the cache by a
> PURGE request, and the origin fails before another client requests the same
> object, an error will be served.
> Instead of using PURGE, we'd like a way to mark the cache item as stale, but
> not delete it, so it will be revalidated on the next request, and if the
> origin is unavailable, it can be served by {{stale-if-error}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3992) enhancement of traffic control command to display cache size in full cluster mode
[ https://issues.apache.org/jira/browse/TS-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3992: -- Fix Version/s: sometime > enhancement of traffic control command to display cache size in full cluster > mode > --- > > Key: TS-3992 > URL: https://issues.apache.org/jira/browse/TS-3992 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Sunil Vasanta > Fix For: sometime > > > I have two ATS node in a cluster each having 10GB cache, I can see cache size > of individual ATS node by using traffic_ctrl command. > Existing implementation of traffic_control command don't have metric to see > full size of logical cache in Full cluster mode. > Request to enhance existing command to displays cache statistics considering > all node of cluster. That will help a lot. > Many Thanks, > Sunil Vasanta -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4014) Update HTTP/2 dynamic table size smartly
[
https://issues.apache.org/jira/browse/TS-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-4014:
--
Fix Version/s: 6.1.0
> Update HTTP/2 dynamic table size smartly
>
>
> Key: TS-4014
> URL: https://issues.apache.org/jira/browse/TS-4014
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> We don't need to update dynamic table size per every updates.
> {quote}
> Multiple updates to the maximum table size can occur between the
> transmission of two header blocks. In the case that this size is
> changed more than once in this interval, the smallest maximum table
> size that occurs in that interval MUST be signaled in a dynamic table
> size update. The final maximum size is always signaled, resulting in
> at most two dynamic table size updates. This ensures that the
> decoder is able to perform eviction based on reductions in dynamic
> table size (see Section 4.3).
> {quote}
> https://tools.ietf.org/html/rfc7541#section-4.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4012) tcp_reused log field doesn't work for http2/spdy
[ https://issues.apache.org/jira/browse/TS-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4012: -- Fix Version/s: 6.1.0 > tcp_reused log field doesn't work for http2/spdy > > > Key: TS-4012 > URL: https://issues.apache.org/jira/browse/TS-4012 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eric Schwartz >Assignee: Eric Schwartz > Fix For: 6.1.0 > > > This is something we noticed at Yahoo! > Because it uses the HttpClientSession transact_count, the tcp_reused log > field will not properly work for http2 and spdy, where the HttpClientSession > isn't reused. > We need to essentially count the number of initiated streams instead. > We've got a fix that does this for HTTP2. With SPDY eventually dying off, > does it make sense to also submit a change to fix this for SPDY? We have code > to do this as well, but it currently involves an H2 dependency that might be > undesirable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4009) stale_while_revalidate crash
[
https://issues.apache.org/jira/browse/TS-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-4009:
--
Fix Version/s: 6.1.0
> stale_while_revalidate crash
>
>
> Key: TS-4009
> URL: https://issues.apache.org/jira/browse/TS-4009
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.0.0
>Reporter: Christoph Keller
> Labels: regression
> Fix For: 6.1.0
>
>
> Since 6.0 stale_while_revalidate-plugin crashes after serving a stale
> document while trying to get the new one. Can reproduce this issue with 6.0.x
> and master branch using the provided testserver. 5.3.x works fine. Doesn't
> look like that issue is up to some changes in the plugin-code so i guess it's
> an issue in the core code.
> {quote}
> #0 0x2b75ae4625d7 in raise () from /lib64/libc.so.6
> #1 0x2b75ae463cc8 in abort () from /lib64/libc.so.6
> #2 0x2b75abdfd29d in ink_die_die_die () at ink_error.cc:43
> #3 0x2b75abdfd356 in ink_fatal_va (fmt=0x2b75abe0e088 "%s:%d: failed
> assert `%s`", ap=0x2b75c0804a48) at ink_error.cc:65
> #4 0x2b75abdfd3f5 in ink_fatal (message_format=0x2b75abe0e088 "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x2b75abdfb016 in _ink_assert (expression=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at ink_assert.cc:37
> #6 0x0051a5e2 in _TSReleaseAssert (text=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at InkAPI.cc:407
> #7 0x00528563 in TSVConnRead (connp=0x2b75d928, contp=0x28e6d60,
> bufp=0x2b75b801d5b0, nbytes=9223372036854775807) at InkAPI.cc:6302
> #8 0x2b75b65d1795 in fetch_resource (cont=0x28e6dd0,
> event=TS_EVENT_IMMEDIATE, edata=0x2825ba0) at stale_while_revalidate.c:449
> #9 0x0051b4a7 in INKContInternal::handle_event (this=0x28e6dd0,
> event=1, edata=0x2825ba0) at InkAPI.cc:1005
> #10 0x00506e34 in Continuation::handleEvent (this=0x28e6dd0, event=1,
> data=0x2825ba0) at ../iocore/eventsystem/I_Continuation.h:146
> #11 0x007ac72e in EThread::process_event (this=0x2b75c0503010,
> e=0x2825ba0, calling_code=1) at UnixEThread.cc:128
> #12 0x007ac990 in EThread::execute (this=0x2b75c0503010) at
> UnixEThread.cc:179
> #13 0x007abc91 in spawn_thread_internal (a=0x2a7d460) at Thread.cc:86
> #14 0x2b75ad48cdf5 in start_thread () from /lib64/libpthread.so.0
> #15 0x2b75ae5231ad in clone () from /lib64/libc.so.6
> {quote}
> EDIT: I guess i just found it. I don't know why but NULL seems to be a
> problem right here
> "consume_cont = TSContCreate(consume_resource, NULL);" in fetch_resource
> In case i create a new TSMutex and pass it to this call it seems to work.
> Trying to make a patch for that now.
> I guess it is broken due to these changes:
> https://issues.apache.org/jira/browse/TS-3569
> https://github.com/apache/trafficserver/commit/a36c416786c79c643cd11fd332274365bc893bb6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3994: -- Fix Version/s: 6.1.0 > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000734#comment-15000734 ] Leif Hedstrom commented on TS-3994: --- Is this completed? > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3999) Add option to go direct for specific parent entry
[
https://issues.apache.org/jira/browse/TS-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3999:
--
Fix Version/s: 6.1.0
> Add option to go direct for specific parent entry
> -
>
> Key: TS-3999
> URL: https://issues.apache.org/jira/browse/TS-3999
> Project: Traffic Server
> Issue Type: Improvement
> Components: Parent Proxy
>Reporter: Alan M. Carroll
> Fix For: 6.1.0
>
>
> We want to use parenty proxying in a peer relationship so that a host can be
> both a parent and child in general but only for a specific URL. Currently
> this can be done using the CARP plugin but that can create some difficulties.
> Being able to specify that one parent in the list is actually direct to
> origin would make that much easier.
> The current suggestion is to overload the port specifier as a indicator of
> direct. For example, if you had three hosts in a pod, {{rikku}}, {{tidus}},
> and {{yuna}}, then you would configure the parent proxying on {{tidus}} as
> {code}
> "tidus:@direct, yuna:8080, rikku:8080"
> {code}
> while the configuration on {{yuna}} would be
> {code}
> "tidus:8080, yuna:@direct, rikku:8080"
> {code}.
> Similarly for {{rikku}} the port would be changed to "@direct" just for the
> "rikku" parent. I discussed several configuration options for this with
> [~dcarlin] and putting the override directly in the parent list was his
> preferred mechanism. Note that in order to have consistency between hosts in
> a pod, the list of names *must* be exactly the same across all the peers. In
> this case, it must be "tidus, yuna, rikku" for all three or loops will occur
> because of different hash seeds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000743#comment-15000743 ] Sudheer Vinukonda commented on TS-3994: --- Yes :) > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3970) Core in PluginVC
[
https://issues.apache.org/jira/browse/TS-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-3970.
--
Resolution: Invalid
Turns out the problem was in the plugin. Their clean up code called
TSIOBufferDestroy() before TSIOBufferReaderFree() on a reader for that buffer.
This revealed a use after free error that was found quickly with ASAN. With
this error, it was possible to have the Buffer reallocated and effectively have
readers on the newly reallocated buffer cleared randomly.
> Core in PluginVC
>
>
> Key: TS-3970
> URL: https://issues.apache.org/jira/browse/TS-3970
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Labels: crash
> Fix For: 6.1.0
>
> Attachments: ts-3970.diff
>
>
> One of our plugins moving from 5.0.1 to 5.3.x (plus 6.0 backports) started
> seeing the following stack trace with high frequency.
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 0x0054c232 in PluginVC::process_read_side (this=0x2b9ace2f3850,
> other_side_call=true) at PluginVC.cc:638
> in PluginVC.cc
> #0 0x0054c232 in PluginVC::process_read_side (this=0x2b9ace2f3850,
> other_side_call=true) at PluginVC.cc:638
> #1 0x0054be2a in PluginVC::process_write_side (this=0x2b9ace2f3a40,
> other_side_call=false) at PluginVC.cc:555
> #2 0x0054acdb in PluginVC::main_handler (this=0x2b9ace2f3a40,
> event=1, data=0x2b9b1e32e930) at PluginVC.cc:208
> #3 0x00510c84 in Continuation::handleEvent (this=0x2b9ace2f3a40,
> event=1, data=0x2b9b1e32e930) at ../iocore/eventsystem/I_Continuation.h:145
> #4 0x0079a2a6 in EThread::process_event (this=0x2b9ab63d9010,
> e=0x2b9b1e32e930, calling_code=1) at UnixEThread.cc:128
> #5 0x0079a474 in EThread::execute (this=0x2b9ab63d9010) at
> UnixEThread.cc:179
> #6 0x00799851 in spawn_thread_internal (a=0x2fea360) at Thread.cc:85
> #7 0x2b9ab457e9d1 in start_thread () from /lib64/libpthread.so.0
> #8 0x0030d38e88fd in clone () from /lib64/libc.so.6
> {code}
> The output buffer fetched by PluginVC::process_read_side was NULL.
> I think they reason this appears in 5.3 is due to the fix for TS-3522.
> Before that change only one do_io_read was made very early to set up the read
> from server. This bug fix delays the real read to later and pulls mbuf out
> of server_buffer_reader. In some cases for this plugin, the mbuf is NULL by
> the time we get there.
> I fixed the core by using server_session->read_buffer in the do_io_read
> instead of server_buffer_reader->mbuf. This seems to fix the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4015: -- Labels: review (was: ) > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Labels: review > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4009) stale_while_revalidate crash
[
https://issues.apache.org/jira/browse/TS-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-4009:
--
Labels: regression (was: )
> stale_while_revalidate crash
>
>
> Key: TS-4009
> URL: https://issues.apache.org/jira/browse/TS-4009
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.0.0
>Reporter: Christoph Keller
> Labels: regression
> Fix For: 6.1.0
>
>
> Since 6.0 stale_while_revalidate-plugin crashes after serving a stale
> document while trying to get the new one. Can reproduce this issue with 6.0.x
> and master branch using the provided testserver. 5.3.x works fine. Doesn't
> look like that issue is up to some changes in the plugin-code so i guess it's
> an issue in the core code.
> {quote}
> #0 0x2b75ae4625d7 in raise () from /lib64/libc.so.6
> #1 0x2b75ae463cc8 in abort () from /lib64/libc.so.6
> #2 0x2b75abdfd29d in ink_die_die_die () at ink_error.cc:43
> #3 0x2b75abdfd356 in ink_fatal_va (fmt=0x2b75abe0e088 "%s:%d: failed
> assert `%s`", ap=0x2b75c0804a48) at ink_error.cc:65
> #4 0x2b75abdfd3f5 in ink_fatal (message_format=0x2b75abe0e088 "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x2b75abdfb016 in _ink_assert (expression=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at ink_assert.cc:37
> #6 0x0051a5e2 in _TSReleaseAssert (text=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at InkAPI.cc:407
> #7 0x00528563 in TSVConnRead (connp=0x2b75d928, contp=0x28e6d60,
> bufp=0x2b75b801d5b0, nbytes=9223372036854775807) at InkAPI.cc:6302
> #8 0x2b75b65d1795 in fetch_resource (cont=0x28e6dd0,
> event=TS_EVENT_IMMEDIATE, edata=0x2825ba0) at stale_while_revalidate.c:449
> #9 0x0051b4a7 in INKContInternal::handle_event (this=0x28e6dd0,
> event=1, edata=0x2825ba0) at InkAPI.cc:1005
> #10 0x00506e34 in Continuation::handleEvent (this=0x28e6dd0, event=1,
> data=0x2825ba0) at ../iocore/eventsystem/I_Continuation.h:146
> #11 0x007ac72e in EThread::process_event (this=0x2b75c0503010,
> e=0x2825ba0, calling_code=1) at UnixEThread.cc:128
> #12 0x007ac990 in EThread::execute (this=0x2b75c0503010) at
> UnixEThread.cc:179
> #13 0x007abc91 in spawn_thread_internal (a=0x2a7d460) at Thread.cc:86
> #14 0x2b75ad48cdf5 in start_thread () from /lib64/libpthread.so.0
> #15 0x2b75ae5231ad in clone () from /lib64/libc.so.6
> {quote}
> EDIT: I guess i just found it. I don't know why but NULL seems to be a
> problem right here
> "consume_cont = TSContCreate(consume_resource, NULL);" in fetch_resource
> In case i create a new TSMutex and pass it to this call it seems to work.
> Trying to make a patch for that now.
> I guess it is broken due to these changes:
> https://issues.apache.org/jira/browse/TS-3569
> https://github.com/apache/trafficserver/commit/a36c416786c79c643cd11fd332274365bc893bb6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3994) Internal Redirect follow should allow to use API set cache key.
[ https://issues.apache.org/jira/browse/TS-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3994. --- Resolution: Fixed > Internal Redirect follow should allow to use API set cache key. > --- > > Key: TS-3994 > URL: https://issues.apache.org/jira/browse/TS-3994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Currently, during redirect follow, uses the Location header in the 3xx > response as the cache key (and does not use the cache key set by using an > API, for example). > This can break the ability to serve cached response in some cases, where the > redirect follow is performed (via a plugin to implement a simple fail-over > mechanism between origin hosts, for example). > Opening this jira to add a new configuration option to allow using original > request cache key to lookup during redirect follow. > This was briefly discussed in TS-3652, but, TS-3652 was actually tracking a > different problem (turned out to be a regression) that prevents a redirect > response being cached altogether. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4016: -- Fix Version/s: 6.1.0 > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Labels: review > Fix For: 6.1.0 > > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4016: -- Labels: review (was: ) > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Labels: review > Fix For: 6.1.0 > > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-4015: -- Fix Version/s: 6.1.0 > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Labels: review > Fix For: 6.1.0 > > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000479#comment-15000479 ] Boaz Reicher commented on TS-4015: -- [~briang], [~sudheerv] : Can you please review and merge? Note: I'm aware that this functionality already exists in Response::setStatusCode(), but this is required in cases where the Response objects haven't been initialized yet. For example, a plugin that needs to block requests after reading the request headers and set a 401 return status would use this method (and Transaction::error(const std::string )). Thanks, > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000504#comment-15000504 ] Sudheer Vinukonda commented on TS-4015: --- lgtm - if [~briang] also +1's, I can merge it. > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4016) Add the ability to skip the remap phase of the SM
Boaz Reicher created TS-4016: Summary: Add the ability to skip the remap phase of the SM Key: TS-4016 URL: https://issues.apache.org/jira/browse/TS-4016 Project: Traffic Server Issue Type: Improvement Components: CPP API Reporter: Boaz Reicher Assignee: Brian Geffon Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000538#comment-15000538 ] Boaz Reicher commented on TS-4016: -- [~briang], [~sudheerv] : Can you please review this patch? Thanks, > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boaz Reicher updated TS-4016: - Attachment: ts-4016.diff > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4015: - Assignee: Sudheer Vinukonda (was: Brian Geffon) > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4015) Add a transaction method to set the HTTP return status
Boaz Reicher created TS-4015: Summary: Add a transaction method to set the HTTP return status Key: TS-4015 URL: https://issues.apache.org/jira/browse/TS-4015 Project: Traffic Server Issue Type: Improvement Components: CPP API Reporter: Boaz Reicher Assignee: Brian Geffon The Transaction class should have a method that allows setting the HTTP return status without requiring a Response object. Primarily needed for setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4015) Add a transaction method to set the HTTP return status
[ https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boaz Reicher updated TS-4015: - Attachment: patch-4015.diff > Add a transaction method to set the HTTP return status > -- > > Key: TS-4015 > URL: https://issues.apache.org/jira/browse/TS-4015 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Attachments: patch-4015.diff > > > The Transaction class should have a method that allows setting the HTTP > return status without requiring a Response object. Primarily needed for > setting error responses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000492#comment-15000492 ] Sudheer Vinukonda commented on TS-4010: --- Thanks, [~briang] - Yes, this is all [~boazr]'s work :) > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-4016: - Assignee: Sudheer Vinukonda (was: Brian Geffon) > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4016) Add the ability to skip the remap phase of the SM
[ https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000551#comment-15000551 ] Sudheer Vinukonda commented on TS-4016: --- lgtm (will merge if [~briang] okay's it). > Add the ability to skip the remap phase of the SM > - > > Key: TS-4016 > URL: https://issues.apache.org/jira/browse/TS-4016 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Sudheer Vinukonda > Attachments: ts-4016.diff > > > Adding a method to the Transaction class to skip the remap phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000364#comment-15000364 ] Boaz Reicher commented on TS-4010: -- You can list me as the author. Thanks, > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4015) Add a transaction method to set the HTTP return status
[
https://issues.apache.org/jira/browse/TS-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001708#comment-15001708
]
Brian Geffon commented on TS-4015:
--
Fwiw, the way that was typically handled in the past was by adding a
transaction hook to SendResponseHeader
https://github.com/apache/trafficserver/blob/master/lib/atscppapi/examples/customresponse/CustomResponse.cc
and then changing those codes once you have a Response object.
Given the message in ts.h:
{code}
/* ToDo: This is a leftover from olden days, can we eliminate? */
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus);
{code}
I question whether we should take this route...?
Brian
> Add a transaction method to set the HTTP return status
> --
>
> Key: TS-4015
> URL: https://issues.apache.org/jira/browse/TS-4015
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Boaz Reicher
>Assignee: Sudheer Vinukonda
> Labels: review
> Fix For: 6.1.0
>
> Attachments: patch-4015.diff
>
>
> The Transaction class should have a method that allows setting the HTTP
> return status without requiring a Response object. Primarily needed for
> setting error responses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4016) Add the ability to skip the remap phase of the SM
[
https://issues.apache.org/jira/browse/TS-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001711#comment-15001711
]
Brian Geffon commented on TS-4016:
--
Good w/ me , please just fix the comment :
{code}
+ /*-
+ * Set the status code returned to the client
+ * @param http status to set
+ */
{code}
I think it should be:
{code}
+ /**
{code}
> Add the ability to skip the remap phase of the SM
> -
>
> Key: TS-4016
> URL: https://issues.apache.org/jira/browse/TS-4016
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Boaz Reicher
>Assignee: Sudheer Vinukonda
> Labels: review
> Fix For: 6.1.0
>
> Attachments: ts-4016.diff
>
>
> Adding a method to the Transaction class to skip the remap phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4010) Add cached request/response to the CPP API transaction object
[ https://issues.apache.org/jira/browse/TS-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001705#comment-15001705 ] ASF subversion and git services commented on TS-4010: - Commit e5fed400699855ecb27e0e17cd0f2380daddcb70 in trafficserver's branch refs/heads/master from [~boazr] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e5fed40 ] TS-4010: Add cached request/response to the CPP API transaction object > Add cached request/response to the CPP API transaction object > - > > Key: TS-4010 > URL: https://issues.apache.org/jira/browse/TS-4010 > Project: Traffic Server > Issue Type: Improvement > Components: CPP API >Reporter: Boaz Reicher >Assignee: Brian Geffon > Fix For: 6.1.0 > > Attachments: ts-4010.diff > > > The transaction object should contain handles to the cached request and > response. > The cached request/response objects should be initialized after > TS_EVENT_HTTP_READ_CACHE_HDR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3991) Coredump seen on plugins written using CPP API
[
https://issues.apache.org/jira/browse/TS-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Geffon updated TS-3991:
-
Description:
Here are the traces on the coredumps we are seeing
{code}
#0 0x2aab682e99a0 in ?? ()
No symbol table info available.
#1 0x2b4b8179 in
std::tr1::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x2aab6809cb10) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/boost_sp_counted_base.h:140
No locals.
#2 0x2b6dfb61 in
std::tr1::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x2b1c832f8bc8, __in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:153
No locals.
#3 0x2b6df94e in std::tr1::__shared_ptr::~__shared_ptr (this=0x2b1c832f8bc0,
__in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:358
No locals.
#4 0x2b6df98e in std::tr1::shared_ptr::~shared_ptr
(this=0x2b1c832f8bc0, __in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:834
No locals.
#5 0x2b6f1e0a in
atscppapi::ScopedSharedMutexTryLock::~ScopedSharedMutexTryLock
(this=0x2b1c832f8bc0, __in_chrg=) at
include/atscppapi/Mutex.h:234
No locals.
#6 0x2b6f1c77 in (anonymous namespace)::handleEvents (cont=0x28eb430,
pristine_event=TS_EVENT_TIMEOUT, pristine_edata=0x2aab20079450) at
InterceptPlugin.cc:347
edata = 0x2aab20079450
state = 0x2aab6809cb80
__FUNCTION__ = "handleEvents"
event = TS_EVENT_TIMEOUT
scopedTryLock = { = {}, mutex_
= std::tr1::shared_ptr (count 0) 0x2aab6809caa0, has_lock_ = false}
#7 0x0050bac8 in INKContInternal::handle_event (this=0x28eb430,
event=2, edata=0x2aab20079450) at InkAPI.cc:1000
No locals.
#8 0x004f70d8 in Continuation::handleEvent (this=0x28eb430, event=2,
data=0x2aab20079450) at ../iocore/eventsystem/I_Continuation.h:146
No locals.
#9 0x0075a8d2 in EThread::process_event (this=0x2b1c80ed6010,
e=0x2aab20079450, calling_code=2) at UnixEThread.cc:145
c_temp = 0x28eb430
lock = {m = {m_ptr = 0x2aaabc0eca50}, lock_acquired = true}
#10 0x0075abed in EThread::execute (this=0x2b1c80ed6010) at
UnixEThread.cc:224
done_one = true
e = 0x2aab20079450
NegativeQueue = {> = {head = 0x257bcf0},
tail = 0x257bcf0}
next_time = 1444322819831472139
#11 0x00759e50 in spawn_thread_internal (a=0x2447860) at Thread.cc:88
p = 0x2447860
#12 0x2b1c7f9cd9d1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#13 0x00381b8e88fd in clone () from /lib64/libc.so.6
{code}
was:
Here are the traces on the coredumps we are seeing
#0 0x2aab682e99a0 in ?? ()
No symbol table info available.
#1 0x2b4b8179 in
std::tr1::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0x2aab6809cb10) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1_impl/boost_sp_counted_base.h:140
No locals.
#2 0x2b6dfb61 in
std::tr1::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count
(this=0x2b1c832f8bc8, __in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:153
No locals.
#3 0x2b6df94e in std::tr1::__shared_ptr::~__shared_ptr (this=0x2b1c832f8bc0,
__in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:358
No locals.
#4 0x2b6df98e in std::tr1::shared_ptr::~shared_ptr
(this=0x2b1c832f8bc0, __in_chrg=) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/tr1/shared_ptr.h:834
No locals.
#5 0x2b6f1e0a in
atscppapi::ScopedSharedMutexTryLock::~ScopedSharedMutexTryLock
(this=0x2b1c832f8bc0, __in_chrg=) at
include/atscppapi/Mutex.h:234
No locals.
#6 0x2b6f1c77 in (anonymous namespace)::handleEvents (cont=0x28eb430,
pristine_event=TS_EVENT_TIMEOUT, pristine_edata=0x2aab20079450) at
InterceptPlugin.cc:347
edata = 0x2aab20079450
state = 0x2aab6809cb80
__FUNCTION__ = "handleEvents"
event = TS_EVENT_TIMEOUT
scopedTryLock = { = {}, mutex_
= std::tr1::shared_ptr (count 0) 0x2aab6809caa0, has_lock_ = false}
#7 0x0050bac8 in INKContInternal::handle_event (this=0x28eb430,
event=2, edata=0x2aab20079450) at InkAPI.cc:1000
No locals.
#8 0x004f70d8 in Continuation::handleEvent (this=0x28eb430, event=2,
data=0x2aab20079450) at ../iocore/eventsystem/I_Continuation.h:146
No locals.
#9 0x0075a8d2 in EThread::process_event (this=0x2b1c80ed6010,
e=0x2aab20079450, calling_code=2) at UnixEThread.cc:145
c_temp = 0x28eb430
lock = {m = {m_ptr =
[jira] [Commented] (TS-3863) Add support for ASAN leak detection
[
https://issues.apache.org/jira/browse/TS-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001332#comment-15001332
]
Bryan Call commented on TS-3863:
Issue 1:
{code}
=
==26578==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new vs free)
on 0x6071cd40
#0 0x7f488121370a in __interceptor_free (/lib64/libasan.so.2+0x9870a)
#1 0x7f4880f45e50 in ink_freelist_free
/home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:270
#2 0x7f487e17e657 in __run_exit_handlers (/lib64/libc.so.6+0x39657)
#3 0x7f487e17e6a4 in exit (/lib64/libc.so.6+0x396a4)
#4 0x583efd in proxy_signal_handler
/home/bcall/dev/apache/trafficserver/proxy/Main.cc:394
#5 0x7f487f31b9ef (/lib64/libpthread.so.0+0x109ef)
#6 0x7f487e2481b2 in __GI_epoll_wait (/lib64/libc.so.6+0x1031b2)
#7 0xc2c148 in NetHandler::mainNetEvent(int, Event*)
/home/bcall/dev/apache/trafficserver/iocore/net/UnixNet.cc:427
#8 0xd1b720 in Continuation::handleEvent(int, void*)
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
#9 0xd1b720 in EThread::process_event(Event*, int)
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#10 0xd1b720 in EThread::execute()
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:252
#11 0x495044 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1922
#12 0x7f487e16557f in __libc_start_main (/lib64/libc.so.6+0x2057f)
#13 0x4a3d58 in _start (/usr/local/bin/traffic_server+0x4a3d58)
0x6071cd40 is located 0 bytes inside of 72-byte region
[0x6071cd40,0x6071cd88)
allocated by thread T0 ([ET_NET 0]) here:
#0 0x7f4881214912 in operator new(unsigned long)
(/lib64/libasan.so.2+0x99912)
#1 0x6d8746 in init_HttpProxyServer(int)
/home/bcall/dev/apache/trafficserver/proxy/http/HttpProxyServerMain.cc:266
#2 0x49484a in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1850
#3 0x7f487e16557f in __libc_start_main (/lib64/libc.so.6+0x2057f)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch ??:0 __interceptor_free
==26578==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==26578==ABORTING
{code}
> Add support for ASAN leak detection
> ---
>
> Key: TS-3863
> URL: https://issues.apache.org/jira/browse/TS-3863
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Bryan Call
> Labels: yahoo
> Fix For: 6.1.0
>
>
> We will need to call exit() instead of _exit() and fix all the coredumps that
> happen when objects are being cleaned up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3863) Add support for ASAN leak detection
[ https://issues.apache.org/jira/browse/TS-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001339#comment-15001339 ] ASF subversion and git services commented on TS-3863: - Commit 447ad332f083242c76b1cd8bd183ad60a44c4bc2 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=447ad33 ] TS-3863: Add support for ASAN leak detection The ssl_plugin_mutex is newed and then freed by the proxy allocator. Using the proxy allocator to allocate it. > Add support for ASAN leak detection > --- > > Key: TS-3863 > URL: https://issues.apache.org/jira/browse/TS-3863 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call > Labels: yahoo > Fix For: 6.1.0 > > > We will need to call exit() instead of _exit() and fix all the coredumps that > happen when objects are being cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3863) Add support for ASAN leak detection
[ https://issues.apache.org/jira/browse/TS-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-3863: -- Assignee: Bryan Call > Add support for ASAN leak detection > --- > > Key: TS-3863 > URL: https://issues.apache.org/jira/browse/TS-3863 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call >Assignee: Bryan Call > Labels: yahoo > Fix For: 6.1.0 > > > We will need to call exit() instead of _exit() and fix all the coredumps that > happen when objects are being cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3863) Add support for ASAN leak detection
[
https://issues.apache.org/jira/browse/TS-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001378#comment-15001378
]
Bryan Call commented on TS-3863:
I am not seeing ATS core anymore when using exit() instead of _exit(). I am
running on Fedora 23:
Patch:
{code}
diff --git a/proxy/Main.cc b/proxy/Main.cc
index 0859603..1369a06 100644
--- a/proxy/Main.cc
+++ b/proxy/Main.cc
@@ -391,7 +391,7 @@ proxy_signal_handler(int signo, siginfo_t *info, void *)
return;
}
- _exit(signo);
+ exit(signo);
}
//
{code}
Without asan compiled:
{code}
[bcall@homer trafficserver]$ sudo /usr/local/bin/traffic_server
traffic_server: using root directory '/usr/local'
^Ctraffic_server: Interrupt (Signal sent by the kernel 0 0)
[bcall@homer trafficserver]$ date
Wed Nov 11 16:09:16 PST 2015
[bcall@homer trafficserver]$ coredumpctl
TIMEPID UID GID SIG PRESENT EXE
Tue 2015-11-10 17:56:07 PST 17907 0 0 11 * /usr/bin/perl
Tue 2015-11-10 17:56:08 PST 17909 0 0 11 * /usr/bin/perl
Wed 2015-11-11 09:54:01 PST 103659999 6
/usr/local/bin/traffic_server
Wed 2015-11-11 09:57:38 PST 107629999 6
/usr/local/bin/traffic_server
Wed 2015-11-11 10:06:02 PST 142709999 6
/usr/local/bin/traffic_server
Wed 2015-11-11 10:07:37 PST 143779999 6
/usr/local/bin/traffic_server
Wed 2015-11-11 10:08:28 PST 144759999 6
/usr/local/bin/traffic_serve
{code}
I was having a problem with this before, so we are able to use the ASAN leak
detection now.
With asan compiled:
{code}
[bcall@homer trafficserver]$ sudo /usr/local/bin/traffic_server -f
traffic_server: using root directory '/usr/local'
^Ctraffic_server: Interrupt (Signal sent by the kernel 0 0)
=
==3791==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 294 byte(s) in 23 object(s) allocated from:
#0 0x7f658f5baa0a in malloc (/lib64/libasan.so.2+0x98a0a)
#1 0x7f658f2ebdf5 in ats_malloc
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
#2 0x7f658f2ec096 in _xstrdup
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:225
#3 0x8b57c1 in LogFieldAliasTable::init(unsigned long, ...)
/home/bcall/dev/apache/trafficserver/proxy/logging/LogFieldAliasMap.cc:78
#4 0x88b9e3 in Log::init_fields()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:579
#5 0x88df1f in Log::init_when_enabled()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:909
#6 0x88eb84 in Log::init(int)
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:898
#7 0x4943e5 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1798
#8 0x7f658c50c57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
Direct leak of 29 byte(s) in 2 object(s) allocated from:
#0 0x7f658f5baa0a in malloc (/lib64/libasan.so.2+0x98a0a)
#1 0x7f658f2ebdf5 in ats_malloc
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
#2 0x7f658f2ec096 in _xstrdup
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:225
#3 0x8b57c1 in LogFieldAliasTable::init(unsigned long, ...)
/home/bcall/dev/apache/trafficserver/proxy/logging/LogFieldAliasMap.cc:78
#4 0x88d008 in Log::init_fields()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:784
#5 0x88df1f in Log::init_when_enabled()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:909
#6 0x88eb84 in Log::init(int)
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:898
#7 0x4943e5 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1798
#8 0x7f658c50c57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
Direct leak of 23 byte(s) in 5 object(s) allocated from:
#0 0x7f658f5baa0a in malloc (/lib64/libasan.so.2+0x98a0a)
#1 0x7f658f2ebdf5 in ats_malloc
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
#2 0x7f658f2ec096 in _xstrdup
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:225
#3 0x8b57c1 in LogFieldAliasTable::init(unsigned long, ...)
/home/bcall/dev/apache/trafficserver/proxy/logging/LogFieldAliasMap.cc:78
#4 0x88cab3 in Log::init_fields()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:746
#5 0x88df1f in Log::init_when_enabled()
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:909
#6 0x88eb84 in Log::init(int)
/home/bcall/dev/apache/trafficserver/proxy/logging/Log.cc:898
#7 0x4943e5 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1798
#8 0x7f658c50c57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f658f5bb912 in operator new(unsigned long)
(/lib64/libasan.so.2+0x99912)
#1 0xa08b33 in SplitDNSConfig::startup()
/home/bcall/dev/apache/trafficserver/iocore/dns/SplitDNS.cc:133
#2 0x494299 in main
[jira] [Commented] (TS-3995) "[hcoofsr] conditional request, 200 response, send back 304 if possible [crc=304]" breaks akamaihd.net live streaming
[
https://issues.apache.org/jira/browse/TS-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001221#comment-15001221
]
ASF GitHub Bot commented on TS-3995:
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/330#discussion_r44594400
--- Diff: proxy/http/HttpTransactCache.cc ---
@@ -1299,7 +1299,7 @@
HttpTransactCache::match_response_to_request_conditionals(HTTPHdr *request, HTTP
ink_time_t lm_value = response->get_last_modified();
// we won't return NOT_MODIFIED if Last-modified is too recent
- if ((lm_value == 0) || (request->get_if_modified_since() <
lm_value)) {
--- End diff --
I am -1 on this change.
You are failing to see how this change would modify the behavior for
everyone else that uses ATS. If you want to submit a change that would have a
configuration to turn this feature off then that would be better.
> "[hcoofsr] conditional request, 200 response, send back 304 if possible
> [crc=304]" breaks akamaihd.net live streaming
> -
>
> Key: TS-3995
> URL: https://issues.apache.org/jira/browse/TS-3995
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core, HTTP
>Affects Versions: 5.3.2
>Reporter: Nikolai Gorchilov
> Labels: review
> Fix For: 6.1.0
>
>
> Caching proxy running ATS 5.3.x (5.3.0, 5.3.1, 5.3.2 all fail) with
> proxy.config.http.cache.when_to_revalidate = 4 breaks akamaihd.net live
> streaming.
> The actual problem is that ATS rewrites origin response from 200 to 304, due
> to If-Modified-Since conditional header in client's request. As per ATS logic
> object is unmodified, but in fact it is. Most probably player and server
> somehow play with if-modified-since/last-modified headers pair to communicate
> position in the live stream. What is obvious is that Last-Modified =
> If-Modified-Since.
> As result, Akamai player keeps repeating the said request, expecting it's
> 200, but getting 304 thus live video freezes forever, just a few seconds
> after start.
> IMHO when proxy.config.http.cache.when_to_revalidate = 4, ATS shall not
> interfere with origin response in this manner.
> Here's a debug log of request and response headers at different states in a
> single transaction:
> {noformat}
> + Incoming Request +
> -- State Machine Id: 168
> GET
> http:///z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> Connection: keep-alive
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language: en-US,en;q=0.8,bg;q=0.6
> Cookie: _alid_=PmjLqgcUUqw6TP5gtK/xbg==;
> hdntl=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8
> If-Modified-Since: Thu, 05 Nov 2015 02:30:28 GMT
> + Proxy's Request +
> -- State Machine Id: 168
> GET
> /z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language: en-US,en;q=0.8,bg;q=0.6
> Cookie: _alid_=PmjLqgcUUqw6TP5gtK/xbg==;
> hdntl=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8
> If-Modified-Since: Thu, 05 Nov 2015 02:30:28 GMT
> + Proxy's Request after hooks +
> -- State Machine Id: 168
> GET
> /z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language:
[jira] [Commented] (TS-3995) "[hcoofsr] conditional request, 200 response, send back 304 if possible [crc=304]" breaks akamaihd.net live streaming
[
https://issues.apache.org/jira/browse/TS-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001235#comment-15001235
]
ASF GitHub Bot commented on TS-3995:
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/330#discussion_r44595605
--- Diff: proxy/http/HttpTransactCache.cc ---
@@ -1299,7 +1299,7 @@
HttpTransactCache::match_response_to_request_conditionals(HTTPHdr *request, HTTP
ink_time_t lm_value = response->get_last_modified();
// we won't return NOT_MODIFIED if Last-modified is too recent
- if ((lm_value == 0) || (request->get_if_modified_since() <
lm_value)) {
--- End diff --
Another acceptable change would be to only allow this optimization if the
response is cacheable. In your use case the response from the origin is not
cacheable.
> "[hcoofsr] conditional request, 200 response, send back 304 if possible
> [crc=304]" breaks akamaihd.net live streaming
> -
>
> Key: TS-3995
> URL: https://issues.apache.org/jira/browse/TS-3995
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core, HTTP
>Affects Versions: 5.3.2
>Reporter: Nikolai Gorchilov
> Labels: review
> Fix For: 6.1.0
>
>
> Caching proxy running ATS 5.3.x (5.3.0, 5.3.1, 5.3.2 all fail) with
> proxy.config.http.cache.when_to_revalidate = 4 breaks akamaihd.net live
> streaming.
> The actual problem is that ATS rewrites origin response from 200 to 304, due
> to If-Modified-Since conditional header in client's request. As per ATS logic
> object is unmodified, but in fact it is. Most probably player and server
> somehow play with if-modified-since/last-modified headers pair to communicate
> position in the live stream. What is obvious is that Last-Modified =
> If-Modified-Since.
> As result, Akamai player keeps repeating the said request, expecting it's
> 200, but getting 304 thus live video freezes forever, just a few seconds
> after start.
> IMHO when proxy.config.http.cache.when_to_revalidate = 4, ATS shall not
> interfere with origin response in this manner.
> Here's a debug log of request and response headers at different states in a
> single transaction:
> {noformat}
> + Incoming Request +
> -- State Machine Id: 168
> GET
> http:///z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> Connection: keep-alive
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language: en-US,en;q=0.8,bg;q=0.6
> Cookie: _alid_=PmjLqgcUUqw6TP5gtK/xbg==;
> hdntl=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8
> If-Modified-Since: Thu, 05 Nov 2015 02:30:28 GMT
> + Proxy's Request +
> -- State Machine Id: 168
> GET
> /z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language: en-US,en;q=0.8,bg;q=0.6
> Cookie: _alid_=PmjLqgcUUqw6TP5gtK/xbg==;
> hdntl=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8
> If-Modified-Since: Thu, 05 Nov 2015 02:30:28 GMT
> + Proxy's Request after hooks +
> -- State Machine Id: 168
> GET
> /z/delayed/indvsa2015_INDVSSATEST1DAY1_1@336263/464_209823ecd2922291-p.bootstrap?g=YCEAMIWDQZQT=exp=1446809835~acl=%2f*~data=hdntl~hmac=ebaedb13781605ce7f9f26b84e1346a7d43ecf0dfcc99e6b53e32487565ba3f8=3.7.0=aasp-3.7.0.39.44
> HTTP/1.1
> Host: sshds5-lh.akamaihd.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
> X-Requested-With: ShockwaveFlash/19.0.0.226
> Accept: */*
> DNT: 1
> Referer: http://www.hotstar.com/
> Accept-Encoding: gzip
> Accept-Language: en-US,en;q=0.8,bg;q=0.6
> Cookie: _alid_=PmjLqgcUUqw6TP5gtK/xbg==;
>
