[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584980#comment-14584980
]
portl4t commented on TS-3282:
-
It looks good to me, I had test the plugin, it works!
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Phil Sorber
Fix For: 6.0.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493526#comment-14493526 ] portl4t commented on TS-1611: - Yeah, your're right. I'm fixing it. By the way, I have finished ts.cache_xxx on github, should we create another issue to handle it ? async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, 0002-TS-1611-add-ts_lua_constant.c.patch, 0003-TS-1611-refine-doc-for-ts_lua.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14493561#comment-14493561 ] portl4t commented on TS-1611: - Agree with Leif. [~kichan], I think you can commit the fix directly as you have the rights. async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, 0002-TS-1611-add-ts_lua_constant.c.patch, 0003-TS-1611-refine-doc-for-ts_lua.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14388264#comment-14388264 ] portl4t commented on TS-1611: - Awesome async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, 0002-TS-1611-add-ts_lua_constant.c.patch, 0003-TS-1611-refine-doc-for-ts_lua.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3469) Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR
[ https://issues.apache.org/jira/browse/TS-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386404#comment-14386404 ] portl4t commented on TS-3469: - How can it be? Can you provide details? I'd like to dig into it. Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR - Key: TS-3469 URL: https://issues.apache.org/jira/browse/TS-3469 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Scott Beardsley Assignee: Alan M. Carroll Fix For: sometime We ran into a problem where SEND_RESPONSE_HDR was being called multiple times leading to a crash. The docs are unclear on this point so we should update them to reflect this intermittent case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3473) add TSCacheVConnPRead and TSCacheVConnPReadCapable
[ https://issues.apache.org/jira/browse/TS-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387972#comment-14387972 ] portl4t commented on TS-3473: - OK, I will take a look at the api review process, thank you all ! add TSCacheVConnPRead and TSCacheVConnPReadCapable -- Key: TS-3473 URL: https://issues.apache.org/jira/browse/TS-3473 Project: Traffic Server Issue Type: New Feature Components: Cache, TS API Reporter: portl4t Labels: review Fix For: 6.0.0 I think we need this two api to read from cache with an offset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3473) add TSCacheVConnPRead and TSCacheVConnPReadCapable
[ https://issues.apache.org/jira/browse/TS-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-3473: Attachment: (was: 0001-TS-3473-add-TSCacheVConnPRead-and-TSCacheVConnPReadC.patch) add TSCacheVConnPRead and TSCacheVConnPReadCapable -- Key: TS-3473 URL: https://issues.apache.org/jira/browse/TS-3473 Project: Traffic Server Issue Type: New Feature Components: Cache, TS API Reporter: portl4t Labels: review Fix For: 6.0.0 I think we need this two api to read from cache with an offset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3473) add TSCacheVConnPRead and TSCacheVConnPReadCapable
portl4t created TS-3473: --- Summary: add TSCacheVConnPRead and TSCacheVConnPReadCapable Key: TS-3473 URL: https://issues.apache.org/jira/browse/TS-3473 Project: Traffic Server Issue Type: New Feature Components: Cache, TS API Reporter: portl4t I think we need this two api to read from cache with an offset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14385008#comment-14385008 ] portl4t commented on TS-1611: - 1. Well, I think it is ok to use TSError instead of ee, although I prefer to record error message in traffic.out with ee. 2. There is no backward incompatibility, old scripts also work. 3. ts.fetch is definitely non-block, it will invoke lua_yield to release cpu after launching the FetchSM, and will excute the next lua line with lua_resume after FetchSM finished. ts.sleep uses the same mechanism. 4. Streaming mode is hard to display in the script, I am working on ts.cache_read these days, which has the same problem. I think we can implement streaming mode with an option if it is necessary. async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, 0002-TS-1611-add-ts_lua_constant.c.patch, 0003-TS-1611-refine-doc-for-ts_lua.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370520#comment-14370520 ] portl4t edited comment on TS-1611 at 3/20/15 1:36 AM: -- patch provided, I will provide the related document revise later. was (Author: portl4t): code async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-1611: Attachment: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch code async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14348039#comment-14348039 ] portl4t commented on TS-1611: - Yeah, I'm doing this job these days, there will be some results come out this month. async http request in lua remap plugin -- Key: TS-1611 URL: https://issues.apache.org/jira/browse/TS-1611 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Luca Rea Assignee: Kit Chan Fix For: sometime Hi, can you add support for async http requests in lua remap plugin please? Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313426#comment-14313426
]
portl4t commented on TS-3282:
-
I guess there should be someone who need this feature to service the mp4 stream
on CDN. I had test this feature in our production environment. Of course
further testing is appreciated.
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Assignee: Leif Hedstrom
Fix For: 5.3.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3235) PluginVC crashed with unrecognized event
[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287412#comment-14287412
]
portl4t commented on TS-3235:
-
Actually, I am not familiar with your business, before you call the Intercept
api, a continuation will be created with a mutex, may be this mutex is the key
point, meanwhile, I never use customer's thread before, why do you have to use
customer's thread?
PluginVC crashed with unrecognized event
Key: TS-3235
URL: https://issues.apache.org/jira/browse/TS-3235
Project: Traffic Server
Issue Type: Bug
Components: CPP API, HTTP, Plugins
Reporter: kang li
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: pluginvc-crash.diff
We are using atscppapi to create Intercept plugin.
From the coredump , that seems Continuation of the InterceptPlugin was
already been destroyed.
{code}
#0 0x00375ac32925 in raise () from /lib64/libc.so.6
#1 0x00375ac34105 in abort () from /lib64/libc.so.6
#2 0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`,
ap=0x2b21f4913ad0) at ink_error.cc:65
#4 0x2b21eeae35ee in ink_fatal (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 call_event ==
core_lock_retry_event, file=0x76dd04 PluginVC.cc, line=203)
at ink_assert.cc:37
#6 0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at PluginVC.cc:203
#7 0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00755d26 in EThread::process_event (this=0x309b250,
e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
#9 0x0075610a in EThread::execute (this=0x309b250) at
UnixEThread.cc:239
#10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
#11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00375ace8b7d in clone () from /lib64/libc.so.6
(gdb) p sm_lock_retry_event
$13 = (Event *) 0x2b2496146e90
(gdb) p core_lock_retry_event
$14 = (Event *) 0x0
(gdb) p active_event
$15 = (Event *) 0x0
(gdb) p inactive_event
$16 = (Event *) 0x0
(gdb) p *(INKContInternal*)this-core_obj-connect_to
Cannot access memory at address 0x2b269cd46c10
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3235) PluginVC crashed with unrecognized event
[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14285654#comment-14285654
]
portl4t commented on TS-3235:
-
Well, I think there is no doubt that the continuation can not be shared by
serveral threads concurrently, some continuations are operating in the plugin
on the condition that their locks had been keeped by the ats working threads.
PluginVC crashed with unrecognized event
Key: TS-3235
URL: https://issues.apache.org/jira/browse/TS-3235
Project: Traffic Server
Issue Type: Bug
Components: CPP API, HTTP, Plugins
Reporter: kang li
Assignee: Brian Geffon
Fix For: 5.3.0
Attachments: pluginvc-crash.diff
We are using atscppapi to create Intercept plugin.
From the coredump , that seems Continuation of the InterceptPlugin was
already been destroyed.
{code}
#0 0x00375ac32925 in raise () from /lib64/libc.so.6
#1 0x00375ac34105 in abort () from /lib64/libc.so.6
#2 0x2b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b21eeae3525 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`,
ap=0x2b21f4913ad0) at ink_error.cc:65
#4 0x2b21eeae35ee in ink_fatal (return_code=1,
message_format=0x2b21eeaf08d8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b21eeae2160 in _ink_assert (expression=0x76ddb8 call_event ==
core_lock_retry_event, file=0x76dd04 PluginVC.cc, line=203)
at ink_assert.cc:37
#6 0x00530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at PluginVC.cc:203
#7 0x004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00755d26 in EThread::process_event (this=0x309b250,
e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
#9 0x0075610a in EThread::execute (this=0x309b250) at
UnixEThread.cc:239
#10 0x00755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
#11 0x2b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x00375ace8b7d in clone () from /lib64/libc.so.6
(gdb) p sm_lock_retry_event
$13 = (Event *) 0x2b2496146e90
(gdb) p core_lock_retry_event
$14 = (Event *) 0x0
(gdb) p active_event
$15 = (Event *) 0x0
(gdb) p inactive_event
$16 = (Event *) 0x0
(gdb) p *(INKContInternal*)this-core_obj-connect_to
Cannot access memory at address 0x2b269cd46c10
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3282:
Attachment: (was: 0001-mp4-streaming-plugin.patch)
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Fix For: 5.3.0
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3282:
Attachment: 0001-mp4-streaming-plugin.patch
refine the fomart
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Fix For: 5.3.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270756#comment-14270756
]
portl4t commented on TS-3282:
-
New patch has been attached.
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Fix For: 5.3.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270476#comment-14270476
]
portl4t commented on TS-3282:
-
OK, I will provide another patch later.
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Fix For: 5.3.0
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3282) mp4 streaming plugin
portl4t created TS-3282:
---
Summary: mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3282) mp4 streaming plugin
[
https://issues.apache.org/jira/browse/TS-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3282:
Attachment: 0001-mp4-streaming-plugin.patch
mp4 streaming plugin
Key: TS-3282
URL: https://issues.apache.org/jira/browse/TS-3282
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: portl4t
Attachments: 0001-mp4-streaming-plugin.patch
This module provides streaming media server support for MP4 files. User can
send a HTTP request to the server with `start` argument which is measured in
seconds, and the server will respond with the stream such that its start
position corresponds to the requested time, for example:
{code}
http://v.foo.com/dota2.mp4?start=290.12
{code}
This allows performing a random seeking at any time. We can use flash player,
vlc, mplayer, firefox or chrome to play the streaming media.
Now this module can be accessed from https://github.com/portl4t/ts-mp4, I'd
like to add this module to the master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3252) Don't chunk response body if transform_response_cl is valid
portl4t created TS-3252:
---
Summary: Don't chunk response body if transform_response_cl is
valid
Key: TS-3252
URL: https://issues.apache.org/jira/browse/TS-3252
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can be
done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the function
HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3253) Don't chunk response body if transform_response_cl is valid
portl4t created TS-3253:
---
Summary: Don't chunk response body if transform_response_cl is
valid
Key: TS-3253
URL: https://issues.apache.org/jira/browse/TS-3253
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can be
done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the function
HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-3253) Don't chunk response body if transform_response_cl is valid
[
https://issues.apache.org/jira/browse/TS-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t closed TS-3253.
---
Resolution: Duplicate
duplicated
Don't chunk response body if transform_response_cl is valid
---
Key: TS-3253
URL: https://issues.apache.org/jira/browse/TS-3253
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can
be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the
function HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3252) Don't chunk response body if transform_response_cl is valid
[
https://issues.apache.org/jira/browse/TS-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3252:
Attachment: 0001-TS-2352-Don-t-chunk-response-body-if-transform_respo.patch
Don't chunk response body if transform_response_cl is valid
---
Key: TS-3252
URL: https://issues.apache.org/jira/browse/TS-3252
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
Attachments:
0001-TS-2352-Don-t-chunk-response-body-if-transform_respo.patch
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can
be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the
function HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3252) Don't chunk response body if transform_response_cl is valid
[
https://issues.apache.org/jira/browse/TS-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3252:
Attachment: (was:
0001-TS-2352-Don-t-chunk-response-body-if-transform_respo.patch)
Don't chunk response body if transform_response_cl is valid
---
Key: TS-3252
URL: https://issues.apache.org/jira/browse/TS-3252
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can
be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the
function HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3252) Don't chunk response body if transform_response_cl is valid
[
https://issues.apache.org/jira/browse/TS-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3252:
Attachment: 0001-TS-3252-Don-t-chunk-response-body-if-transform_respo.patch
Don't chunk response body if transform_response_cl is valid
---
Key: TS-3252
URL: https://issues.apache.org/jira/browse/TS-3252
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
Attachments:
0001-TS-3252-Don-t-chunk-response-body-if-transform_respo.patch
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can
be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the
function HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3252) Don't chunk response body if transform_response_cl is valid
[
https://issues.apache.org/jira/browse/TS-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3252:
Description:
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can be
done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this in plugin:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the function
HttpTransact::handle_response_keep_alive_headers(...)
was:
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can be
done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this is
plugins:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(ytc-output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the function
HttpTransact::handle_response_keep_alive_headers(...)
Don't chunk response body if transform_response_cl is valid
---
Key: TS-3252
URL: https://issues.apache.org/jira/browse/TS-3252
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Reporter: portl4t
Labels: Review
Fix For: 5.3.0
Attachments:
0001-TS-3252-Don-t-chunk-response-body-if-transform_respo.patch
The way as I see, the client will get chunked response from ATS if the origin
server issues a chunked response to ATS.
I am wondering whether this can be changed if there is a transfrom plugin
exists and the transform can insure transform_response_cl is valid. This can
be done by TSVConnWrite(...) with a valid nbytes(not INT64_MAX) in transform
handler.
Here is an example, I want to response abcdefg in transform handler, no
matter what is received from upstream, and I can write code like this in
plugin:
{code}
static int transform_handler(...)
{
...
output.buffer = TSIOBufferCreate();
output.reader = TSIOBufferReaderAlloc(output.buffer);
output.vio = TSVConnWrite(output_conn, contp, output.reader,
sizeof(abcdefg)-1);
TSIOBufferWrite(output.buffer, abcdefg, sizeof(abcdefg)-1);
TSVIOReenable(output.vio);
...
}
{code}
However, the response body to the client will be chunked if ATS got chunked
response from origin server. Maybe we can change this by refining the
function HttpTransact::handle_response_keep_alive_headers(...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3225) Add more API support to ts_lua plugin
[ https://issues.apache.org/jira/browse/TS-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243987#comment-14243987 ] portl4t commented on TS-3225: - Good news, I'm also refining the transform mechanism, and I will provide a patch later. Add more API support to ts_lua plugin - Key: TS-3225 URL: https://issues.apache.org/jira/browse/TS-3225 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.3.0 I would like to add support for the following APIs in ts_lua plugin as well as updating the documentation timeout related APIs - tsapi void TSHttpTxnActiveTimeoutSet(TSHttpTxn txnp, int timeout); tsapi void TSHttpTxnConnectTimeoutSet(TSHttpTxn txnp, int timeout); tsapi void TSHttpTxnDNSTimeoutSet(TSHttpTxn txnp, int timeout); tsapi void TSHttpTxnNoActivityTimeoutSet(TSHttpTxn txnp, int timeout); base64 encoding/decoding APIs - tsapi TSReturnCode TSBase64Decode(const char *str, size_t str_len, unsigned char *dst, size_t dst_size, size_t *length); tsapi TSReturnCode TSBase64Encode(const char *str, size_t str_len, char *dst, size_t dst_size, size_t *length); Percent encoding/decoding APIs tsapi TSReturnCode TSStringPercentEncode(const char *str, int str_len, char *dst, size_t dst_size, size_t *length, const unsigned char *map); tsapi TSReturnCode TSStringPercentDecode(const char *str, size_t str_len, char *dst, size_t dst_size, size_t *length); mark/tos APIs tsapi TSReturnCode TSHttpTxnClientPacketMarkSet(TSHttpTxn txnp, int mark); tsapi TSReturnCode TSHttpTxnServerPacketMarkSet(TSHttpTxn txnp, int mark); tsapi TSReturnCode TSHttpTxnClientPacketTosSet(TSHttpTxn txnp, int tos); tsapi TSReturnCode TSHttpTxnServerPacketTosSet(TSHttpTxn txnp, int tos); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3224) ts_lua plugin coredump occasionally
[
https://issues.apache.org/jira/browse/TS-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14236858#comment-14236858
]
portl4t commented on TS-3224:
-
I'm afraid that is the problem of memory limits.
Try to use Lua instead of LuaJIT
ts_lua plugin coredump occasionally
---
Key: TS-3224
URL: https://issues.apache.org/jira/browse/TS-3224
Project: Traffic Server
Issue Type: Bug
Components: Lua, Plugins
Reporter: Kit Chan
Assignee: Kit Chan
Fix For: 5.3.0
Here is a sample stack trace
Program terminated with signal 11, Segmentation fault.
#0 lj_str_new (L=0x46d77d28, str=0x2aaab03fa980 /not\303\255cias/, '\\'
repeats 189 times..., lenx=value optimized out) at lj_str.c:107
107 lj_str.c: No such file or directory.
in lj_str.c
Starting GDB Here
=
#0 lj_str_new (L=0x46d77d28, str=0x2aaab03fa980 /not\303\255cias/, '\\'
repeats 189 times..., lenx=value optimized out) at lj_str.c:107
g = 0x42f173b8
s = value optimized out
o = value optimized out
len = value optimized out
a = 1953459759
b = value optimized out
h = value optimized out
#1 0x00574e7b in lua_pushlstring (L=0x46d77d28, str=value optimized
out, len=value optimized out) at lj_api.c:587
s = value optimized out
#2 0x2b39b76a97a4 in ts_lua_client_request_get_uri (L=0x46d77d28) at
trafficserver/plugins/experimental/ts_lua/ts_lua_client_request.c:476
uri = /not\303\255cias/, '\\' repeats 2036 times
path = value optimized out
path_len = 24653
uri_len = value optimized out
http_ctx = value optimized out
#3 0x005b54f8 in lj_BC_FUNCC ()
g_rec_config_contents_ht = 0x21d2c30
g_rec_config_fpath = 0x0
g_rec_config_contents_llq = 0x21cde90
g_rec_config_lock = {__data = {__lock = 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next =
0x0}}, __size = '\000' repeats 39 times, __align = 0}
#4 0x00574690 in lua_pcall (L=value optimized out, nargs=value
optimized out, nresults=value optimized out, errfunc=value optimized
out) at lj_api.c:1052
g = 0x42f173b8
oldh = 0 '\000'
ef = value optimized out
status = value optimized out
#5 0x2b39b76a8091 in globalHookHandler (contp=value optimized out,
event=TS_EVENT_HTTP_PRE_REMAP, edata=0x2aab084bf650) at
trafficserver/plugins/experimental/ts_lua/ts_lua.c:298
txnp = 0x2aab084bf650
bufp = 0x2aab084bfd58
hdr_loc = 0x2aaadc0ff098
url_loc = 0x2aaadc0ff318
ret = value optimized out
req_id = value optimized out
txn_contp = 0x19e3bf40
l = 0x46d77d28
main_ctx = 0x272afe0
http_ctx = 0x2aac98b912b0
conf = value optimized out
__FUNCTION__ = globalHookHandler
#6 0x005099a8 in INKContInternal::handle_event (this=0x26555b0,
event=60016, edata=0x2aab084bf650) at InkAPI.cc:999
No locals.
#7 0x004f4f18 in Continuation::handleEvent (this=0x26555b0,
event=60016, data=0x2aab084bf650) at
../iocore/eventsystem/I_Continuation.h:146
No locals.
#8 0x0050a1ef in APIHook::invoke (this=0x2656a40, event=60016,
edata=0x2aab084bf650) at InkAPI.cc:1218
No locals.
#9 0x005cbe69 in HttpSM::state_api_callout (this=0x2aab084bf650,
event=6, data=0x0) at HttpSM.cc:1364
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x2656a40
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#10 0x005cb896 in HttpSM::state_api_callback (this=0x2aab084bf650,
event=6, data=0x0) at HttpSM.cc:1257
__func__ = state_api_callback
#11 0x005150d6 in TSHttpTxnReenable (txnp=0x2aab084bf650,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
trylock = {m = {m_ptr = 0x2aabc020d470}, lock_acquired = true}
sm = 0x2aab084bf650
eth = 0x2dedb010
#12 0x2b39b729af2a in plugin_handler (contp=0x26556d0, event=value
optimized out, edata=0x2aab084bf650) at ssl_helper.cc:334
txnp = 0x2aab084bf650
#13 0x005099a8 in INKContInternal::handle_event (this=0x26556d0,
event=60016, edata=0x2aab084bf650) at InkAPI.cc:999
No locals.
#14 0x004f4f18 in Continuation::handleEvent (this=0x26556d0,
event=60016, data=0x2aab084bf650) at
../iocore/eventsystem/I_Continuation.h:146
No locals.
#15 0x0050a1ef in APIHook::invoke (this=0x2656ac0, event=60016,
edata=0x2aab084bf650) at InkAPI.cc:1218
No locals.
#16 0x005cbe69 in HttpSM::state_api_callout (this=0x2aab084bf650,
event=6, data=0x0) at HttpSM.cc:1364
plugin_lock = false
[jira] [Commented] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213831#comment-14213831
]
portl4t commented on TS-3198:
-
I just provide a method to solve this problem, and I think there will be better
ways.
Ignore useless MIMEFieldBlockImpl.
--
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 4.1.2, 4.2.0, 4.2.2, 5.0.0, 5.1.1
Reporter: portl4t
Assignee: Brian Geffon
Fix For: 5.2.0
Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header
in mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
[jira] [Created] (TS-3198) Ignore useless MIMEFieldBlockImpl.
portl4t created TS-3198:
---
Summary: Ignore useless MIMEFieldBlockImpl.
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: portl4t
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1) at
Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980, event=100,
data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100, vc=0x7fffe0015b60)
at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30, vc=0x7fffe0015b60,
thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io (this=0x7fffe0015b60,
nh=0x737cea30, lthread=0x737cb010) at UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header in
mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3198:
Attachment: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
Ignore useless MIMEFieldBlockImpl.
--
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: portl4t
Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header
in mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3198:
Affects Version/s: 3.2.5
4.1.2
4.2.0
Ignore useless MIMEFieldBlockImpl.
--
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 3.2.5, 4.1.2, 4.2.0, 4.2.2, 5.0.0, 5.1.1
Reporter: portl4t
Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header
in mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3198:
Affects Version/s: 4.2.2
5.0.0
5.1.1
Ignore useless MIMEFieldBlockImpl.
--
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 3.2.5, 4.1.2, 4.2.0, 4.2.2, 5.0.0, 5.1.1
Reporter: portl4t
Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header
in mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3198:
Affects Version/s: (was: 3.2.5)
Ignore useless MIMEFieldBlockImpl.
--
Key: TS-3198
URL: https://issues.apache.org/jira/browse/TS-3198
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 4.1.2, 4.2.0, 4.2.2, 5.0.0, 5.1.1
Reporter: portl4t
Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
ATS will generate a very large marshal header in a rare case. As we know, ATS
will merge the response header if it get 304 from origin server. I found that
the HdrHeap size will increase if duplidated header exist.
In our production environment, we got a response from origin server like this:
{code}
HTTP/1.1 200 OK
Content-Length: 60
...
Powered-By-CC: MISS from A
Cache-Control: public,max-age=0
Powered-By-CC: MISS from B
Connection: close
{code}
There is a duplicated header 'Powered-By-CC', and every time the doc had been
accessed, ATS had to revalidate this doc from the origin as the max-age is 0.
The origin server response 304 like this:
{code}
HTTP/1.1 304 Not Modified
...
Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
Cache-Control: public,max-age=0
Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
Connection: close
{code}
ATS will merge the header frequently, and the HdrHeap size will increase
endlessly.
{code}
Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
132 header_len = write_vector-marshal_length();
(gdb) n
133 od-writing_vec = 1;
(gdb) p header_len
$1 = 1068944
(gdb) bt
#0 CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
#1 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) at Main.cc:1763
{code}
In HttpTransact::merge_response_header_with_cached_header(...), ATS will set
the old MIMEField as DELETED if it is duplicated, and attach new MIMEField,
this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may
increase to larger than 1M.
I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header
in mime_hdr_copy_onto(...).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3060) Attempt to send back a HTTP status code (e.g 408) upon a transaction activity timeout from the client
[ https://issues.apache.org/jira/browse/TS-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166645#comment-14166645 ] portl4t commented on TS-3060: - [~jamespeach] I just suggest to close the connection when acivity timeout exists. :) Attempt to send back a HTTP status code (e.g 408) upon a transaction activity timeout from the client - Key: TS-3060 URL: https://issues.apache.org/jira/browse/TS-3060 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Affects Versions: 4.0.2 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Labels: yahoo Fix For: 5.2.0 Attachments: TS-3060.diff This bug is similar to TS-3054, but, on the client connection. Currently, when ATS sees a transaction activity timeout on the client connection, it just closes the connection and releases the resources. As long as the socket is still active, it might be better to attempt sending back a HTTP status code to the client. For example, the use case might be a client sending a POST request with content-length, but doesn't send the body. ATS times out and aborts the connection without notifying the client. Even though, the inactivity timeout might indicate that the client connection is dead, it's possible that the body that the client sent was lost somewhere on the network before reaching ATS. It's possible that the status code response may never make it to the client for the same reasons, but, nevertheless, it's worth to give it a try. Some things to keep in mind are if the response headers have already been sent to the client, sending a status code is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3060) Attempt to send back a HTTP status code (e.g 408) upon a transaction activity timeout from the client
[ https://issues.apache.org/jira/browse/TS-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166645#comment-14166645 ] portl4t edited comment on TS-3060 at 10/10/14 11:19 AM: [~jamespeach] I just suggest to close the connection when acivity timeout exists by default. :) was (Author: portl4t): [~jamespeach] I just suggest to close the connection when acivity timeout exists. :) Attempt to send back a HTTP status code (e.g 408) upon a transaction activity timeout from the client - Key: TS-3060 URL: https://issues.apache.org/jira/browse/TS-3060 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Affects Versions: 4.0.2 Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Labels: yahoo Fix For: 5.2.0 Attachments: TS-3060.diff This bug is similar to TS-3054, but, on the client connection. Currently, when ATS sees a transaction activity timeout on the client connection, it just closes the connection and releases the resources. As long as the socket is still active, it might be better to attempt sending back a HTTP status code to the client. For example, the use case might be a client sending a POST request with content-length, but doesn't send the body. ATS times out and aborts the connection without notifying the client. Even though, the inactivity timeout might indicate that the client connection is dead, it's possible that the body that the client sent was lost somewhere on the network before reaching ATS. It's possible that the status code response may never make it to the client for the same reasons, but, nevertheless, it's worth to give it a try. Some things to keep in mind are if the response headers have already been sent to the client, sending a status code is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3101) Add TSHttpHdrHostGet
[ https://issues.apache.org/jira/browse/TS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151320#comment-14151320 ] portl4t commented on TS-3101: - I think TSHttpHdrPortGet is also needed. Add TSHttpHdrHostGet Key: TS-3101 URL: https://issues.apache.org/jira/browse/TS-3101 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Fix For: 5.2.0 Plugins should be able to get the host directly from the HTTP header and not do the URL vs. entity field logic every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3065) Delete the header Transfer-Encoding when the error body was set
portl4t created TS-3065: --- Summary: Delete the header Transfer-Encoding when the error body was set Key: TS-3065 URL: https://issues.apache.org/jira/browse/TS-3065 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: portl4t TSHttpTxnErrorBodySet(...) will usually be called in the plugin to set the body of the client response when error exists, but sometimes the header Transfer-Encoding will be inserted into the client response(from handle_response_keep_alive_headers(...)), and we should delete this header to indicate that the body was not chunked. = HTTP/1.1 500 INKApi Error Date: Sun, 07 Sep 2014 10:03:31 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 0 ^C HTTP/1.1 404 Not Found Date: Sun, 07 Sep 2014 10:01:35 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 12 Content-Type: text/html ^C -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3065) Delete the header Transfer-Encoding when the error body was set
[ https://issues.apache.org/jira/browse/TS-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-3065: Attachment: 0001-TS-3065-Delete-the-header-Transfer-Encoding-when-the.patch Delete the header Transfer-Encoding when the error body was set - Key: TS-3065 URL: https://issues.apache.org/jira/browse/TS-3065 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: portl4t Attachments: 0001-TS-3065-Delete-the-header-Transfer-Encoding-when-the.patch TSHttpTxnErrorBodySet(...) will usually be called in the plugin to set the body of the client response when error exists, but sometimes the header Transfer-Encoding will be inserted into the client response(from handle_response_keep_alive_headers(...)), and we should delete this header to indicate that the body was not chunked. = HTTP/1.1 500 INKApi Error Date: Sun, 07 Sep 2014 10:03:31 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 0 ^C HTTP/1.1 404 Not Found Date: Sun, 07 Sep 2014 10:01:35 GMT Transfer-Encoding: chunked Connection: keep-alive Server: ATS/5.2.0 Content-Length: 12 Content-Type: text/html ^C -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096475#comment-14096475 ] portl4t commented on TS-1381: - How many bytes do you send in the server intercept ? I use server intercept in combo plugin under our product environment. Performance of server intercept without Content-Length is poor -- Key: TS-1381 URL: https://issues.apache.org/jira/browse/TS-1381 Project: Traffic Server Issue Type: Improvement Components: HTTP, Performance Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 6.0.0 When using a server intercept plugin, if the plugin is unable (for whatever reason) to inject a Content-Length header, we perform chunked encoding on the body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown doing this chunking, vs simply setting a CL: header. The reason I'm filing this is because for certain server intercept plugins, such as an fcgi plugin, this could be bad for performance. I can see that there would be some overhead doing the chunking, but 800% seems very steep. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2953) GET Host header in reverse proxy setup
[
https://issues.apache.org/jira/browse/TS-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072956#comment-14072956
]
portl4t commented on TS-2953:
-
TSHttpTxnEffectiveUrlStringGet(...) is a function which can be used to get the
whole url, you can see this function in proxy/InkAPI.cc, and there may be
other plugins which had used this function.
GET Host header in reverse proxy setup
--
Key: TS-2953
URL: https://issues.apache.org/jira/browse/TS-2953
Project: Traffic Server
Issue Type: Bug
Components: Core, CPP API, Logging
Affects Versions: 4.2.1
Reporter: Vasile Bogdan Raica
Labels: API
Hello, been trying this for 3 days, I think this is a bug. See bellow code,
this has been tested on TS_HTTP_PRE_REMAP_HOOK and
TS_HTTP_READ_REQUEST_HDR_HOOK. Also the example for blacklist, which uses the
same thing, also fails.
Same goes with getting the URL string, it will remove the hostname and leave
the requested part, eg.
http:///somefile.php
(there are 3 slashes there).
I've been using ATS for about 3 days (yes short time) and trying to make a
plugin for it and I can't seem to get what I want ... I may be missing
something, and if so, I apologize for taking your time to read this and if
possible, kindly show me the right way to do this if possible.
static void
handle_request(TSHttpTxn txnp, TSCont contp) {
TSMBuffer bufp; // TSMBuffer
TSMLoc hdr_loc; // TSMLoc offset
TSMLoc url_loc; // TSMLoc locp
const char *host;
int host_length;
// getting client request
errorCode = TSHttpTxnClientReqGet (txnp, bufp, hdr_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve client request header\n);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading client request...);
}
// getting client requested url
errorCode = TSHttpHdrUrlGet (bufp, hdr_loc, url_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve request url\n);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading url_loc request...);
}
// getting host
host = TSUrlHostGet (bufp, url_loc, host_length);
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
if (!host) {
TSError (couldn't retrieve request host header \n);
TSHandleMLocRelease (bufp, hdr_loc, url_loc);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
}
done:
TSTextLogObjectWrite(logFile, Allowing http event to continue ...);
TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2953) GET Host header in reverse proxy setup
[
https://issues.apache.org/jira/browse/TS-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072715#comment-14072715
]
portl4t commented on TS-2953:
-
You can try to get the url with TSHttpTxnEffectiveUrlStringGet(...) first.
GET Host header in reverse proxy setup
--
Key: TS-2953
URL: https://issues.apache.org/jira/browse/TS-2953
Project: Traffic Server
Issue Type: Bug
Components: Core, CPP API, Logging
Affects Versions: 4.2.1
Reporter: Vasile Bogdan Raica
Labels: API
Hello, been trying this for 3 days, I think this is a bug. See bellow code,
this has been tested on TS_HTTP_PRE_REMAP_HOOK and
TS_HTTP_READ_REQUEST_HDR_HOOK. Also the example for blacklist, which uses the
same thing, also fails.
Same goes with getting the URL string, it will remove the hostname and leave
the requested part, eg.
http:///somefile.php
(there are 3 slashes there).
I've been using ATS for about 3 days (yes short time) and trying to make a
plugin for it and I can't seem to get what I want ... I may be missing
something, and if so, I apologize for taking your time to read this and if
possible, kindly show me the right way to do this if possible.
static void
handle_request(TSHttpTxn txnp, TSCont contp) {
TSMBuffer bufp; // TSMBuffer
TSMLoc hdr_loc; // TSMLoc offset
TSMLoc url_loc; // TSMLoc locp
const char *host;
int host_length;
// getting client request
errorCode = TSHttpTxnClientReqGet (txnp, bufp, hdr_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve client request header\n);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading client request...);
}
// getting client requested url
errorCode = TSHttpHdrUrlGet (bufp, hdr_loc, url_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve request url\n);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading url_loc request...);
}
// getting host
host = TSUrlHostGet (bufp, url_loc, host_length);
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
if (!host) {
TSError (couldn't retrieve request host header \n);
TSHandleMLocRelease (bufp, hdr_loc, url_loc);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
}
done:
TSTextLogObjectWrite(logFile, Allowing http event to continue ...);
TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2947) Make the setting proxy.config.http.global_user_agent_header overrideable per remap
[ https://issues.apache.org/jira/browse/TS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2947: Summary: Make the setting proxy.config.http.global_user_agent_header overrideable per remap (was: Make the setting proxy.config.http.global_user_agent_header over rideable per remap) Make the setting proxy.config.http.global_user_agent_header overrideable per remap -- Key: TS-2947 URL: https://issues.apache.org/jira/browse/TS-2947 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Labels: review Fix For: 5.1.0 Attachments: TS-2947.diff There's a requirement among some of our origins to see custom and different user_agent headers. This ticket adds the setting proxy.config.http.global_user_agent_header to the list of overrideable params. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2930) Missing hostname in ts.client_request.get_url()
[
https://issues.apache.org/jira/browse/TS-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060047#comment-14060047
]
portl4t commented on TS-2930:
-
The way as I see, the whole url always comes from m_url_cached.m_url_impl, but
the two members 'm_ptr_host' and 'm_ptr_port' can only be set in
setup_for_remap or in TSHttpTxnEffectiveUrlStringGet [UrlPrintHack(...)], and
then both get_url() and get_url_host() can work well, may be we should ensure
the two members had been set before we get the whole url or host.
Missing hostname in ts.client_request.get_url()
---
Key: TS-2930
URL: https://issues.apache.org/jira/browse/TS-2930
Project: Traffic Server
Issue Type: Bug
Components: Lua, Plugins, TS API
Affects Versions: 5.0.0
Reporter: Nikolai Gorchilov
Assignee: Kit Chan
Fix For: 5.1.0
In Linux TPROXY forwarding mode ts.client_request.get_uri() omits hostname
from the returned url - responds with http:///pathname?parameters; instead
of http://hostname/pathname?parameters;. This happens in the context of
early state hooks up to and including TS_HTTP_POST_REMAP_HOOK.
In case of cacheurl.so rewrite on the URL, hostname reamains empty even after
post_remap.
Here're the steps to reproduce the problem - a global lua plugin
(plugins.config):
==[cut]==
function do_global_txn_start()
print('==[cut]==')
print ('do_global_txt_start: ' .. ts.client_request.get_url())
end
function do_global_txn_close()
print ('do_global_txn_close: ' .. ts.client_request.get_url())
print('==[cut]==')
end
function do_global_os_dns()
print ('do_global_os_dns: ' .. ts.client_request.get_url())
end
function do_global_pre_remap()
print ('do_global_pre_remap: ' .. ts.client_request.get_url())
end
function do_global_post_remap()
print ('do_global_post_remap: ' .. ts.client_request.get_url())
end
function do_global_read_request()
print ('do_global_read_request: ' .. ts.client_request.get_url())
end
function do_global_send_request()
print ('do_global_send_request: ' .. ts.client_request.get_url())
end
function do_global_read_response()
print ('do_global_read_response: ' .. ts.client_request.get_url())
end
function do_global_send_response()
print ('do_global_send_response: ' .. ts.client_request.get_url())
end
function do_global_cache_lookup_complete()
print ('do_global_cache_lookup_complete: ' ..
ts.client_request.get_url())
end
function do_global_read_cache()
print ('do_global_read_cache: ' .. ts.client_request.get_url())
end
Requesting same URL -
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png - in 4
different scenarios:
1. empty cache (MISS) without cacheurl.so activated
2. HIT request without cacheurl.so activated
3. empty cache (MISS) with cacheurl.so activated
4. HIT request with cacheurl.so activated
cacheurl.config consists the following:
^http://[^\/]*(yimg\.com)/(.*)http://$1.internal/$2
Here's my traffic.out output:
1. MISS without cacheurl.so
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
2. HIT without cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_cache:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
3. MISS with
[jira] [Commented] (TS-2930) Missing hostname in ts.client_request.get_url()
[
https://issues.apache.org/jira/browse/TS-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059622#comment-14059622
]
portl4t commented on TS-2930:
-
I think we should retrieve the client_request's url with
TSHttpTxnEffectiveUrlStringGet(...) before PRE_REMAP. By the way, I can get the
whole url from POST_REMAP.
Missing hostname in ts.client_request.get_url()
---
Key: TS-2930
URL: https://issues.apache.org/jira/browse/TS-2930
Project: Traffic Server
Issue Type: Bug
Components: Lua, Plugins, TS API
Affects Versions: 5.0.0
Reporter: Nikolai Gorchilov
Assignee: Kit Chan
In Linux TPROXY forwarding mode ts.client_request.get_uri() omits hostname
from the returned url - responds with http:///pathname?parameters; instead
of http://hostname/pathname?parameters;. This happens in the context of
early state hooks up to and including TS_HTTP_POST_REMAP_HOOK.
In case of cacheurl.so rewrite on the URL, hostname reamains empty even after
post_remap.
Here're the steps to reproduce the problem - a global lua plugin
(plugins.config):
==[cut]==
function do_global_txn_start()
print('==[cut]==')
print ('do_global_txt_start: ' .. ts.client_request.get_url())
end
function do_global_txn_close()
print ('do_global_txn_close: ' .. ts.client_request.get_url())
print('==[cut]==')
end
function do_global_os_dns()
print ('do_global_os_dns: ' .. ts.client_request.get_url())
end
function do_global_pre_remap()
print ('do_global_pre_remap: ' .. ts.client_request.get_url())
end
function do_global_post_remap()
print ('do_global_post_remap: ' .. ts.client_request.get_url())
end
function do_global_read_request()
print ('do_global_read_request: ' .. ts.client_request.get_url())
end
function do_global_send_request()
print ('do_global_send_request: ' .. ts.client_request.get_url())
end
function do_global_read_response()
print ('do_global_read_response: ' .. ts.client_request.get_url())
end
function do_global_send_response()
print ('do_global_send_response: ' .. ts.client_request.get_url())
end
function do_global_cache_lookup_complete()
print ('do_global_cache_lookup_complete: ' ..
ts.client_request.get_url())
end
function do_global_read_cache()
print ('do_global_read_cache: ' .. ts.client_request.get_url())
end
Requesting same URL -
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png - in 4
different scenarios:
1. empty cache (MISS) without cacheurl.so activated
2. HIT request without cacheurl.so activated
3. empty cache (MISS) with cacheurl.so activated
4. HIT request with cacheurl.so activated
cacheurl.config consists the following:
^http://[^\/]*(yimg\.com)/(.*)http://$1.internal/$2
Here's my traffic.out output:
1. MISS without cacheurl.so
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
2. HIT without cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_cache:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
3. MISS with cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
http:///os/mit/media/m/base/images/transparent-1093278.png
[jira] [Commented] (TS-2910) TCP/IP Protocols defined in Lua
[ https://issues.apache.org/jira/browse/TS-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14051026#comment-14051026 ] portl4t commented on TS-2910: - That's a good suggestion, we may think about this later. TCP/IP Protocols defined in Lua --- Key: TS-2910 URL: https://issues.apache.org/jira/browse/TS-2910 Project: Traffic Server Issue Type: Improvement Components: Lua Reporter: Luca Rea Assignee: Kit Chan Request feature to add support for adding new TCP protocols in lua -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2900) TSHttpConnect response includes chunk sizes
[ https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045470#comment-14045470 ] portl4t commented on TS-2900: - Fact, your plugin act as a browser, so chunked response should be processed in your plugin not matter what version the ATS is. I think your can use FetchSM to implement your business. 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 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.2#6252)
[jira] [Commented] (TS-2825) Segmentation fault on POST request transformation
[
https://issues.apache.org/jira/browse/TS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037003#comment-14037003
]
portl4t commented on TS-2825:
-
I found that ATS does not support chunked post request transformation well,
which has been described in HttpSM::state_request_wait_for_transform_read(...):
...
else {
// No content length from the post. This is a no go
// since http spec requires content length when
// sending a request message body. Change the event
// to an error and fall through
event = VC_EVENT_ERROR;
Log::error(Request transformation failed to set content length);
}
As the VC_EVENT_ERROR event arise, the tunnel will be killed, then the
producer UA will invoke do_io_close which cause client_vc will be set to NULL,
after that ATS will try to send error response to UA, so it will crash.
Should we just fix the crash or refine chunked post transformation?
Segmentation fault on POST request transformation
-
Key: TS-2825
URL: https://issues.apache.org/jira/browse/TS-2825
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, Lua, Plugins, TS API
Reporter: Pasquale Puzio
Assignee: Kit Chan
Priority: Critical
Fix For: sometime
I'm trying to write a simple encryption/decryption plugin for Apache Traffic
Server. The plugin should transform requests/responses in order to
encrypt/decrypt them. I decided to write the plugin in LUA (using the ts-lua
plugin available here https://github.com/portl4t/ts-lua)
function encrypt(data, eos)
if (data == '') then
return data, eos
end
if (eos == 1) then
ts.debug('End of Stream')
end
return data, eos
end
function do_remap()
ts.debug('do_remap')
if (ts.client_request.get_method() == 'POST') then
ts.hook(TS_LUA_REQUEST_TRANSFORM, encrypt)
end
ts.http.resp_cache_transformed(0)
ts.http.resp_cache_untransformed(0)
return 0
end
Everything works fine for GET and DELETE requests, but when I send a POST
chunked-encoded request, ATS crashes almost every time.
if I don't activate the request transformation hook, the chunked request is
forwarded perfectly. Most of the time, if one request is forwarded
succesfully, the one after crashes.
Here is the stack trace:
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
NOTE: Traffic Server received Sig 11: Segmentation fault
bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f045cd29cb0]
bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x171)[0x5c274f]
bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x883)[0x5c24cf]
bin/traffic_server(_ZN6HttpSM23do_api_callout_internalEv+0x1b7)[0x5ceaef]
bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x26)[0x5dc18e]
bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x12f9)[0x5d6a19]
bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ba)[0x5d5718]
bin/traffic_server(_ZN6HttpSM36state_common_wait_for_transform_readEP17HttpTransformInfoMS_FiiPvEiS2_+0x39b)[0x5c1a11]
bin/traffic_server(_ZN6HttpSM37state_request_wait_for_transform_readEiPv+0x1e1)[0x5c1483]
bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x333)[0x5c5eeb]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x2f6)[0x538d2a]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x7537e2]
bin/traffic_server(_ZN7EThread7executeEv+0xc9)[0x753a27]
bin/traffic_server[0x752ca7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f045cd21e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f045c0383fd]
Segmentation fault (core dumped)
I've already tried to use one of the example plugins for request
transformation and I still have the same problem. The only way to make the
problem disappear is to avoid request transformation.
Is there something wrong in the way I'm transforming requests? What does this
segmentation fault depend on?
Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2825) Segmentation fault on POST request transformation
[
https://issues.apache.org/jira/browse/TS-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14037003#comment-14037003
]
portl4t edited comment on TS-2825 at 6/19/14 6:08 AM:
--
I found that ATS does not support chunked post request transformation well,
which has been described in HttpSM::state_request_wait_for_transform_read(...):
{code}
...
} else {
// No content length from the post. This is a no go
// since http spec requires content length when
// sending a request message body. Change the event
// to an error and fall through
event = VC_EVENT_ERROR;
Log::error(Request transformation failed to set content length);
}
// FALLTHROUGH
default:
state_common_wait_for_transform_read(post_transform_info,
HttpSM::tunnel_handler_post, event, data);
break;
}
{code}
As the VC_EVENT_ERROR event arise, the tunnel will be killed, then the
producer UA will invoke do_io_close which cause client_vc will be set to NULL,
after that ATS will try to send error response to UA, so it will crash.
Should we just fix the crash or refine chunked post transformation?
was (Author: portl4t):
I found that ATS does not support chunked post request transformation well,
which has been described in HttpSM::state_request_wait_for_transform_read(...):
...
else {
// No content length from the post. This is a no go
// since http spec requires content length when
// sending a request message body. Change the event
// to an error and fall through
event = VC_EVENT_ERROR;
Log::error(Request transformation failed to set content length);
}
As the VC_EVENT_ERROR event arise, the tunnel will be killed, then the
producer UA will invoke do_io_close which cause client_vc will be set to NULL,
after that ATS will try to send error response to UA, so it will crash.
Should we just fix the crash or refine chunked post transformation?
Segmentation fault on POST request transformation
-
Key: TS-2825
URL: https://issues.apache.org/jira/browse/TS-2825
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, Lua, Plugins, TS API
Reporter: Pasquale Puzio
Assignee: Kit Chan
Priority: Critical
Fix For: sometime
I'm trying to write a simple encryption/decryption plugin for Apache Traffic
Server. The plugin should transform requests/responses in order to
encrypt/decrypt them. I decided to write the plugin in LUA (using the ts-lua
plugin available here https://github.com/portl4t/ts-lua)
function encrypt(data, eos)
if (data == '') then
return data, eos
end
if (eos == 1) then
ts.debug('End of Stream')
end
return data, eos
end
function do_remap()
ts.debug('do_remap')
if (ts.client_request.get_method() == 'POST') then
ts.hook(TS_LUA_REQUEST_TRANSFORM, encrypt)
end
ts.http.resp_cache_transformed(0)
ts.http.resp_cache_untransformed(0)
return 0
end
Everything works fine for GET and DELETE requests, but when I send a POST
chunked-encoded request, ATS crashes almost every time.
if I don't activate the request transformation hook, the chunked request is
forwarded perfectly. Most of the time, if one request is forwarded
succesfully, the one after crashes.
Here is the stack trace:
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[May 20 13:16:28.105] Server {0x7f045a1c1700} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
NOTE: Traffic Server received Sig 11: Segmentation fault
bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f045cd29cb0]
bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x171)[0x5c274f]
bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x883)[0x5c24cf]
bin/traffic_server(_ZN6HttpSM23do_api_callout_internalEv+0x1b7)[0x5ceaef]
bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x26)[0x5dc18e]
bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x12f9)[0x5d6a19]
bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ba)[0x5d5718]
bin/traffic_server(_ZN6HttpSM36state_common_wait_for_transform_readEP17HttpTransformInfoMS_FiiPvEiS2_+0x39b)[0x5c1a11]
bin/traffic_server(_ZN6HttpSM37state_request_wait_for_transform_readEiPv+0x1e1)[0x5c1483]
bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x333)[0x5c5eeb]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x2f6)[0x538d2a]
bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4f06b2]
bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x11e)[0x7537e2]
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004507#comment-14004507 ] portl4t commented on TS-2723: - I think we can ignore `ts.shared.DICT` to get other features in 5.0.0 release, and we may refine ts.shared.DICT later. I also agree to reuse ts api for doing base64 encoding and uri encoding. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2723: Attachment: 0002-TS-2723-add-new-features-for-ts_lua.patch I remove some features out, including: ts.shared.DICT ts.re.match (relys on ts.shared.DICT) ts.base64_encoding ts.base64_decoding ts.escape_uri ts.unescape_uri ts.http.redirect (remove http_ctx-rri) We can refine base64 encoding and uri encoding later. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch, 0002-TS-2723-add-new-features-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000812#comment-14000812 ] portl4t commented on TS-2723: - I agree to get rid of TCL, and we should use other ways to implement ts.shared.DICT. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2723: Attachment: 0001-TS-2723-refine-doc-for-ts_lua.patch refine doc for ts_lua Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, 0001-TS-2723-refine-doc-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988616#comment-13988616 ] portl4t commented on TS-2723: - Ok, I will try to provide the documentation later. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986478#comment-13986478 ] portl4t commented on TS-2723: - Kit Chan, can I provide a patch which base on the current code ? Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2723: Attachment: 0001-TS-2723-add-new-features-for-ts_lua.patch add new features Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan Fix For: 5.0.0 Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2723) Add new features for ts_lua.
portl4t created TS-2723: --- Summary: Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970606#comment-13970606 ] portl4t commented on TS-2723: - I will provide a patch next week. Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t Assignee: Kit Chan After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963938#comment-13963938 ] portl4t commented on TS-2555: - OK, I will provide a patch later. Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963709#comment-13963709 ] portl4t commented on TS-2555: - Hi, all. I had add many features to ts-lua on https://github.com/portl4t/ts-lua. I don't know whether I should add these features to experimental/ts_lua. What's the progress of this issue now? Move existing lua plugin to plugins/deprecated and rename ts_lua to lua --- Key: TS-2555 URL: https://issues.apache.org/jira/browse/TS-2555 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 5.0.0 As suggested by Igor Galic in TS-2335, to avoid namespace pollution, we could move move the old Lua plugin to plugins/deprecated, and name this one lua again from the start. From what I gather, the consensus on the mailing list was to replace the old plugin with this one. Given that the old plugin was experimental, and we've decided that all bets regarding compatibility and stability are off in experimental, I'm fairly certain we can just do that. I'd move it, for easy reference into plugins/deprecated, remove it from the build, and once the new plugin has absorbed all of its features, remove it all together. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2603) Do not update hostdb if intercept exists
portl4t created TS-2603: --- Summary: Do not update hostdb if intercept exists Key: TS-2603 URL: https://issues.apache.org/jira/browse/TS-2603 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: portl4t We should not update hostdb if a HttpSM was intercepted, as the HttpSM did not really connect to the origin server. Otherwise we may set the hostdb address to zero if timeout occurs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2603) Do not update hostdb if intercept exists
[ https://issues.apache.org/jira/browse/TS-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2603: Attachment: 0001-TS-2603-Do-not-update-hostdb-if-intercept-exists.patch provide patch Do not update hostdb if intercept exists Key: TS-2603 URL: https://issues.apache.org/jira/browse/TS-2603 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: portl4t Attachments: 0001-TS-2603-Do-not-update-hostdb-if-intercept-exists.patch We should not update hostdb if a HttpSM was intercepted, as the HttpSM did not really connect to the origin server. Otherwise we may set the hostdb address to zero if timeout occurs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2541) Add WebSocket support
[ https://issues.apache.org/jira/browse/TS-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13907983#comment-13907983 ] portl4t commented on TS-2541: - I had test it with intercept plugin, it works. :) Add WebSocket support - Key: TS-2541 URL: https://issues.apache.org/jira/browse/TS-2541 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 4.2.0 Attachments: ws.patch, ws.patch Add WebSocket Support in TrafficServer. websocket is enabled on a remap basis, you will setup a websocket mapping by specifying the ws:// or wss:// schemes, for example add the following to remap.config: map ws://127.0.0.1:8080/foo ws://127.0.0.1:9090/ Next, the current number of websocket connections can be monitored via the stats variable proxy.process.http.websocket.current_active_client_connections Community feedback would be appreciated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2335) Putting Alibaba Lua plugin into /experimental
[ https://issues.apache.org/jira/browse/TS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2335: Attachment: ts-lua.patch attach patch Putting Alibaba Lua plugin into /experimental - Key: TS-2335 URL: https://issues.apache.org/jira/browse/TS-2335 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Kit Chan Attachments: ts-lua.patch There is an awesome plugin created by Alibaba engineer - portl4t https://github.com/portl4t/ts-lua/ There is a mail thread on dev mailing list and the author agrees to put it to ATS source as well. So I would like to start things off with filing a jira first. I think it would be nice to put it into /experimental/ to start things first. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2335) Putting Alibaba Lua plugin into /experimental
[ https://issues.apache.org/jira/browse/TS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821175#comment-13821175 ] portl4t commented on TS-2335: - 1. I tested the performance of ts-lua with 'header rewrite' case, and ts-lua performs well, but I suggest you test it yourself with your own case and make a comparison. 2. A lua context can be used by multiple client requests with lock protected, and HttpSM won't be blocked by ts-lua, I suggest TS_LUA_MAX_STATE_COUNT to be 2048 or more. Putting Alibaba Lua plugin into /experimental - Key: TS-2335 URL: https://issues.apache.org/jira/browse/TS-2335 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Kit Chan There is an awesome plugin created by Alibaba engineer - portl4t https://github.com/portl4t/ts-lua/ There is a mail thread on dev mailing list and the author agrees to put it to ATS source as well. So I would like to start things off with filing a jira first. I think it would be nice to put it into /experimental/ to start things first. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2335) Putting Alibaba Lua plugin into /experimental
[ https://issues.apache.org/jira/browse/TS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818404#comment-13818404 ] portl4t commented on TS-2335: - good news Putting Alibaba Lua plugin into /experimental - Key: TS-2335 URL: https://issues.apache.org/jira/browse/TS-2335 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Kit Chan There is an awesome plugin created by Alibaba engineer - portl4t https://github.com/portl4t/ts-lua/ There is a mail thread on dev mailing list and the author agrees to put it to ATS source as well. So I would like to start things off with filing a jira first. I think it would be nice to put it into /experimental/ to start things first. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (TS-2335) Putting Alibaba Lua plugin into /experimental
[ https://issues.apache.org/jira/browse/TS-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818404#comment-13818404 ] portl4t edited comment on TS-2335 at 11/10/13 8:43 AM: --- Good news, and I will provide a patch later. was (Author: portl4t): good news Putting Alibaba Lua plugin into /experimental - Key: TS-2335 URL: https://issues.apache.org/jira/browse/TS-2335 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Kit Chan There is an awesome plugin created by Alibaba engineer - portl4t https://github.com/portl4t/ts-lua/ There is a mail thread on dev mailing list and the author agrees to put it to ATS source as well. So I would like to start things off with filing a jira first. I think it would be nice to put it into /experimental/ to start things first. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2317) read/write mutex of PluginVC may be held without release
portl4t created TS-2317: --- Summary: read/write mutex of PluginVC may be held without release Key: TS-2317 URL: https://issues.apache.org/jira/browse/TS-2317 Project: Traffic Server Issue Type: Bug Components: Core Reporter: portl4t read/write mutex of PluginVC may be held without release which will cause PluginVC hang -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2317) read/write mutex of PluginVC may be held without release
[ https://issues.apache.org/jira/browse/TS-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2317: Attachment: pluginvc.patch unlock read_side_mutex write_side_mutex if held read/write mutex of PluginVC may be held without release Key: TS-2317 URL: https://issues.apache.org/jira/browse/TS-2317 Project: Traffic Server Issue Type: Bug Components: Core Reporter: portl4t Attachments: pluginvc.patch read/write mutex of PluginVC may be held without release which will cause PluginVC hang -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2275) fix interim cache lossing data if the server process crash
[ https://issues.apache.org/jira/browse/TS-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2275: Attachment: master.patch This patch will recover interim index. fix interim cache lossing data if the server process crash -- Key: TS-2275 URL: https://issues.apache.org/jira/browse/TS-2275 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Zhao Yongming Assignee: portl4t Attachments: master.patch the current interim cache device is not permanent storage, it is cleared on each server restart, that is because we do not have a very good solution for the storage consistence. we have a patch under testing for that improvement. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2247) ua close time in milestone may not set
[ https://issues.apache.org/jira/browse/TS-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] portl4t updated TS-2247: Attachment: time.patch check milestones.ua_close in HttpSM::update_stats ua close time in milestone may not set -- Key: TS-2247 URL: https://issues.apache.org/jira/browse/TS-2247 Project: Traffic Server Issue Type: Bug Components: HTTP, Logging, Stats Reporter: Zhao Yongming Assignee: portl4t Fix For: 4.1.0 Attachments: time.patch that will cause many problems such as create some negative stats on transaction time. LiGang have a patch for that. which maybe related to TS-2238 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-2166:
Assignee: portl4t
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4, 4.2.0
Reporter: portl4t
Assignee: portl4t
Fix For: 4.2.0
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2166) Response header to ua has two Content-Range field
portl4t created TS-2166: --- Summary: Response header to ua has two Content-Range field Key: TS-2166 URL: https://issues.apache.org/jira/browse/TS-2166 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: portl4t Follow these steps to reproduce: 1. TrafficServer cache a document which has Etag field in response header 2. The document expires. 3. UA sends request with Range field to this document. 4. TrafficServer sends request with IMS field to origin server to revalidate this document 5. Origin Server sends response which has 304 code and Content-Range field to TrafficServer 6. TrafficServer will generate another Content-Range field in RangeTransform. HTTP/1.1 206 Partial Content Date: Thu, 29 Aug 2013 03:09:05 GMT Content-Type: application/octet-stream Cache-Control: public Content-Disposition: attachment; Content-Encoding: utf-8 ETag: F68ADB16DB4F1EF87D93D665CC1FFF54 Expires: Tue,13 August 2013 07:04:10 GMT Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT Server: ATS/3.2.0 x-oss-request-id: 521EBB51E369AA445D2F48B9 Accept-Ranges: bytes Content-Range: bytes 0-4243537/4243538 Content-Range: bytes 0-4243537/4243538 Content-Length: 4243538 Age: 0 Via: http/1.1 l2cn202 (ATS [cSsNfU]) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-2166:
Description:
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field to
TrafficServer
6. TrafficServer will generate another Content-Range field in RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
was:
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field to
TrafficServer
6. TrafficServer will generate another Content-Range field in RangeTransform.
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: portl4t
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-2166:
Affects Version/s: 3.2.4
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4
Reporter: portl4t
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2061) malloc(): memory corruption (fast) in LogBuffer
[
https://issues.apache.org/jira/browse/TS-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-2061:
Attachment: 0001-check-m_overspill_bytes-value.patch
malloc(): memory corruption (fast) in LogBuffer
-
Key: TS-2061
URL: https://issues.apache.org/jira/browse/TS-2061
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Yunkai Zhang
Attachments: 0001-check-m_overspill_bytes-value.patch
{code}
(gdb) bt
#0 0x003c466f4e6e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x003c4667bae8 in _L_lock_9162 () from /lib64/libc.so.6
#2 0x003c46679482 in malloc () from /lib64/libc.so.6
#3 0x003c45e0cb7b in _dl_map_object_deps () from
/lib64/ld-linux-x86-64.so.2
#4 0x003c45e12991 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#5 0x003c45e0e106 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#6 0x003c45e123ea in _dl_open () from /lib64/ld-linux-x86-64.so.2
#7 0x003c46722f80 in do_dlopen () from /lib64/libc.so.6
#8 0x003c45e0e106 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#9 0x003c467230d7 in __libc_dlopen_mode () from /lib64/libc.so.6
#10 0x003c466fb675 in init () from /lib64/libc.so.6
#11 0x003c46a0cac3 in pthread_once () from /lib64/libpthread.so.0
#12 0x003c466fb774 in backtrace () from /lib64/libc.so.6
#13 0x2ae6b8e48358 in ink_stack_trace_dump () from
/usr/lib64/trafficserver/libtsutil.so.3
#14 0x004f19e2 in ?? ()
#15 signal handler called
#16 0x003c46678568 in _int_malloc () from /lib64/libc.so.6
#17 0x003c4667948d in malloc () from /lib64/libc.so.6
#18 0x0031a56bd0bd in operator new(unsigned long) () from
/usr/lib64/libstdc++.so.6
#19 0x0031a56bd1d9 in operator new[](unsigned long) () from
/usr/lib64/libstdc++.so.6
#20 0x005b5e40 in LogBuffer::LogBuffer(LogObject*, unsigned long,
unsigned long, unsigned long) ()
#21 0x005cdbd4 in LogObject::_checkout_write(unsigned long*, unsigned
long) ()
#22 0x005cf4a0 in LogObject::log(LogAccess*, char*) ()
#23 0x005b69e6 in Log::access(LogAccess*) ()
#24 0x00539900 in HttpSM::update_stats() ()
#25 0x00542b78 in HttpSM::kill_this() ()
#26 0x00542e98 in HttpSM::main_handler(int, void*) ()
#27 0x005805fe in HttpTunnel::main_handler(int, void*) ()
#28 0x006bbfb1 in ?? ()
#29 0x006be037 in write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*) ()
#30 0x006b69a6 in NetHandler::mainNetEvent(int, Event*) ()
#31 0x006df414 in EThread::process_event(Event*, int) ()
#32 0x006dfdbb in EThread::execute() ()
#33 0x004d6c9c in main ()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2061) malloc(): memory corruption (fast) in LogBuffer
[
https://issues.apache.org/jira/browse/TS-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13716362#comment-13716362
]
portl4t commented on TS-2061:
-
attach patch file
malloc(): memory corruption (fast) in LogBuffer
-
Key: TS-2061
URL: https://issues.apache.org/jira/browse/TS-2061
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Yunkai Zhang
Attachments: 0001-check-m_overspill_bytes-value.patch
{code}
(gdb) bt
#0 0x003c466f4e6e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x003c4667bae8 in _L_lock_9162 () from /lib64/libc.so.6
#2 0x003c46679482 in malloc () from /lib64/libc.so.6
#3 0x003c45e0cb7b in _dl_map_object_deps () from
/lib64/ld-linux-x86-64.so.2
#4 0x003c45e12991 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#5 0x003c45e0e106 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#6 0x003c45e123ea in _dl_open () from /lib64/ld-linux-x86-64.so.2
#7 0x003c46722f80 in do_dlopen () from /lib64/libc.so.6
#8 0x003c45e0e106 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#9 0x003c467230d7 in __libc_dlopen_mode () from /lib64/libc.so.6
#10 0x003c466fb675 in init () from /lib64/libc.so.6
#11 0x003c46a0cac3 in pthread_once () from /lib64/libpthread.so.0
#12 0x003c466fb774 in backtrace () from /lib64/libc.so.6
#13 0x2ae6b8e48358 in ink_stack_trace_dump () from
/usr/lib64/trafficserver/libtsutil.so.3
#14 0x004f19e2 in ?? ()
#15 signal handler called
#16 0x003c46678568 in _int_malloc () from /lib64/libc.so.6
#17 0x003c4667948d in malloc () from /lib64/libc.so.6
#18 0x0031a56bd0bd in operator new(unsigned long) () from
/usr/lib64/libstdc++.so.6
#19 0x0031a56bd1d9 in operator new[](unsigned long) () from
/usr/lib64/libstdc++.so.6
#20 0x005b5e40 in LogBuffer::LogBuffer(LogObject*, unsigned long,
unsigned long, unsigned long) ()
#21 0x005cdbd4 in LogObject::_checkout_write(unsigned long*, unsigned
long) ()
#22 0x005cf4a0 in LogObject::log(LogAccess*, char*) ()
#23 0x005b69e6 in Log::access(LogAccess*) ()
#24 0x00539900 in HttpSM::update_stats() ()
#25 0x00542b78 in HttpSM::kill_this() ()
#26 0x00542e98 in HttpSM::main_handler(int, void*) ()
#27 0x005805fe in HttpTunnel::main_handler(int, void*) ()
#28 0x006bbfb1 in ?? ()
#29 0x006be037 in write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*) ()
#30 0x006b69a6 in NetHandler::mainNetEvent(int, Event*) ()
#31 0x006df414 in EThread::process_event(Event*, int) ()
#32 0x006dfdbb in EThread::execute() ()
#33 0x004d6c9c in main ()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1151) in some strange situation, cop will crash
[
https://issues.apache.org/jira/browse/TS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-1151:
Attachment: 0001-initialize-pointer-val.patch
in some strange situation, cop will crash
-
Key: TS-1151
URL: https://issues.apache.org/jira/browse/TS-1151
Project: Traffic Server
Issue Type: Bug
Components: cop
Affects Versions: 3.3.4, 3.2.4, 3.0.4
Reporter: Zhao Yongming
Assignee: portl4t
Fix For: 3.3.5, 3.1.4
Attachments: 0001-initialize-pointer-val.patch
we get some strange crash, the manager cop may die, we are not sure what
that is, but I'd like to start one Issue here if we have other same issue.
here is the log in /var/log/messages
{code}
Mar 19 10:08:24 cache172.cn77 kernel:: [1553138.961401] [ET_NET 2][17949]:
segfault at 2aadf1387937 ip 003c5bc7bdbe sp 410f3188 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: cop received child status
signal [17935 2816]
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: traffic_manager not
running, making sure traffic_server is dead
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: spawning traffic_manager
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: --- Manager
Starting ---
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:08:46 cache172.cn77 traffic_cop[17933]: (cli test) unable to
retrieve manager_binary
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: --- Server Starting
---
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012
at 09:56:00)
Mar 19 10:09:00 cache172.cn77 traffic_server[2789]: {0x2b5a8ef03970} STATUS:
opened /var/log/trafficserver/diags.log
Mar 19 10:14:02 cache172.cn77 kernel:: [1553476.364204] [ET_NET 0][2789]:
segfault at 2aab1fa99ce3 ip 003c5bc7bdbe sp 7fff39743fa8 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
(last system error 32: Broken pipe)
{code}
here is the message in traffic.out
{code}
Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]:
segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in
libc-2.5.so[3f7f20+14d000]
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status
signal [305 2816]
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running,
making sure traffic_server is dead
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager
Starting ---
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to
[jira] [Commented] (TS-1751) when ts have high cpu usage, cluster thread isn't balance
[ https://issues.apache.org/jira/browse/TS-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13608928#comment-13608928 ] portl4t commented on TS-1751: - if not bound thread, will this increase cache miss ? when ts have high cpu usage, cluster thread isn't balance - Key: TS-1751 URL: https://issues.apache.org/jira/browse/TS-1751 Project: Traffic Server Issue Type: Improvement Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Attachments: TS-1751.patch eg: 3944 ats 20 0 33.1g 26g 7156 S 25.1 57.0 28:14.11 [ET_CLUSTER 4] 3946 ats 20 0 33.1g 26g 7156 S 23.2 57.0 25:49.79 [ET_CLUSTER 6] 3948 ats 20 0 33.1g 26g 7156 R 23.2 57.0 23:58.17 [ET_CLUSTER 8] 3945 ats 20 0 33.1g 26g 7156 S 21.2 57.0 25:42.89 [ET_CLUSTER 5] 3941 ats 20 0 33.1g 26g 7156 R 19.3 57.0 22:46.74 [ET_CLUSTER 1] 3942 ats 20 0 33.1g 26g 7156 S 19.3 57.0 23:49.98 [ET_CLUSTER 2] 3943 ats 20 0 33.1g 26g 7156 R 19.3 57.0 21:34.23 [ET_CLUSTER 3] 3949 ats 20 0 33.1g 26g 7156 S 19.3 57.0 26:26.14 [ET_CLUSTER 9] 3950 ats 20 0 33.1g 26g 7156 R 17.4 57.0 19:16.56 [ET_CLUSTER 10] 3940 ats 20 0 33.1g 26g 7156 S 13.5 57.0 15:18.88 [ET_CLUSTER 0] 3947 ats 20 0 33.1g 26g 7156 S 13.5 57.0 14:18.56 [ET_CLUSTER 7] 3951 ats 20 0 33.1g 26g 7156 S 11.6 57.0 12:16.01 [ET_CLUSTER 11] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1746) Crash report: UnixNetVConnection::reenable ink_atomiclist_push ink_atomic_cas
[
https://issues.apache.org/jira/browse/TS-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601167#comment-13601167
]
portl4t commented on TS-1746:
-
ink_atomic_cas__int128 will use instruction: lock cmpxchg16b (%rsi), which
requires 16-byte alignment, and mem=0x73cae288 is not 16-byte alignment,
so it crash
Crash report: UnixNetVConnection::reenable ink_atomiclist_push
ink_atomic_cas
--
Key: TS-1746
URL: https://issues.apache.org/jira/browse/TS-1746
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Zhao Yongming
I think the recent changes cause this crash, and here is the stack trace:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x72492700 (LWP 23610)]
0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
153 return __sync_bool_compare_and_swap(mem, prev, next);
(gdb) bt
#0 0x77bb30a5 in ink_atomic_cas__int128 (mem=0x73cae288,
prev=0x0001,
next=0x7fffd4014501)
at ink_atomic.h:153
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
#2 0x006d8961 in AtomicSLLUnixNetVConnection,
UnixNetVConnection::Link_read_enable_link::push (this=0x73cae288,
c=0x7fffd4014500)
at ../../lib/ts/List.h:477
#3 0x006d6767 in UnixNetVConnection::reenable (this=0x7fffd4014500,
vio=0x7fffd4014610) at UnixNetVConnection.cc:721
#4 0x005195d5 in VIO::reenable (this=0x7fffd4014610) at
../iocore/eventsystem/P_VIO.h:124
#5 0x005c73b1 in HttpTunnel::consumer_handler (this=0x7fffdbefb888,
event=101, c=0x7fffdbefb8c8) at HttpTunnel.cc:1237
#6 0x005c7c1f in HttpTunnel::main_handler (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at HttpTunnel.cc:1481
#7 0x004f8aa6 in Continuation::handleEvent (this=0x7fffdbefb888,
event=101, data=0x7fffc4008870) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x0050a612 in TSContCall (contp=0x7fffdbefb888,
event=TS_EVENT_VCONN_WRITE_READY, edata=0x7fffc4008870) at InkAPI.cc:4400
#9 0x0055f302 in handle_transform (contp=0x7fffc40087c0) at
InkAPITest.cc:6435
#10 0x0055f4be in transformtest_transform (contp=0x7fffc40087c0,
event=TS_EVENT_IMMEDIATE, edata=0x1166920) at InkAPITest.cc:6501
#11 0x00501922 in INKVConnInternal::handle_event
(this=0x7fffc40087c0, event=1, edata=0x1166920) at InkAPI.cc:1045
#12 0x004f8aa6 in Continuation::handleEvent (this=0x7fffc40087c0,
event=1, data=0x1166920) at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006f823d in EThread::process_event (this=0x73aa9010,
e=0x1166920, calling_code=1) at UnixEThread.cc:142
#14 0x006f8491 in EThread::execute (this=0x73aa9010) at
UnixEThread.cc:193
#15 0x006f744c in spawn_thread_internal (a=0x1090810) at Thread.cc:88
#16 0x7793dea7 in start_thread () from /lib64/libpthread.so.0
#17 0x751c114d in clone () from /lib64/libc.so.6
(gdb) l
148 // ink_atomic_cas(mem, prev, next)
149 // Atomically store the value @next into the pointer @mem, but only
if the current value at @mem is @prev.
150 // Returns true if @next was successfully stored.
151 template typename T static inline bool
152 ink_atomic_cas(volatile T * mem, T prev, T next) {
153 return __sync_bool_compare_and_swap(mem, prev, next);
154 }
155
156 // ink_atomic_increment(ptr, count)
157 // Increment @ptr by @count, returning the previous value.
(gdb) f 1
#1 0x77bb2e29 in ink_atomiclist_push (l=0x73cae288,
item=0x7fffd4014500) at ink_queue.cc:481
481result = ink_atomic_cas((__int128_t*) l-head, head.data,
item_pair.data);
(gdb) p head.data
$1 = 0x0001
(gdb) p head
$2 = {s = {pointer = 0x1, version = 0}, data =
0x0001}
(gdb)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
