[jira] [Commented] (TS-899) ts crash

2011-08-07 Thread Zhao Yongming (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080772#comment-13080772
 ] 

Zhao Yongming commented on TS-899:
--

weijin find out that prefetch plugin will cause this remap into the buggy 
transform codes, can crash the server, so I update it a prefetch sub task, and 
hopes we can get all target for prefetch clear and fixed later.

> ts crash
> 
>
> Key: TS-899
> URL: https://issues.apache.org/jira/browse/TS-899
> Project: Traffic Server
>  Issue Type: Sub-task
>  Components: HTTP, MIME
>Affects Versions: 3.0.1
> Environment: readhat5.5, ts-3.0.1, X86-64
>Reporter: weijin
>
> If a request url is forbidden then redirected to another url, TS crash.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-899) ts crash

2011-08-07 Thread Zhao Yongming (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming updated TS-899:
-

Issue Type: Sub-task  (was: Bug)
Parent: TS-893

> ts crash
> 
>
> Key: TS-899
> URL: https://issues.apache.org/jira/browse/TS-899
> Project: Traffic Server
>  Issue Type: Sub-task
>  Components: HTTP, MIME
>Affects Versions: 3.0.1
> Environment: readhat5.5, ts-3.0.1, X86-64
>Reporter: weijin
>
> If a request url is forbidden then redirected to another url, TS crash.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-844) ReadFromWriter fail in CacheRead.cc

2011-08-07 Thread Zhao Yongming (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080763#comment-13080763
 ] 

Zhao Yongming commented on TS-844:
--

after talk to mohan, he is not sure what is the low level crash root cause too, 
that is what John wondering.
I'd push back a while, if no other report on the same issue, maybe mohan can 
get the question cleared.

> ReadFromWriter fail in CacheRead.cc
> ---
>
> Key: TS-844
> URL: https://issues.apache.org/jira/browse/TS-844
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: mohan_zl
>Assignee: Zhao Yongming
> Fix For: 3.1.0
>
> Attachments: TS-844.patch
>
>
> {code}
> #6  0x006ab4d7 in CacheVC::openReadChooseWriter (this=0x2aaaf81523d0, 
> event=1, e=0x0) at CacheRead.cc:320
> #7  0x006abdc9 in CacheVC::openReadFromWriter (this=0x2aaaf81523d0, 
> event=1, e=0x0) at CacheRead.cc:411
> #8  0x004d302f in Continuation::handleEvent (this=0x2aaaf81523d0, 
> event=1, data=0x0) at I_Continuation.h:146
> #9  0x006ae2b9 in Cache::open_read (this=0x2aaab0001c40, 
> cont=0x2aaab4472aa0, key=0x42100b10, request=0x2aaab44710f0, 
> params=0x2aaab4470928, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aab09581049 
> "js.tongji.linezing.comicon1.gifjs.tongji.linezing.com�ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿½ï¿½"...,
>  host_len=22) at CacheRead.cc:228
> #10 0x0068da30 in Cache::open_read (this=0x2aaab0001c40, 
> cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
> params=0x2aaab4470928,
> type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1068
> #11 0x0067d32f in CacheProcessor::open_read (this=0xf2c030, 
> cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
> params=0x2aaab4470928, pin_in_cache=0,
> type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3011
> #12 0x0054e058 in HttpCacheSM::do_cache_open_read 
> (this=0x2aaab4472aa0) at HttpCacheSM.cc:220
> #13 0x0054e1a7 in HttpCacheSM::open_read (this=0x2aaab4472aa0, 
> url=0x2aaab4471108, hdr=0x2aaab44710f0, params=0x2aaab4470928, 
> pin_in_cache=0) at HttpCacheSM.cc:252
> #14 0x00568404 in HttpSM::do_cache_lookup_and_read 
> (this=0x2aaab4470830) at HttpSM.cc:3893
> #15 0x005734b5 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6436
> #16 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #17 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #18 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #19 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #20 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #21 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #22 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #23 0x00572faf in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6378
> #24 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #25 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #26 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #27 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #28 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #29 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #30 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #31 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #32 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #33 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #34 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #35 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #36 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0x59e52e

[jira] [Commented] (TS-808) INACTIVE_TIMEOUT for *.channel.facebook.com

2011-08-07 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080720#comment-13080720
 ] 

Leif Hedstrom commented on TS-808:
--

