[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886375#comment-13886375
]
Yunkai Zhang edited comment on TS-2431 at 1/30/14 8:18 AM:
-----------------------------------------------------------
[~jamespeach], [~briang]:
I read the IRC log, and found the following conversation:
{code}
07:26 <@jpeach> briangef: I don't like all the API changes to TSFetch
07:27 <@briangef> jpeach, I agree.
07:28 <@briangef> TSFetchUrl is very important to me because it's something I
use quite a bit
07:28 <@briangef> I think the correct approach is to create a new API and then
slowly deprecate TSFetch
07:28 <@jpeach> I don't see the need to make TSFetchUrl more like TSHttpConnect
when we already have TSHttpConnect
07:28 <@briangef> Exactly.
07:28 <@briangef> Infact TSFetchUrl is just a crappy wrapper on TSHttpConnect
07:29 <@briangef> so just create a new API
07:29 <@briangef> I think TSFetchUrl shouldn't be touched and you should just
create an easier to use wrapper on TSHttpConnect
07:29 <@jpeach> agreed; TSHttpConnect is the right building block
07:30 <@briangef> meeting, back in a bit
08:55 <@jpeach> briangef: are you also reviewing yunkai's SPDY patches?
{code}
Were you talking about this ticket?
If yes, I must remind that my patch DON'T do any changes on TSFetchUrl() API.
As I mentioned early, one of principle of these patches is to keep backward
compatibility, so it wound't change any original APIs. I have described this
principle in the commit log of
{{0003-TS-2431-Extends-and-optimizes-FetchSM.V3.patch}}
{code}
>From 9a8e2e8a5c1eff0bac483aeb5d4067be9834d7a2 Mon Sep 17 00:00:00 2001
From: Yunkai Zhang <[email protected]>
Date: Fri, 10 Jan 2014 15:33:07 +0800
Subject: [PATCH V3 03/14] TS-2431: Extends and optimizes FetchSM
* This patch should keep FetchSM's backward compatibility.
* Optimize FetchSM to support stream IO.
* Reduce memory copy in FetchSM.
* Expose some plugin APIs.
....
Signed-off-by: Yunkai Zhang <[email protected]>
{code}
was (Author: yunkai):
[~jamespeach], [~briang]:
I read the IRC log, and found the following conversation:
{code}
07:26 <@jpeach> briangef: I don't like all the API changes to TSFetch
07:27 <@briangef> jpeach, I agree.
07:28 <@briangef> TSFetchUrl is very important to me because it's something I
use quite a bit
07:28 <@briangef> I think the correct approach is to create a new API and then
slowly deprecate TSFetch
07:28 <@jpeach> I don't see the need to make TSFetchUrl more like TSHttpConnect
when we already have TSHttpConnect
07:28 <@briangef> Exactly.
07:28 <@briangef> Infact TSFetchUrl is just a crappy wrapper on TSHttpConnect
07:29 <@briangef> so just create a new API
07:29 <@briangef> I think TSFetchUrl shouldn't be touched and you should just
create an easier to use wrapper on TSHttpConnect
07:29 <@jpeach> agreed; TSHttpConnect is the right building block
07:30 <@briangef> meeting, back in a bit
08:55 <@jpeach> briangef: are you also reviewing yunkai's SPDY patches?
{code}
Were you talking about this ticket?
If yes, I must remind that my patch DON'T do any changes on TSFetchUrl() API.
As I mentioned early, one of principle of these patches is to keep backward
compatibility, so it wound't change any original APIs.
> Add SPDY supporting to ATS
> --------------------------
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
> Reporter: Yunkai Zhang
> Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Preparation-of-SPDY-protocol.V3.patch,
> 0002-TS-2431-Add-autoconf-options-for-SPDY.V3.patch,
> 0003-TS-2431-Extends-and-optimizes-FetchSM.V3.patch,
> 0004-TS-2431-Implement-dechunk-supporting-in-FetchSM.V3.patch,
> 0005-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V3.patch,
> 0006-TS-2431-Add-SSL-supporting-for-SPDY.V3.patch,
> 0007-TS-2431-Set-proto_type-properly-for-HttpSM.V3.patch,
> 0008-TS-2431-Add-client_req_proto_type-cqpt-field-into-lo.V3.patch,
> 0009-TS-2431-Close-SPDY-request-when-SPDY-is-not-endabled.V3.patch,
> 0010-TS-2431-Fix-infinite-loop-when-reading-the-fist-byte.V3.patch,
> 0011-TS-2431-Fix-dechunking-on-FetchSM-s-response-data.V3.patch,
> 0012-TS-2431-Set-the-water-mark-of-resp_buffer-with-INT64.V3.patch,
> 0013-TS-2431-Set-eof-flag-to-prevent-spdy-client-hang.V3.patch,
> 0014-TS-2431-Ignore-fetch-errors-after-FETCH_BODY_DONE.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=<dir>' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
> The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
