You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Zhao Yongming (JIRA)" <ji...@apache.org> on 2010/11/12 16:51:14 UTC
[jira] Created: (TS-532) possible misbehavior with HEAD request
before GET
possible misbehavior with HEAD request before GET
-------------------------------------------------
Key: TS-532
URL: https://issues.apache.org/jira/browse/TS-532
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Environment: we have many haproxy before the TS server, do L7 hashing for all request
Reporter: Zhao Yongming
Priority: Trivial
sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
here is some tcpdum cap file
why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-532:
-----------------------------
Fix Version/s: 2.1.5
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Fix For: 2.1.5
>
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Zhao Yongming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933002#action_12933002 ]
Zhao Yongming commented on TS-532:
----------------------------------
seems the OPTIONS request can kill me too.
any common? they just can not cache by TS at all.
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-532:
-----------------------------
Fix Version/s: (was: 2.1.5)
2.1.6
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Fix For: 2.1.6
>
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Zhao Yongming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933810#action_12933810 ]
Zhao Yongming commented on TS-532:
----------------------------------
I have finally get the root cause:
my OS is 2 squid cluster, while one of the cluster have no dedicate hosts file, then fall back to DNS to lookup the backend, then loop back to my TS.
this will just happens when both TS and Squid have no such content in the cache, and you have send a HEAD request.
the question:
the loop detect in Squid and TS seems all fail for me. why?
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Zhao Yongming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhao Yongming closed TS-532.
----------------------------
Resolution: Invalid
This is invalid, I will post a project on create options to get loop detection more configurable later.
what we need to do is not just IP, but also hostanme(cluster name) etc
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Fix For: 2.1.6
>
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-532) possible misbehavior with HEAD request
before GET
Posted by "Zhao Yongming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933054#action_12933054 ]
Zhao Yongming commented on TS-532:
----------------------------------
maybe there is the problem:
01:42 < ming_zym> ok, zwoop: I think I got the problem
01:43 < ming_zym> when use ab, the -k will make ab timeout
01:43 < ming_zym> apr_poll: The timeout specified has expired (70007)
01:43 < ming_zym> while without -k, with all my custom headers, it works
01:51 < ming_zym> while the squid log shows: 1290016205.008 10 115.238.23.157 TCP_MISS/200 472 HEAD http://img08.taobaocdn.com/tps/i8/T1CNJHXd8BXXXXXXXX-40-40.jpg -
DIRECT/img08.taobaocdn.com image/jpeg -
01:52 < ming_zym> the log rise up just quickly, but ab is waiting to timeout
01:52 < ming_zym> I think that is reproduce now, here is my ab command:
01:53 < ming_zym> ab -i -k http://img08.taobaocdn.com/tps/i8/T1CNJHXd8BXXXXXXXX-40-40.jpg
01:53 < ming_zym> while that object is not cached in the TS.
01:58 < ming_zym> but I can not reproduce it on latest trunk, on another host
02:01 < ming_zym> error log show that requst have been send to OS, and a good response is returned back to TS
02:02 < ming_zym> is this just affect 2.1.4?
> possible misbehavior with HEAD request before GET
> -------------------------------------------------
>
> Key: TS-532
> URL: https://issues.apache.org/jira/browse/TS-532
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
> Environment: we have many haproxy before the TS server, do L7 hashing for all request
> Reporter: Zhao Yongming
> Priority: Trivial
> Attachments: 35425.cap, 434.cap, 8092.cap
>
>
> sometimes there is many HEAD request flood in, looks like cache in loop, but TS does not identify it as a loop.
> as the HEAD request will all pass to OS, that will make OS unable to response for sometime? get 1-5k connections, make TS get throttling.
> here is some tcpdum cap file
> why I suspect HEAD request, is when I ban all HEAD request use quick filter mask, the connection rush is gone.
> but this could be other problem indeed. just open this bug for logging.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.