Anyone have any ideas how to reproduce or test this problem ? I'm venturing a 
guess that this is somehow related to "hanging gets" from Facebook, but I 
honestly don't know...

> INACTIVE_TIMEOUT for *.channel.facebook.com
> ---
>
> Key: TS-808
> URL: https://issues.apache.org/jira/browse/TS-808
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 2.1.8
> Environment: Linux 2.6.35.10 x86_64
>Reporter: Alvin Alexander
> Fix For: 3.1.0
>
>
> error.log :
> 20110528.13h06m13s CONNECT:[5] could not connect [INACTIVE_TIMEOUT] to 
> 66.220.151.83 for 
> 'http://0.164.channel.facebook.com/x/324863553/1802403183/false/p_11790027719=1'
> 20110528.13h06m13s CONNECT:[6] could not connect [INACTIVE_TIMEOUT] to 
> 66.220.151.76 for 
> 'http://0.122.channel.facebook.com/x/461720327/101899065/false/p_1523748988=22'
> 20110528.13h06m13s CONNECT:[3] could not connect [INACTIVE_TIMEOUT] to 
> 66.220.151.77 for 
> 'http://0.128.channel.facebook.com/x/2800423340/1779706821/false/p_10277560566=6'

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-844) ReadFromWriter fail in CacheRead.cc

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-844:


Assignee: Zhao Yongming

Assigning to ming_zym, so he can properly prioritize / review.

> ReadFromWriter fail in CacheRead.cc
> ---
>
> Key: TS-844
> URL: https://issues.apache.org/jira/browse/TS-844
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: mohan_zl
>Assignee: Zhao Yongming
> Fix For: 3.1.0
>
> Attachments: TS-844.patch
>
>
> {code}
> #6  0x006ab4d7 in CacheVC::openReadChooseWriter (this=0x2aaaf81523d0, 
> event=1, e=0x0) at CacheRead.cc:320
> #7  0x006abdc9 in CacheVC::openReadFromWriter (this=0x2aaaf81523d0, 
> event=1, e=0x0) at CacheRead.cc:411
> #8  0x004d302f in Continuation::handleEvent (this=0x2aaaf81523d0, 
> event=1, data=0x0) at I_Continuation.h:146
> #9  0x006ae2b9 in Cache::open_read (this=0x2aaab0001c40, 
> cont=0x2aaab4472aa0, key=0x42100b10, request=0x2aaab44710f0, 
> params=0x2aaab4470928, type=CACHE_FRAG_TYPE_HTTP,
> hostname=0x2aab09581049 
> "js.tongji.linezing.comicon1.gifjs.tongji.linezing.com�ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿½ï¿½"...,
>  host_len=22) at CacheRead.cc:228
> #10 0x0068da30 in Cache::open_read (this=0x2aaab0001c40, 
> cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
> params=0x2aaab4470928,
> type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1068
> #11 0x0067d32f in CacheProcessor::open_read (this=0xf2c030, 
> cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
> params=0x2aaab4470928, pin_in_cache=0,
> type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3011
> #12 0x0054e058 in HttpCacheSM::do_cache_open_read 
> (this=0x2aaab4472aa0) at HttpCacheSM.cc:220
> #13 0x0054e1a7 in HttpCacheSM::open_read (this=0x2aaab4472aa0, 
> url=0x2aaab4471108, hdr=0x2aaab44710f0, params=0x2aaab4470928, 
> pin_in_cache=0) at HttpCacheSM.cc:252
> #14 0x00568404 in HttpSM::do_cache_lookup_and_read 
> (this=0x2aaab4470830) at HttpSM.cc:3893
> #15 0x005734b5 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6436
> #16 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #17 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #18 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #19 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #20 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #21 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #22 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #23 0x00572faf in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6378
> #24 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #25 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #26 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #27 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #28 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #29 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #30 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
> #31 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
> HttpSM.cc:1516
> #32 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
> event=0, data=0x0) at HttpSM.cc:1448
> #33 0x0056de77 in HttpSM::do_api_callout_internal 
> (this=0x2aaab4470830) at HttpSM.cc:4345
> #34 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
> HttpSM.cc:497
> #35 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
> HttpSM.cc:6362
> #36 0x0056115a in HttpSM::call_transact_and_set_next_state 
> (this=0x2aaab4470830, f=0x59e52e 
> ) at HttpSM.cc:6328
> #37 0x0057490c in HttpSM::state_read_client_request_header 
> (this=0x2aaab4470830, event=100, data=0x2049f5e8) at HttpSM.cc:780
> #38 0x

