You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by John Plevyak <jp...@apache.org> on 2010/07/01 01:50:19 UTC
Re: Inspecting the cache
I just tested with the mainline and the cache
inspector works fine so long as your cache is
working.
You have to type in a URL and it has to exactly
match a URL in the cache unless you use Regex.
As for {cache}, current browsers will not
pass that as a hostname (they used to when this
feature was implemented). Right now the remap
is your best way to handle it.
john
On 6/30/2010 7:21 AM, Leif Hedstrom wrote:
> On 06/29/2010 11:46 PM, Pranav Modi wrote:
>> To inspect the cache I added the following rule in remap.config -
>>
>> map http://localhost:8080/cache http://{cache} @action=allow
>> @src_ip=0.0.0.0-255.255.255.255
>>
>> The value of the variable proxy.config.http_ui_enabled is 1.
>>
>> When i navigate to http://localhost:8080/cache on the browser, it
>> shows the cache page where the links to- 'Lookup Url', 'Delete Url'
>> etc. are shown.
>>
>
> Hmmm, not sure, I don't know if anyone has played with the cache
> inspector lately. Might be worthwhile filing a bug, so that we don't
> forget to test this.
>
>> But on clicking on any of those links shows - 'Your requested URL was
>> not found'. What could be the problem?
>>
>
> What is the URL that it's not finding?
>
>> Also, the administrator's guide says to navigate to this url -
>> http://{cache}. What does that mean?
>>
>
> That's in forward proxy mode only, which means you'd point your browser
> to use TS as the proxy. I think what you did above is preferable in most
> cases.
>
> -- leif
Re: Inspecting the cache
Posted by John Plevyak <jp...@apache.org>.
I did 2 experiments:
map http://ts_cache/ http://{cache} @action=allow
@src_ip=0.0.0.0-255.255.255.255
This is the way I tested it and it works fine.
map http://localhost:8080/cache http://{cache} @action=allow
@src_ip=0.0.0.0-255.255.255.255
This is the way you were doing it. This seems a bit confusing
to me since TS is actually at localhost:8080, and out of
all the possible things to remap this wouldn't be the one
I would pick.
This one produces
internal error - server connection terminated
The problem seems to be that after the remap it
is not detected as a stat page.
Specifically, the correct trace is:
[Jul 2 12:14:16.148] Server {140737268184848} DEBUG: (http) [2]
[HttpSM::main_handler, VC_EVENT_READ_READY]
[Jul 2 12:14:16.148] Server {140737268184848} DEBUG: (http) [2]
[&HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
[Jul 2 12:14:16.149] Server {140737268184848} DEBUG: (http) [2] done
parsing client request header
[Jul 2 12:14:16.149] Server {140737268184848} DEBUG: (http) [2] State
Transition: STATE_UNDEFINED -> HTTP_API_READ_REQUEST_PRE_REMAP
[Jul 2 12:14:16.149] Server {140737268184848} DEBUG: (http) [2] State
Transition: HTTP_API_READ_REQUEST_PRE_REMAP -> HTTP_REMAP_REQUEST
[Jul 2 12:14:16.149] Server {140737268184848} DEBUG: (http) [2] State
Transition: HTTP_REMAP_REQUEST -> API_READ_REQUEST_HDR
[Jul 2 12:14:16.149] Server {140737268184848} DEBUG: (http) [2] State
Transition: API_READ_REQUEST_HDR -> PROXY_INTERNAL_REQUEST
[Jul 2 12:14:16.168] Server {140737268184848} DEBUG: (http) [2]
[HttpSM::main_handler, STAT_PAGE_SUCCESS]
Whereas with the mapping you are using I am getting:
[Jul 2 12:13:51.383] Server {140737353979872} DEBUG: (http) [0]
[HttpSM::main_handler, VC_EVENT_READ_READY]
[Jul 2 12:13:51.383] Server {140737353979872} DEBUG: (http) [0]
[&HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
[Jul 2 12:13:51.384] Server {140737353979872} DEBUG: (http) [0] done
parsing client request header
[Jul 2 12:13:51.384] Server {140737353979872} DEBUG: (http) [0] State
Transition: STATE_UNDEFINED -> HTTP_API_READ_REQUEST_PRE_REMAP
[Jul 2 12:13:51.384] Server {140737353979872} DEBUG: (http) [0] State
Transition: HTTP_API_READ_REQUEST_PRE_REMAP -> HTTP_REMAP_REQUEST
[Jul 2 12:13:51.384] Server {140737353979872} DEBUG: (http) [0] State
Transition: HTTP_REMAP_REQUEST -> API_READ_REQUEST_HDR
[Jul 2 12:13:51.385] Server {140737353979872} DEBUG: (http) [0] State
Transition: API_READ_REQUEST_HDR -> CACHE_LOOKUP
[Jul 2 12:13:51.385] Server {140737353979872} DEBUG: (http) [0]
[HttpSM::main_handler, CACHE_EVENT_OPEN_READ_FAILED]
[Jul 2 12:13:51.385] Server {140737353979872} DEBUG: (http) [0]
[&HttpSM::state_cache_open_read, CACHE_EVENT_OPEN_READ_FAILED]
I am not an HTTP SM guy (I am a cache guy), but the problem isn't with
the cache stat pages but rather with the remap and/or HTTP SM.
john
On 6/30/2010 9:42 PM, Pranav Modi wrote:
> The url not found for 'lookup url' is - http://localhost:8080/lookup_url_form
>
> And I checked, the cache is working.
>
> Pranav.
>
>
>
> On Thu, Jul 1, 2010 at 5:20 AM, John Plevyak <jp...@apache.org> wrote:
>>
>>
>> I just tested with the mainline and the cache
>> inspector works fine so long as your cache is
>> working.
>>
>> You have to type in a URL and it has to exactly
>> match a URL in the cache unless you use Regex.
>>
>> As for {cache}, current browsers will not
>> pass that as a hostname (they used to when this
>> feature was implemented). Right now the remap
>> is your best way to handle it.
>>
>>
>> john
>>
>>
>> On 6/30/2010 7:21 AM, Leif Hedstrom wrote:
>>> On 06/29/2010 11:46 PM, Pranav Modi wrote:
>>>> To inspect the cache I added the following rule in remap.config -
>>>>
>>>> map http://localhost:8080/cache http://{cache} @action=allow
>>>> @src_ip=0.0.0.0-255.255.255.255
>>>>
>>>> The value of the variable proxy.config.http_ui_enabled is 1.
>>>>
>>>> When i navigate to http://localhost:8080/cache on the browser, it
>>>> shows the cache page where the links to- 'Lookup Url', 'Delete Url'
>>>> etc. are shown.
>>>>
>>>
>>> Hmmm, not sure, I don't know if anyone has played with the cache
>>> inspector lately. Might be worthwhile filing a bug, so that we don't
>>> forget to test this.
>>>
>>>> But on clicking on any of those links shows - 'Your requested URL was
>>>> not found'. What could be the problem?
>>>>
>>>
>>> What is the URL that it's not finding?
>>>
>>>> Also, the administrator's guide says to navigate to this url -
>>>> http://{cache}. What does that mean?
>>>>
>>>
>>> That's in forward proxy mode only, which means you'd point your browser
>>> to use TS as the proxy. I think what you did above is preferable in most
>>> cases.
>>>
>>> -- leif
>>
>>
Re: Inspecting the cache
Posted by Pranav Modi <pr...@lukup.com>.
The url not found for 'lookup url' is - http://localhost:8080/lookup_url_form
And I checked, the cache is working.
Pranav.
On Thu, Jul 1, 2010 at 5:20 AM, John Plevyak <jp...@apache.org> wrote:
>
>
> I just tested with the mainline and the cache
> inspector works fine so long as your cache is
> working.
>
> You have to type in a URL and it has to exactly
> match a URL in the cache unless you use Regex.
>
> As for {cache}, current browsers will not
> pass that as a hostname (they used to when this
> feature was implemented). Right now the remap
> is your best way to handle it.
>
>
> john
>
>
> On 6/30/2010 7:21 AM, Leif Hedstrom wrote:
>> On 06/29/2010 11:46 PM, Pranav Modi wrote:
>>> To inspect the cache I added the following rule in remap.config -
>>>
>>> map http://localhost:8080/cache http://{cache} @action=allow
>>> @src_ip=0.0.0.0-255.255.255.255
>>>
>>> The value of the variable proxy.config.http_ui_enabled is 1.
>>>
>>> When i navigate to http://localhost:8080/cache on the browser, it
>>> shows the cache page where the links to- 'Lookup Url', 'Delete Url'
>>> etc. are shown.
>>>
>>
>> Hmmm, not sure, I don't know if anyone has played with the cache
>> inspector lately. Might be worthwhile filing a bug, so that we don't
>> forget to test this.
>>
>>> But on clicking on any of those links shows - 'Your requested URL was
>>> not found'. What could be the problem?
>>>
>>
>> What is the URL that it's not finding?
>>
>>> Also, the administrator's guide says to navigate to this url -
>>> http://{cache}. What does that mean?
>>>
>>
>> That's in forward proxy mode only, which means you'd point your browser
>> to use TS as the proxy. I think what you did above is preferable in most
>> cases.
>>
>> -- leif
>
>