[
https://issues.apache.org/jira/browse/TS-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372190#comment-14372190
]
Susan Hinrichs commented on TS-3456:
------------------------------------
Got the Tsung environment running. I think I'm seeing the error now. In the
tsung.log do you get counts for error_unknown?
Thought I had a solution. It seems like the SSLNetVC version of reenable ought
to reset the reenable flag as well like the UnixNetVConnection version does.
However, once I "tidied up" my solution the error_unknown's returned. I must
head out until later this weekend. Hopefully, we can get you a solution to try
then.
Alan also mentioned that another person had to "patch the core" to get their
SSL plugins working. He's reaching out to that person for details.
> 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)