[jira] [Updated] (TS-888) SSL connections working with 2.1.5 fail with 3.0.1 and FireFox

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-888:
-

Backport to Version: 3.0.2

> SSL connections working with 2.1.5 fail with 3.0.1 and FireFox
> --
>
> Key: TS-888
> URL: https://issues.apache.org/jira/browse/TS-888
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 3.0.1
> Environment: Ubuntu 10.04 LTS amd64, Glassfish 3.0.1, FireFox 5.0
>Reporter: Kurt Huwig
>Assignee: Leif Hedstrom
> Fix For: 3.1.0
>
> Attachments: TS-888-jp.patch
>
>
> ATS has SSL server certificates. The backend is accessed via SSL as well 
> which uses the same certificates. It fails with FireFox, but works with 
> Google Chrome.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-888) SSL connections working with 2.1.5 fail with 3.0.1 and FireFox

2011-08-07 Thread Leif Hedstrom (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080707#comment-13080707
 ] 

Leif Hedstrom commented on TS-888:
--

Patch looks good to me.

> SSL connections working with 2.1.5 fail with 3.0.1 and FireFox
> --
>
> Key: TS-888
> URL: https://issues.apache.org/jira/browse/TS-888
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 3.0.1
> Environment: Ubuntu 10.04 LTS amd64, Glassfish 3.0.1, FireFox 5.0
>Reporter: Kurt Huwig
>Assignee: Leif Hedstrom
> Fix For: 3.1.0
>
> Attachments: TS-888-jp.patch
>
>
> ATS has SSL server certificates. The backend is accessed via SSL as well 
> which uses the same certificates. It fails with FireFox, but works with 
> Google Chrome.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-888) SSL connections working with 2.1.5 fail with 3.0.1 and FireFox

2011-08-07 Thread John Plevyak (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Plevyak updated TS-888:


Attachment: TS-888-jp.patch

> SSL connections working with 2.1.5 fail with 3.0.1 and FireFox
> --
>
> Key: TS-888
> URL: https://issues.apache.org/jira/browse/TS-888
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 3.0.1
> Environment: Ubuntu 10.04 LTS amd64, Glassfish 3.0.1, FireFox 5.0
>Reporter: Kurt Huwig
>Assignee: Leif Hedstrom
> Fix For: 3.1.0
>
> Attachments: TS-888-jp.patch
>
>
> ATS has SSL server certificates. The backend is accessed via SSL as well 
> which uses the same certificates. It fails with FireFox, but works with 
> Google Chrome.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-867) PluginVC crashes with TSFetchURL

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-867:


Assignee: vijaya bhaskar mamidi

