[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385008#comment-14385008 ] portl4t commented on TS-1611: - 1. Well, I think it is ok to use TSError instead of ee, although I prefer to record error message in traffic.out with ee. 2. There is no backward incompatibility, old scripts also work. 3. ts.fetch is definitely non-block, it will invoke lua_yield to release cpu after launching the FetchSM, and will excute the next lua line with lua_resume after FetchSM finished. ts.sleep uses the same mechanism. 4. Streaming mode is hard to display in the script, I am working on ts.cache_read these days, which has the same problem. I think we can implement streaming mode with an option if it is necessary. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3469) Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR
[
https://issues.apache.org/jira/browse/TS-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384747#comment-14384747
]
Sudheer Vinukonda commented on TS-3469:
---
Hmm..how can {{SEND_RESPOSNE_HDR_HOOK}} get called more than once for a given
txn? If it does, that sounds like a bug?
> Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR
> -
>
> Key: TS-3469
> URL: https://issues.apache.org/jira/browse/TS-3469
> Project: Traffic Server
> Issue Type: Improvement
> Components: Documentation
>Reporter: Scott Beardsley
>Assignee: Alan M. Carroll
>
> We ran into a problem where SEND_RESPONSE_HDR was being called multiple times
> leading to a crash. The docs are unclear on this point so we should update
> them to reflect this intermittent case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3469) Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR
[ https://issues.apache.org/jira/browse/TS-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-3469: --- Assignee: Alan M. Carroll > Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR > - > > Key: TS-3469 > URL: https://issues.apache.org/jira/browse/TS-3469 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Scott Beardsley >Assignee: Alan M. Carroll > > We ran into a problem where SEND_RESPONSE_HDR was being called multiple times > leading to a crash. The docs are unclear on this point so we should update > them to reflect this intermittent case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3469) Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR
Scott Beardsley created TS-3469: --- Summary: Update plugin docs to reflect multiple calls to SEND_RESPONSE_HDR Key: TS-3469 URL: https://issues.apache.org/jira/browse/TS-3469 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Scott Beardsley We ran into a problem where SEND_RESPONSE_HDR was being called multiple times leading to a crash. The docs are unclear on this point so we should update them to reflect this intermittent case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384623#comment-14384623 ] Kit Chan commented on TS-1611: -- [~portl4t] pls take a look at my comment. Thanks. > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3468) Fix command line stripe inspector
[
https://issues.apache.org/jira/browse/TS-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384612#comment-14384612
]
Alan M. Carroll commented on TS-3468:
-
My original plan was to do this as a stand alone with an eye to integrating in
to traffic_ctl but there was already some base logic in traffic_server so I
used that. I think there's value in having this be stand-alone / traffic_ctl
but it's a non-trivial amount of work. It may be possible to do this in the
live traffic_server.
> Fix command line stripe inspector
> -
>
> Key: TS-3468
> URL: https://issues.apache.org/jira/browse/TS-3468
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Console
>Reporter: Alan M. Carroll
>
> There is currently a {{--command check}} command line option for
> {{traffic_server}} but it doesn't work and provides little useful
> information. It should be fixed so that
> * It works
> * It provides useful diagnostic information
> * It is available on a live system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1611) async http request in lua remap plugin
[ https://issues.apache.org/jira/browse/TS-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384598#comment-14384598 ] Kit Chan commented on TS-1611: -- 1) Should we use TSError instead of ee() for reporting error? 2) Am I correct that there is no backward incompatibility? There are additional API such as fetch and fetch_multi. And then there are enhancements to existing api (transform/intercept). But those enhancements are backward compatible. Right? 3) Are all the fetch api blocking? Of course I have to wait for the response to come back before the next lua line is executed. But during the wait, do we no longer hold onto the thread so it can go and execute other stuff? 4) The fetch api (essesntialy using TSFetch* TS apis) does not seem to support streaming mode. Do you think it is necessary to support that or not? I have compiled and run your test example lua scripts. I also run my own application for a short while without problem. I think if we clarify the questions I have above, it should be good to be merged. Only stuff I need to do is just to run it through clang-format before committing. Thanks > async http request in lua remap plugin > -- > > Key: TS-1611 > URL: https://issues.apache.org/jira/browse/TS-1611 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Luca Rea >Assignee: Kit Chan > Fix For: sometime > > Attachments: > 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch, > 0002-TS-1611-add-ts_lua_constant.c.patch, > 0003-TS-1611-refine-doc-for-ts_lua.patch > > > Hi, > can you add support for async http requests in lua remap plugin please? > Thank you -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3468) Fix command line stripe inspector
[
https://issues.apache.org/jira/browse/TS-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384435#comment-14384435
]
James Peach commented on TS-3468:
-
Would this make sense for {{traffic_ctl}}?
> Fix command line stripe inspector
> -
>
> Key: TS-3468
> URL: https://issues.apache.org/jira/browse/TS-3468
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Console
>Reporter: Alan M. Carroll
>
> There is currently a {{--command check}} command line option for
> {{traffic_server}} but it doesn't work and provides little useful
> information. It should be fixed so that
> * It works
> * It provides useful diagnostic information
> * It is available on a live system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3468) Fix command line stripe inspector
Alan M. Carroll created TS-3468:
---
Summary: Fix command line stripe inspector
Key: TS-3468
URL: https://issues.apache.org/jira/browse/TS-3468
Project: Traffic Server
Issue Type: Bug
Components: Cache, Console
Reporter: Alan M. Carroll
There is currently a {{--command check}} command line option for
{{traffic_server}} but it doesn't work and provides little useful information.
It should be fixed so that
* It works
* It provides useful diagnostic information
* It is available on a live system
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created
[ https://issues.apache.org/jira/browse/TS-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3456: --- Attachment: ts-3456-2.diff ts-3456-2.diff includes Lev's fix plus a thread check to do the direct reenable if the calling thread is the same as the sslvc thread. [~lstipakov] could you give this variant a try in your environment? If it works, I'll commit this. > SSL blind tunnel sometimes not created > --- > > Key: TS-3456 > URL: https://issues.apache.org/jira/browse/TS-3456 > Project: Traffic Server > Issue Type: Bug > Components: Plugins, SSL >Reporter: Lev Stipakov >Assignee: Susan Hinrichs > Fix For: 6.0.0 > > Attachments: ts-3456-2.diff, ts-tls.cc > > > Hello, > I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a > blind tunnel from a separate thread. With low load everything works > fine, but with moderate load (100 simultaneous users, each user sends > 200 HTTPS requests) I see somewhat strange behavior. > On a client side I use Tsung, which creates users and sends number of > requests per user. For each user Tsung waits for a response before > sending a new request, so if response never arrives, a particular user > (and the whole test) stalls. > So, with load mentioned above I see few 'stalled' connections on both > client and proxy – netstat shows them as ”established”, ATS seems to > have data structures for those (checked > proxy.process.net.connections_currently_open value), but no traffic > goes between proxy and client. > Client side (.175): > tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp > (more similar connections here) > Proxy side (.250 is a server): > tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve > (more similar connections here) > I checked traffic.out log and found out that > ”SSLNextProtocolAccept:mainEvent” does not get called as many times as > it should. This can probably be explained by the fact that client does > not send requests for given user anymore if response to previous > request hasn't been received. Which, in turn, may indicate that at > some point tunnel has not been created. > The interesting thing is that everything works fine if a tunnel is > created directly from TS_SSL_SNI_HOOK but not from the separate > thread. > The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a > thread with TSThreadCreate. When hook got called, I push TSVConn to a > thread-safe queue. The thread wakes up when item has been pushed, > calls TSVConnTunnel / TSVConnReenable for given vconn and then waits > for the next item. I have attached the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3456) SSL blind tunnel sometimes not created
[ https://issues.apache.org/jira/browse/TS-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382822#comment-14382822 ] Susan Hinrichs edited comment on TS-3456 at 3/27/15 6:22 PM: - [~amc] and I talked about this a bit this morning. With your change and previous observations, it seems likely that the problem is due to some faulty locking on the queue associated with the nethandler. The vast majority of the time a single thread is working with a nethandler's queue. But in this case, the direct reenable would have another thread add/remove items on the nethandler's queue. In the short term, we should commit a variant of Lev's fix. In addition, we should add a thread check and do the direct reenable if the current thread is the same as the ssl_vc->thread and the code was able to acquire the code. In Lev's separate thread case it would always do the schedule_imm to get back on the original thread. I can put up another patch tomorrow or later this evening for Lev to verify. In the longer term, we should discuss this issue at the ApacheCon Summit. I don't think any of us fully understand the details of the threading and locking requirements. We should at least pool our knowledge and perhaps do some organized investigation to clarify. was (Author: shinrich): [~amc] and I talked about this a bit this morning. With your change and previous observations, it seems clear that the problem is due to some faulty locking on the queue associated with the nethandler. The vast majority of the time a single thread is working with a nethandler's queue. But in this case, the direct reenable would have another thread add/remove items on the nethandler's queue. In the short term, we should commit a variant of Lev's fix. In addition, we should add a thread check and do the direct reenable if the current thread is the same as the ssl_vc->thread and the code was able to acquire the code. In Lev's separate thread case it would always do the schedule_imm to get back on the original thread. I can put up another patch tomorrow or later this evening for Lev to verify. In the longer term, we should discuss this issue at the ApacheCon Summit. I don't think any of us fully understand the details of the threading and locking requirements. We should at least pool our knowledge and perhaps do some organized investigation to clarify. > SSL blind tunnel sometimes not created > --- > > Key: TS-3456 > URL: https://issues.apache.org/jira/browse/TS-3456 > Project: Traffic Server > Issue Type: Bug > Components: Plugins, SSL >Reporter: Lev Stipakov >Assignee: Susan Hinrichs > Fix For: 6.0.0 > > Attachments: ts-tls.cc > > > Hello, > I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a > blind tunnel from a separate thread. With low load everything works > fine, but with moderate load (100 simultaneous users, each user sends > 200 HTTPS requests) I see somewhat strange behavior. > On a client side I use Tsung, which creates users and sends number of > requests per user. For each user Tsung waits for a response before > sending a new request, so if response never arrives, a particular user > (and the whole test) stalls. > So, with load mentioned above I see few 'stalled' connections on both > client and proxy – netstat shows them as ”established”, ATS seems to > have data structures for those (checked > proxy.process.net.connections_currently_open value), but no traffic > goes between proxy and client. > Client side (.175): > tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp > (more similar connections here) > Proxy side (.250 is a server): > tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve > (more similar connections here) > I checked traffic.out log and found out that > ”SSLNextProtocolAccept:mainEvent” does not get called as many times as > it should. This can probably be explained by the fact that client does > not send requests for given user anymore if response to previous > request hasn't been received. Which, in turn, may indicate that at > some point tunnel has not been created. > The interesting thing is that everything works fine if a tunnel is > created directly from TS_SSL_SNI_HOOK but not from the separate > thread. > The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a > thread with TSThreadCreate. When hook got called, I push TSVConn to a > thread-safe queue. The thread wakes up when item has been pushed, > calls TSVConnTunnel / TSVConnReenable for given vconn and then waits > for the next item. I have attached the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created
[ https://issues.apache.org/jira/browse/TS-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3456: --- Attachment: (was: ts-3456.diff) > SSL blind tunnel sometimes not created > --- > > Key: TS-3456 > URL: https://issues.apache.org/jira/browse/TS-3456 > Project: Traffic Server > Issue Type: Bug > Components: Plugins, SSL >Reporter: Lev Stipakov >Assignee: Susan Hinrichs > Fix For: 6.0.0 > > Attachments: ts-tls.cc > > > Hello, > I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a > blind tunnel from a separate thread. With low load everything works > fine, but with moderate load (100 simultaneous users, each user sends > 200 HTTPS requests) I see somewhat strange behavior. > On a client side I use Tsung, which creates users and sends number of > requests per user. For each user Tsung waits for a response before > sending a new request, so if response never arrives, a particular user > (and the whole test) stalls. > So, with load mentioned above I see few 'stalled' connections on both > client and proxy – netstat shows them as ”established”, ATS seems to > have data structures for those (checked > proxy.process.net.connections_currently_open value), but no traffic > goes between proxy and client. > Client side (.175): > tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp > (more similar connections here) > Proxy side (.250 is a server): > tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve > (more similar connections here) > I checked traffic.out log and found out that > ”SSLNextProtocolAccept:mainEvent” does not get called as many times as > it should. This can probably be explained by the fact that client does > not send requests for given user anymore if response to previous > request hasn't been received. Which, in turn, may indicate that at > some point tunnel has not been created. > The interesting thing is that everything works fine if a tunnel is > created directly from TS_SSL_SNI_HOOK but not from the separate > thread. > The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a > thread with TSThreadCreate. When hook got called, I push TSVConn to a > thread-safe queue. The thread wakes up when item has been pushed, > calls TSVConnTunnel / TSVConnReenable for given vconn and then waits > for the next item. I have attached the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2515) Create stat for when ATS wrapped around on disk cache cleanup
[ https://issues.apache.org/jira/browse/TS-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384029#comment-14384029 ] ASF GitHub Bot commented on TS-2515: Github user SolidWallOfCode closed the pull request at: https://github.com/apache/trafficserver/pull/175 > Create stat for when ATS wrapped around on disk cache cleanup > - > > Key: TS-2515 > URL: https://issues.apache.org/jira/browse/TS-2515 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Metrics >Reporter: Bryan Call >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > Create a stat for the last time ATS wrapped around on cleaning up the disk > cache. > This can be implemented with two stats the last time it wrapped and the time > difference between the last two wraps. This would give an idea of how often > the cache does wrap around. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2515) Create stat for when ATS wrapped around on disk cache cleanup
[ https://issues.apache.org/jira/browse/TS-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384028#comment-14384028 ] ASF GitHub Bot commented on TS-2515: Github user SolidWallOfCode commented on the pull request: https://github.com/apache/trafficserver/pull/175#issuecomment-86981259 Ccommit d22cdccd2c8f082d73a616165752a665f76e9890 > Create stat for when ATS wrapped around on disk cache cleanup > - > > Key: TS-2515 > URL: https://issues.apache.org/jira/browse/TS-2515 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Metrics >Reporter: Bryan Call >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > Create a stat for the last time ATS wrapped around on cleaning up the disk > cache. > This can be implemented with two stats the last time it wrapped and the time > difference between the last two wraps. This would give an idea of how often > the cache does wrap around. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
