[jira] [Commented] (TS-895) Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid (10.04)

2011-08-01 Thread JIRA 

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

Brane F. Gračnar commented on TS-895:
-

Installing bison solved compilation issue!

Sorry for unnecessary nagging, but i wasn't able to find any external 
dependency related information.

Thanks alot!

> Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid 
> (10.04)
> ---
>
> Key: TS-895
> URL: https://issues.apache.org/jira/browse/TS-895
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Ubuntu lucid (10.04) LTS, 64bit
>Reporter: Brane F. Gračnar
>Assignee: Alan M. Carroll
> Fix For: 3.1.1
>
>
> I'm unable to compile ATS 3.0.1 on my 64bit ubuntu lucid server.
> Configure flags:
> ./configure --prefix=/usr --sysconfdir=/etc/trafficserver --enable-wccp 
> --enable-tproxy=auto --with-pic
> make dies with the following error:
> make[2]: Entering directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> /bin/bash ../../build/aux/ylwrap TsConfigGrammar.y y.tab.c TsConfigGrammar.c 
> y.tab.h TsConfigGrammar.h y.output TsConfigGrammar.output -- byacc  -d -p 
> tsconfig
> byacc: e - line 1 of 
> "/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig/TsConfigGrammar.y", syntax 
> error
> %code top {
> ^
> make[2]: *** [TsConfigGrammar.c] Error 1
> make[2]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib'
> make: *** [all-recursive] Error 1

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

[jira] [Commented] (TS-895) Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid (10.04)

2011-08-01 Thread Alan M. Carroll (JIRA) 

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

Alan M. Carroll commented on TS-895:


We realize that information is missing, so we're keeping the bug as a marker 
that the configuration process should be clearer about this requirement.

> Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid 
> (10.04)
> ---
>
> Key: TS-895
> URL: https://issues.apache.org/jira/browse/TS-895
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Ubuntu lucid (10.04) LTS, 64bit
>Reporter: Brane F. Gračnar
>Assignee: Alan M. Carroll
> Fix For: 3.1.1
>
>
> I'm unable to compile ATS 3.0.1 on my 64bit ubuntu lucid server.
> Configure flags:
> ./configure --prefix=/usr --sysconfdir=/etc/trafficserver --enable-wccp 
> --enable-tproxy=auto --with-pic
> make dies with the following error:
> make[2]: Entering directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> /bin/bash ../../build/aux/ylwrap TsConfigGrammar.y y.tab.c TsConfigGrammar.c 
> y.tab.h TsConfigGrammar.h y.output TsConfigGrammar.output -- byacc  -d -p 
> tsconfig
> byacc: e - line 1 of 
> "/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig/TsConfigGrammar.y", syntax 
> error
> %code top {
> ^
> make[2]: *** [TsConfigGrammar.c] Error 1
> make[2]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib'
> make: *** [all-recursive] Error 1

--
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-01 Thread John Plevyak (JIRA) 

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

John Plevyak commented on TS-844:
-

I'd like to know what the top of the stack looked like and also what "fail" 
means in this context.

The patch is safe in the sense that it is conservative, but if a write has been 
closed, but
not yet been written into the aggregation buffer, this patch will prevent that 
data from being
available for a ReadFromWriter.  At least that is how I read it.

What I am wondering is what about a closed by not yet written CacheVC is making 
ReadaFromWriter fail?


> 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
> 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.