> PluginVC crashes with TSFetchURL
> 
>
> Key: TS-867
> URL: https://issues.apache.org/jira/browse/TS-867
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Naveen
>Assignee: vijaya bhaskar mamidi
>  Labels: api, plugin
> Fix For: 3.1.0
>
>
> On TSFetchURL call, the call_event in PluginVC does not match with any of the 
> events(active_event,inactive_event,core_lock_retry_event,sm_lock_retry_event).
>  However, on trace analysis it actually matches with sm_lock_retry_event. 
> (gdb) bt
> #0  0xb7fe1424 in __kernel_vsyscall ()
> #1  0xb7a1ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2  0xb7a1e34e in abort () at abort.c:92
> #3  0xb7fad9a4 in ink_die_die_die (retval=1) at ink_error.cc:43
> #4  0xb7fada79 in ink_fatal_va (return_code=1, message_format=0xb5767f5c 
> "PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`", 
> ap=0xb5767f38 "") at ink_error.cc:65
> #5  0xb7fadabd in ink_fatal (return_code=1, message_format=0xb5767f5c 
> "PluginVC.cc:193: failed assert `call_event == core_lock_retry_event`")
> at ink_error.cc:73
> #6  0xb7fac684 in _ink_assert (a=0x8302b10 "call_event == 
> core_lock_retry_event", f=0x8302a2d "PluginVC.cc", l=193) at ink_assert.cc:44
> #7  0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1, 
> data=0x8999890) at PluginVC.cc:193
> #8  0x0810bd47 in Continuation::handleEvent (this=0x896a7fc, event=1, 
> data=0x8999890) at ../iocore/eventsystem/I_Continuation.h:146
> #9  0x082f2a8a in EThread::process_event (this=0xb6577008, e=0x8999890, 
> calling_code=1) at UnixEThread.cc:140
> #10 0x082f2f30 in EThread::execute (this=0xb6577008) at UnixEThread.cc:232
> #11 0x082f1b75 in spawn_thread_internal (a=0x891a1e0) at Thread.cc:85
> #12 0xb7f89e99 in start_thread (arg=0xb5768b70) at pthread_create.c:304
> #13 0xb7ac073e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
> (gdb) f 7
> #7  0x0813e0fa in PluginVC::main_handler (this=0x896a7fc, event=1, 
> data=0x8999890) at PluginVC.cc:193
> 193 ink_release_assert(call_event == core_lock_retry_event);
> (gdb) print *this
> $1 = { = { = { = 
> { = {_vptr.force_VFPT_to_top = 0x8303188}, handler = (
> int (Continuation::*)(Continuation *, int, void *)) 0x813dc66 
> , 
> handler_name = 0x8302a06 "&PluginVC::main_handler", mutex = {m_ptr = 
> 0x8979c30}, link = {> = {next = 0x0}, 
>   prev = 0x0}}, lerrno = 0}, options = {ip_proto = 
> NetVCOptions::USE_TCP, local_port = 0, port_binding = NetVCOptions::ANY_PORT, 
>   local_addr = 0, addr_binding = NetVCOptions::ANY_ADDR, f_blocking = 
> false, f_blocking_connect = false, socks_support = 0 '\000', 
>   socks_version = 0 '\000', socket_recv_bufsize = 0, socket_send_bufsize 
> = 0, sockopt_flags = 0, static SOCK_OPT_NO_DELAY = 1, 
>   static SOCK_OPT_KEEP_ALIVE = 2, etype = 0}, socks_addr = {type = 0 
> '\000', addr = {ipv4 = "\000\000\000", buf = 0x0}}, attributes = 0, 
> thread = 0xb6a7c008, local_addr = {ss_family = 0, __ss_align = 0, 
> __ss_padding = '\000' }, remote_addr = {ss_family = 0, 
>   __ss_align = 0, __ss_padding = '\000' }, 
> got_local_addr = 0, got_remote_addr = 0, is_internal_request = false, 
> is_transparent = 49, is_other_side_transparent = false}, magic = 
> 2864434397, vc_type = PLUGIN_VC_ACTIVE, core_obj = 0x896a7e0, 
>   other_side = 0x896a9fc, read_state = {vio = {_cont = 0x8970e30, nbytes = 
> 9223372036854775807, ndone = 0, op = 1, buffer = {mbuf = 0x8995b40, 
> entry = 0x0, name = 0x0}, vc_server = 0x896a7fc, mutex = {m_ptr = 
> 0x89b8a60}}, shutdown = false}, write_state = {vio = {
>   _cont = 0x8970e30, nbytes = 188, ndone = 0, op = 2, buffer = {mbuf = 
> 0x8994d80, entry = 0x8994d94, name = 0x0}, vc_server = 0x896a7fc, 
>   mutex = {m_ptr = 0x89b8a60}}, shutdown = false}, need_read_process = 
> true, need_write_process = true, closed = false, 
>   sm_lock_retry_event = 0x8999890, core_lock_retry_event = 0x0, deletable = 
> false, reentrancy_count = 1, active_timeout = 0, 
>   inactive_timeout = 0, active_event = 0x0, inactive_event = 0x0}
> (gdb) print sm_lock_retry_event
> $5 = (Event *) 0x8999890
> (gdb) print call_event
> $6 = (Event *) 0x8999890
> (gdb) print this->write_state->vio->_cont->handler_name
> $7 = 0x82fae82 "&FetchSM::fetch_handler"
> (gdb) print this->read_state->vio->_cont->handler_name
> $8 = 0x82fae82 "&FetchSM::fetch_handler"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-876) forward map based on request receive port

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-876:
-

Fix Version/s: (was: 3.1.1)
   3.1.0
 Assignee: vijaya bhaskar mamidi  (was: Leif Hedstrom)

