[jira] [Updated] (TS-2945) balancer plugin forward to other port than 80
[ https://issues.apache.org/jira/browse/TS-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibault Marquand updated TS-2945: -- Description: The balancer plugin can't load-balance on others ports than 80. In documentation of the plugin, there is nothing about how to load-balance on others ports. Syntax in remap.config : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com @pparam=two.bar.com I obviously try this : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com:8080 @pparam=two.bar.com:8080 But ATS continues to hit on port 80 on my web server and in error.log I get this : status 502 (Connect Error ) for 'http://two.bar.com:8080/' was: The balancer plugin can't load-balancer on other ports than 80. In documentation of the plugin, there is nothing about how to load-balance on others ports. Syntax in remap.config : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com @pparam=two.bar.com I obviously try this : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com:8080 @pparam=two.bar.com:8080 But ATS continue to hit on port 80 on my web server and in error.log I get this : status 502 (Connect Error ) for 'http://two.bar.com:8080/' > balancer plugin forward to other port than 80 > - > > Key: TS-2945 > URL: https://issues.apache.org/jira/browse/TS-2945 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Thibault Marquand >Assignee: James Peach > Fix For: 5.1.0 > > > The balancer plugin can't load-balance on others ports than 80. > In documentation of the plugin, there is nothing about how to load-balance on > others ports. > Syntax in remap.config : > map http://foo.com http://foo.com @plugin=balancer.so > @pparam=--policy=hash,url @pparam=one.bar.com @pparam=two.bar.com > I obviously try this : > map http://foo.com http://foo.com @plugin=balancer.so > @pparam=--policy=hash,url @pparam=one.bar.com:8080 @pparam=two.bar.com:8080 > But ATS continues to hit on port 80 on my web server and in error.log I get > this : > status 502 (Connect Error ) for > 'http://two.bar.com:8080/' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2983:
--
Attachment: (was: TS-2983.diff)
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_
[jira] [Updated] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2983:
--
Attachment: TS-2983.diff
Modified the file to reenable protocol probe for http and disable it for https
connection per the discussion. If protocol probe for https is needed, it may
perhaps, be added via a separate jira (It did not seem obvious from the
description in TS-2751 that it was also adding probe support for SSL)
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQ
[jira] [Updated] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2983:
--
Attachment: (was: TS-2983.diff)
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_
[jira] [Commented] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090878#comment-14090878
]
Sudheer Vinukonda commented on TS-2983:
---
Turns out that enabling probe for http also may be corrupting the requests.
Apologies for the misinformation, I may not have run it long enough earlier.
The https corruption was happening so often that, it was clear within a minute,
but, the http issue seems to be happening with really low frequency (once/hour
or so) - this may also be due to the generally lower percentage of http
traffic on our host. Anyway, for now, turning off both http and https probe and
we are back to trying to find the root cause.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090878#comment-14090878
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 3:41 PM:
---
Turns out that enabling probe for http also may be corrupting the requests.
Apologies for the misinformation, I may not have run it long enough earlier.
The https corruption was happening so often that, it was clear within a minute,
but, the http issue seems to be happening with really low frequency (once/hour
or so) - this may also be due to the generally lower percentage of http
traffic on our host. Anyway, for now, turning off both http and https probe and
we are back to trying to find the root cause.
{code}
1407509742.113 0 207.178.224.170 ERR_CONNECT_FAIL 404 0 bS?Q?
MLrM???[?'?j?ni?? http://%00?%009%008%005%003%002%00%04%00/??%00
INVALID_CODE(3833167298291761197)/1 - - f1 f2 f3 f4
1407509742.113 0 207.178.224.170 ERR_CONNECT_FAIL 404 1713 bS?Q?
MLrM???[?'?j?ni?? http://%00?%009%008%005%003%002%00%04%00/??%00
INVALID_CODE(4770214920072593453)/1 - text/html f1 f2 f3 f4
{code}
was (Author: sudheerv):
Turns out that enabling probe for http also may be corrupting the requests.
Apologies for the misinformation, I may not have run it long enough earlier.
The https corruption was happening so often that, it was clear within a minute,
but, the http issue seems to be happening with really low frequency (once/hour
or so) - this may also be due to the generally lower percentage of http
traffic on our host. Anyway, for now, turning off both http and https probe and
we are back to trying to find the root cause.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCb
[jira] [Created] (TS-2994) Make use of SO_REUSEPORT socket option
Yunkai Zhang created TS-2994: Summary: Make use of SO_REUSEPORT socket option Key: TS-2994 URL: https://issues.apache.org/jira/browse/TS-2994 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang "One of the features merged in the 3.9 development cycle was TCP and UDP support for the SO_REUSEPORT socket option; that support was implemented in a series of patches by Tom Herbert. The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems." --[The SO_REUSEPORT socket option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2994: Fix Version/s: 6.0.0 > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091041#comment-14091041 ] Phil Sorber commented on TS-2994: - This combined with a proper event loop in the net thread accept logic would be a nice improvement. > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2995) Setting client connection TOS/DSCP field has no effect
Jack Bates created TS-2995:
--
Summary: Setting client connection TOS/DSCP field has no effect
Key: TS-2995
URL: https://issues.apache.org/jira/browse/TS-2995
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
{{proxy.config.net.sock_packet_tos_in}} has no effect if
{{proxy.config.accept_threads}} is not zero.
If it is zero then {{UnixNetProcessor::accept_internal()}} calls
{{NetAccept::init_accept_per_thread()}} which eventually calls
{{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
and {{IP_TOS}} socket options.
But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead calls
{{NetAccept::init_accept_loop()}} which eventually calls
{{NetAccept::do_blocking_accept()}}
One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
options from {{NetAccept::acceptFastEvent()}} to
{{NetAccept::do_blocking_accept()}}
{code}
--- a/iocore/net/UnixNetAccept.cc
+++ b/iocore/net/UnixNetAccept.cc
@@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
return -1;
}
+#if TS_HAS_SO_MARK
+ if (packet_mark != 0) {
+safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_cast(&
+ }
+#endif
+
+#if TS_HAS_IP_TOS
+ if (packet_tos != 0) {
+safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_cast(&p
+ }
+#endif
+
// Use 'NULL' to Bypass thread allocator
vc = (UnixNetVConnection *)this->getNetProcessor()->allocate_vc(NULL);
if (!vc) {
{code}
I tested this change and verified that {{proxy.config.net.sock_packet_tos_in}}
does correctly set the TOS/DSCP field.
This issue was reported by Jason Strongman on the users list
http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
{{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091123#comment-14091123 ] James Peach commented on TS-2994: - Make use of in what way? > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091121#comment-14091121
]
James Peach commented on TS-2983:
-
FWIW, I'm strongly -1 on disabling probing on SSL connections unless we have a
good explanation for the root cause of the problem. Once we have that, I'm
happy to discuss it further.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3L
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091157#comment-14091157 ] Phil Sorber commented on TS-2994: - [~jpe...@apache.org], For opening sockets in the accept per net thread operating mode. Right now we just share a file descriptor. > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091167#comment-14091167 ] James Peach commented on TS-2994: - Is multi-threaded accept a problem? What happens if you just dup(2) the socket? > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[
https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091225#comment-14091225
]
Phil Sorber commented on TS-2994:
-
>From the link in the description:
{quote}
The second of the traditional approaches used by multithreaded servers
operating on a single port is to have all of the threads (or processes) perform
an accept() call on a single listening socket in a simple event loop of the
form:
{code}
while (1) {
new_fd = accept(...);
process_connection(new_fd);
}
{code}
The problem with this technique, as Tom pointed out, is that when multiple
threads are waiting in the accept() call, wake-ups are not fair, so that, under
high load, incoming connections may be distributed across threads in a very
unbalanced fashion. At Google, they have seen a factor-of-three difference
between the thread accepting the most connections and the thread accepting the
fewest connections; that sort of imbalance can lead to underutilization of CPU
cores.
{quote}
> Make use of SO_REUSEPORT socket option
> --
>
> Key: TS-2994
> URL: https://issues.apache.org/jira/browse/TS-2994
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
>Reporter: Yunkai Zhang
> Fix For: 6.0.0
>
>
> "One of the features merged in the 3.9 development cycle was TCP and UDP
> support for the SO_REUSEPORT socket option; that support was implemented in a
> series of patches by Tom Herbert. The new socket option allows multiple
> sockets on the same host to bind to the same port, and is intended to improve
> the performance of multithreaded network server applications running on top
> of multicore systems." --[The SO_REUSEPORT socket
> option|http://lwn.net/Articles/542629/]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2996) Add consistent hashing method to parent selection
[ https://issues.apache.org/jira/browse/TS-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2996: Fix Version/s: 5.1.0 > Add consistent hashing method to parent selection > - > > Key: TS-2996 > URL: https://issues.apache.org/jira/browse/TS-2996 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2996) Add consistent hashing method to parent selection
Phil Sorber created TS-2996: --- Summary: Add consistent hashing method to parent selection Key: TS-2996 URL: https://issues.apache.org/jira/browse/TS-2996 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2996) Add consistent hashing method to parent selection
[ https://issues.apache.org/jira/browse/TS-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2996: --- Assignee: Phil Sorber > Add consistent hashing method to parent selection > - > > Key: TS-2996 > URL: https://issues.apache.org/jira/browse/TS-2996 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1800: Summary: Create one hashing infra that all can use (was: coalesce FNV hash implementations) > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2996) Add consistent hashing method to parent selection
[ https://issues.apache.org/jira/browse/TS-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091366#comment-14091366 ] ASF subversion and git services commented on TS-2996: - Commit 7fa5c5c7ae1837f0cc867924342e03cccb45b9f6 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7fa5c5c ] TS-2996: Add consistent hash method to parent selection > Add consistent hashing method to parent selection > - > > Key: TS-2996 > URL: https://issues.apache.org/jira/browse/TS-2996 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091365#comment-14091365 ] ASF subversion and git services commented on TS-2332: - Commit 123590fb30dec31a2c304fc41f49c81d33f1db21 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=123590f ] TS-2332: Add Consistent Hash Class > Add Consistent Hash class to libts > -- > > Key: TS-2332 > URL: https://issues.apache.org/jira/browse/TS-2332 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We may have a consistent hash implementation in the cluster code, but we > don't have a general one available to libts. We need one to implement a > consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091361#comment-14091361 ] ASF subversion and git services commented on TS-1800: - Commit 524f8d7579c53378053595d2428cc36ccb94273e in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=524f8d7 ] TS-1800: Add new hash function implementation of MD5 > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091360#comment-14091360 ] ASF subversion and git services commented on TS-1800: - Commit 709650eec623ebf842ddc9825b232c1f8cc6fe94 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=709650e ] TS-1800: Add new hash function implementation of FNV > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091362#comment-14091362 ] ASF subversion and git services commented on TS-1800: - Commit 5d0d6d8ba9490df9ce3da5064722f64ef373fedb in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5d0d6d8 ] TS-1800: Add new hash function implementation of SipHash > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2997) Collapse all FNV usage to new lib ts Hash class
Phil Sorber created TS-2997: --- Summary: Collapse all FNV usage to new lib ts Hash class Key: TS-2997 URL: https://issues.apache.org/jira/browse/TS-2997 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2997) Collapse all FNV usage to new lib ts Hash class
[ https://issues.apache.org/jira/browse/TS-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2997: Fix Version/s: sometime > Collapse all FNV usage to new lib ts Hash class > --- > > Key: TS-2997 > URL: https://issues.apache.org/jira/browse/TS-2997 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber > Fix For: sometime > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-1800. - Resolution: Implemented > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2332. - Resolution: Implemented > Add Consistent Hash class to libts > -- > > Key: TS-2332 > URL: https://issues.apache.org/jira/browse/TS-2332 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We may have a consistent hash implementation in the cluster code, but we > don't have a general one available to libts. We need one to implement a > consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2996) Add consistent hashing method to parent selection
[ https://issues.apache.org/jira/browse/TS-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2996. - Resolution: Implemented > Add consistent hashing method to parent selection > - > > Key: TS-2996 > URL: https://issues.apache.org/jira/browse/TS-2996 > Project: Traffic Server > Issue Type: New Feature >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2996) Add consistent hashing method to parent selection
[ https://issues.apache.org/jira/browse/TS-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2996: Issue Type: New Feature (was: Improvement) > Add consistent hashing method to parent selection > - > > Key: TS-2996 > URL: https://issues.apache.org/jira/browse/TS-2996 > Project: Traffic Server > Issue Type: New Feature >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1800) Create one hashing infra that all can use
[ https://issues.apache.org/jira/browse/TS-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1800: Issue Type: Improvement (was: Bug) > Create one hashing infra that all can use > - > > Key: TS-1800 > URL: https://issues.apache.org/jira/browse/TS-1800 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We have 4 copies of the FNV hash function: > example/query-remap/query-remap.c > iocore/hostdb/I_HostDBProcessor.h > proxy/hdrs/HdrToken.cc > proxy/logstats.cc > We should unify these into a single place in libts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091416#comment-14091416 ] ASF subversion and git services commented on TS-2357: - Commit 2158d61dc83d88c04204201d55d61005955c1bbd in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2158d61 ] TS-2357: Add option to cache POST requests > Add option to cache POST requests > - > > Key: TS-2357 > URL: https://issues.apache.org/jira/browse/TS-2357 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 5.1.0 > > Attachments: ts-2357.diff > > > This feature was added to YTS after it was open sourced. Yahoo bug number: > 2831983 > This is the configuration option and it might be nice to keep it the same > name for those that are migrating from YTS to ATS: > CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2998) sscl is occasionally zero
Scott Beardsley created TS-2998:
---
Summary: sscl is occasionally zero
Key: TS-2998
URL: https://issues.apache.org/jira/browse/TS-2998
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Scott Beardsley
Running ATS 5.0 it looks like sscl in the extended2.log is occasionally zero
even for cache misses and HTTP 200 reponses... Here is how I am finding these
cases:
tail -f extended2.log|awk '$23~/TCP_MISS/&&$11~/200/&&$12~/^0/{print
$10,$11,$12,$23,$7}'
21452 200 0 TCP_MISS http://search.example.com/search?p=pizza
You can see that pscl ($10) is non-zero but sscl ($12) is zero. Where is ats
getting the content from if it isn't coming from the origin? Is this related to
the value of the content-length header from the origin? Ideally we would want
to see the raw number of bytes coming from the origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2998) sscl is occasionally zero
[
https://issues.apache.org/jira/browse/TS-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091533#comment-14091533
]
Leif Hedstrom commented on TS-2998:
---
Strange. Could it be something with Content-Length vs Chunked?
> sscl is occasionally zero
> -
>
> Key: TS-2998
> URL: https://issues.apache.org/jira/browse/TS-2998
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Scott Beardsley
> Fix For: sometime
>
>
> Running ATS 5.0 it looks like sscl in the extended2.log is occasionally zero
> even for cache misses and HTTP 200 reponses... Here is how I am finding
> these cases:
> tail -f extended2.log|awk '$23~/TCP_MISS/&&$11~/200/&&$12~/^0/{print
> $10,$11,$12,$23,$7}'
> 21452 200 0 TCP_MISS http://search.example.com/search?p=pizza
> You can see that pscl ($10) is non-zero but sscl ($12) is zero. Where is ats
> getting the content from if it isn't coming from the origin? Is this related
> to the value of the content-length header from the origin? Ideally we would
> want to see the raw number of bytes coming from the origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2998) sscl is occasionally zero
[
https://issues.apache.org/jira/browse/TS-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2998:
--
Fix Version/s: sometime
> sscl is occasionally zero
> -
>
> Key: TS-2998
> URL: https://issues.apache.org/jira/browse/TS-2998
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Scott Beardsley
> Fix For: sometime
>
>
> Running ATS 5.0 it looks like sscl in the extended2.log is occasionally zero
> even for cache misses and HTTP 200 reponses... Here is how I am finding
> these cases:
> tail -f extended2.log|awk '$23~/TCP_MISS/&&$11~/200/&&$12~/^0/{print
> $10,$11,$12,$23,$7}'
> 21452 200 0 TCP_MISS http://search.example.com/search?p=pizza
> You can see that pscl ($10) is non-zero but sscl ($12) is zero. Where is ats
> getting the content from if it isn't coming from the origin? Is this related
> to the value of the content-length header from the origin? Ideally we would
> want to see the raw number of bytes coming from the origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2995) Setting client connection TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2995:
--
Fix Version/s: 5.1.0
> Setting client connection TOS/DSCP field has no effect
> --
>
> Key: TS-2995
> URL: https://issues.apache.org/jira/browse/TS-2995
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Jack Bates
> Fix For: 5.1.0
>
>
> {{proxy.config.net.sock_packet_tos_in}} has no effect if
> {{proxy.config.accept_threads}} is not zero.
> If it is zero then {{UnixNetProcessor::accept_internal()}} calls
> {{NetAccept::init_accept_per_thread()}} which eventually calls
> {{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
> and {{IP_TOS}} socket options.
> But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
> calls {{NetAccept::init_accept_loop()}} which eventually calls
> {{NetAccept::do_blocking_accept()}}
> One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
> options from {{NetAccept::acceptFastEvent()}} to
> {{NetAccept::do_blocking_accept()}}
> {code}
> --- a/iocore/net/UnixNetAccept.cc
> +++ b/iocore/net/UnixNetAccept.cc
> @@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
>return -1;
> }
>
> +#if TS_HAS_SO_MARK
> + if (packet_mark != 0) {
> +safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_cast *>(&
> + }
> +#endif
> +
> +#if TS_HAS_IP_TOS
> + if (packet_tos != 0) {
> +safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_cast *>(&p
> + }
> +#endif
> +
> // Use 'NULL' to Bypass thread allocator
> vc = (UnixNetVConnection *)this->getNetProcessor()->allocate_vc(NULL);
> if (!vc) {
> {code}
> I tested this change and verified that
> {{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
> This issue was reported by Jason Strongman on the users list
> http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
> {{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
> b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2995) Setting client connection TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091549#comment-14091549
]
Leif Hedstrom commented on TS-2995:
---
I haven't verified / reviewed the code, but it seems very reasonable that we
should function the same in both cases. Jack, you want to take this one? Good,
assigned it to you :).
> Setting client connection TOS/DSCP field has no effect
> --
>
> Key: TS-2995
> URL: https://issues.apache.org/jira/browse/TS-2995
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Jack Bates
> Fix For: 5.1.0
>
>
> {{proxy.config.net.sock_packet_tos_in}} has no effect if
> {{proxy.config.accept_threads}} is not zero.
> If it is zero then {{UnixNetProcessor::accept_internal()}} calls
> {{NetAccept::init_accept_per_thread()}} which eventually calls
> {{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
> and {{IP_TOS}} socket options.
> But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
> calls {{NetAccept::init_accept_loop()}} which eventually calls
> {{NetAccept::do_blocking_accept()}}
> One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
> options from {{NetAccept::acceptFastEvent()}} to
> {{NetAccept::do_blocking_accept()}}
> {code}
> --- a/iocore/net/UnixNetAccept.cc
> +++ b/iocore/net/UnixNetAccept.cc
> @@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
>return -1;
> }
>
> +#if TS_HAS_SO_MARK
> + if (packet_mark != 0) {
> +safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_cast *>(&
> + }
> +#endif
> +
> +#if TS_HAS_IP_TOS
> + if (packet_tos != 0) {
> +safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_cast *>(&p
> + }
> +#endif
> +
> // Use 'NULL' to Bypass thread allocator
> vc = (UnixNetVConnection *)this->getNetProcessor()->allocate_vc(NULL);
> if (!vc) {
> {code}
> I tested this change and verified that
> {{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
> This issue was reported by Jason Strongman on the users list
> http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
> {{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
> b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2995) Setting client connection TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2995:
--
Assignee: Jack Bates
> Setting client connection TOS/DSCP field has no effect
> --
>
> Key: TS-2995
> URL: https://issues.apache.org/jira/browse/TS-2995
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Jack Bates
>Assignee: Jack Bates
> Fix For: 5.1.0
>
>
> {{proxy.config.net.sock_packet_tos_in}} has no effect if
> {{proxy.config.accept_threads}} is not zero.
> If it is zero then {{UnixNetProcessor::accept_internal()}} calls
> {{NetAccept::init_accept_per_thread()}} which eventually calls
> {{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
> and {{IP_TOS}} socket options.
> But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
> calls {{NetAccept::init_accept_loop()}} which eventually calls
> {{NetAccept::do_blocking_accept()}}
> One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
> options from {{NetAccept::acceptFastEvent()}} to
> {{NetAccept::do_blocking_accept()}}
> {code}
> --- a/iocore/net/UnixNetAccept.cc
> +++ b/iocore/net/UnixNetAccept.cc
> @@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
>return -1;
> }
>
> +#if TS_HAS_SO_MARK
> + if (packet_mark != 0) {
> +safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_cast *>(&
> + }
> +#endif
> +
> +#if TS_HAS_IP_TOS
> + if (packet_tos != 0) {
> +safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_cast *>(&p
> + }
> +#endif
> +
> // Use 'NULL' to Bypass thread allocator
> vc = (UnixNetVConnection *)this->getNetProcessor()->allocate_vc(NULL);
> if (!vc) {
> {code}
> I tested this change and verified that
> {{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
> This issue was reported by Jason Strongman on the users list
> http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
> {{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
> b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091596#comment-14091596 ] James Peach commented on TS-2950: - Is this done, or are you still working on build integration? > Import libck to libts for atomics and concurrent data structures > > > Key: TS-2950 > URL: https://issues.apache.org/jira/browse/TS-2950 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.2.0 > > > We want to import libck to replace our atomics and concurrent data structures. > We would preferably like to build against an OS supplied version, but will > import ourselves until it is more ubiquitous. > https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2950: Fix Version/s: (was: 5.2.0) 5.1.0 > Import libck to libts for atomics and concurrent data structures > > > Key: TS-2950 > URL: https://issues.apache.org/jira/browse/TS-2950 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We want to import libck to replace our atomics and concurrent data structures. > We would preferably like to build against an OS supplied version, but will > import ourselves until it is more ubiquitous. > https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2950) Import libck to libts for atomics and concurrent data structures
[ https://issues.apache.org/jira/browse/TS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2950. - Resolution: Implemented I was going to do more on this ticket, but I guess technically it is building now, so I can do more in separate tickets. > Import libck to libts for atomics and concurrent data structures > > > Key: TS-2950 > URL: https://issues.apache.org/jira/browse/TS-2950 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.1.0 > > > We want to import libck to replace our atomics and concurrent data structures. > We would preferably like to build against an OS supplied version, but will > import ourselves until it is more ubiquitous. > https://cwiki.apache.org/confluence/display/TS/Import+ConcurrecyKit+for+atomics+and+containers -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2362: Attachment: ts-2362.diff > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: Review > Fix For: 5.1.0 > > Attachments: ts-2362.diff > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2362: Attachment: (was: ts-2362.diff) > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: Review > Fix For: 5.1.0 > > Attachments: ts-2362.diff > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091632#comment-14091632 ] Alan M. Carroll commented on TS-2362: - Updated patch. Should work for all caches from 3.2.0 to 5.1. In addition to the backwards compatibility, per object version data was added to provide easier forward compatibility in the future. The cache version was bumped but that should not cause loss of cache because it's now backwards compatible! The basic fragment / doc type was changed so that prior formats (without per object version data) are easily distinguished without the cost of format guessing heuristics. The latter are used only when the stripe is indicated to be a back version. > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: Review > Fix For: 5.1.0 > > Attachments: ts-2362.diff > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2994) Make use of SO_REUSEPORT socket option
[ https://issues.apache.org/jira/browse/TS-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091653#comment-14091653 ] Yunkai Zhang commented on TS-2994: -- Yes, the description from the link is clear enough for why we should make use of it:). And we have tested this option in Nginx, it can avoid *thundering herd* thoroughly, and play excellent performance on accepting connections. > Make use of SO_REUSEPORT socket option > -- > > Key: TS-2994 > URL: https://issues.apache.org/jira/browse/TS-2994 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Yunkai Zhang > Fix For: 6.0.0 > > > "One of the features merged in the 3.9 development cycle was TCP and UDP > support for the SO_REUSEPORT socket option; that support was implemented in a > series of patches by Tom Herbert. The new socket option allows multiple > sockets on the same host to bind to the same port, and is intended to improve > the performance of multithreaded network server applications running on top > of multicore systems." --[The SO_REUSEPORT socket > option|http://lwn.net/Articles/542629/] -- This message was sent by Atlassian JIRA (v6.2#6252)