> forward map based on request receive port
> -
>
> Key: TS-876
> URL: https://issues.apache.org/jira/browse/TS-876
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Remap API
>Reporter: Manjesh Nilange
>Assignee: vijaya bhaskar mamidi
> Fix For: 3.1.0
>
> Attachments: map_with_recv_port-trunk.patch, 
> map_with_recv_port.patch, map_with_recv_port_v2.patch
>
>
> Currently the port in the "from" fields of all remap rules are compared 
> against the port in the request (explicitly in the request or implicitly 
> deduced from the protocol). TS supports listening on multiple ports, so there 
> is a use case for a remap rule that uses the TS port at which the request is 
> received instead of the "request port".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-882) traffic_logstats dies when printing log

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reopened TS-882:
--


Reopening for 3.0.2 backport.

> traffic_logstats dies when printing log
> ---
>
> Key: TS-882
> URL: https://issues.apache.org/jira/browse/TS-882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.0.0
> Environment: Mac OSX 10.6.8
>Reporter: Alan Cabrera
>Assignee: Leif Hedstrom
>Priority: Critical
>  Labels: crash
> Fix For: 3.1.0
>
>
> {code}
> [daruma:trafficserver 598]$ ./bin/traffic_logstats  -l 
> var/log/trafficserver/squid.blog 
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0003 0x0 + 3
> Abort trap
> [daruma:trafficserver 599]$ ./bin/traffic_logstats  -f 
> var/log/trafficserver/squid.blog 
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0003 0x0 + 3
> Abort trap
> [daruma:trafficserver 600]$ ./bin/traffic_logstats
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0001 0x0 + 1
> Abort trap
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-882) traffic_logstats dies when printing log

2011-08-07 Thread Leif Hedstrom (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-882:
-

Backport to Version: 3.0.2

> traffic_logstats dies when printing log
> ---
>
> Key: TS-882
> URL: https://issues.apache.org/jira/browse/TS-882
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.0.0
> Environment: Mac OSX 10.6.8
>Reporter: Alan Cabrera
>Assignee: Leif Hedstrom
>Priority: Critical
>  Labels: crash
> Fix For: 3.1.0
>
>
> {code}
> [daruma:trafficserver 598]$ ./bin/traffic_logstats  -l 
> var/log/trafficserver/squid.blog 
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0003 0x0 + 3
> Abort trap
> [daruma:trafficserver 599]$ ./bin/traffic_logstats  -f 
> var/log/trafficserver/squid.blog 
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0003 0x0 + 3
> Abort trap
> [daruma:trafficserver 600]$ ./bin/traffic_logstats
> FATAL: ./logging/LogStandalone.cc:96: failed assert `setrlimit((RLIMCAST) 
> which, &rl) >= 0`
> ./bin/traffic_logstats - STACK TRACE: 
> 0   libtsutil.3.dylib   0x0001000cbb6b ink_fatal + 123
> 1   libtsutil.3.dylib   0x0001000ca571 _ink_assert + 145
> 2   traffic_logstats0x000152f4 _Z11init_systemv + 
> 100
> 3   traffic_logstats0x0001538b 
> _Z25init_log_standalone_basicPKc + 27
> 4   traffic_logstats0x000155ab main + 411
> 5   traffic_logstats0x00011484 start + 52
> 6   ??? 0x0001 0x0 + 1
> Abort trap
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-906) ATS doesn't read proxy.config.http.forward.proxy_auth_to_parent

2011-08-07 Thread Conan Wang (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080555#comment-13080555
 ] 

Conan Wang commented on TS-906:
---

This diff works for me: ATS sent my Proxy-Authorization header to origin server 
when I enabled the config.

Tested in global records.config as well as remap.config with conf_remap plugin.

> ATS doesn't read proxy.config.http.forward.proxy_auth_to_parent
> ---
>
> Key: TS-906
> URL: https://issues.apache.org/jira/browse/TS-906
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 3.0.1, 2.0.0
>Reporter: Conan Wang
>Assignee: Leif Hedstrom
> Fix For: 3.1.0
>
> Attachments: TS-906.diff
>
>
> "proxy.config.http.forward.proxy_auth_to_parent" should work when we want ATS 
> relay "Proxy-Authorization" header to parent proxy or origin server. 
> Current ATS doesn't read this config and set it to 0 (disable) by default. As 
> a result, HttpTransactHeaders::copy_header_fields always remove 
> "Proxy-Authorization" when building requests to origin server.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira