You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Bryan Call (JIRA)" <ji...@apache.org> on 2014/06/13 19:39:02 UTC

[jira] [Comment Edited] (TS-2887) Per-thread session pools don't work when mixing SSL with Non-SSL.

    [ https://issues.apache.org/jira/browse/TS-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030878#comment-14030878 ] 

Bryan Call edited comment on TS-2887 at 6/13/14 5:37 PM:
---------------------------------------------------------

I had a bug in our ticketing system tracking it.  It is good to have a Jira ticket on this issue.

We run a lot of our systems now with shared sessions set to 1 because of this.


was (Author: bcall):
I had a bug in our ticketing system tracking it.  It is good to have a Jira ticket on this issue.

> Per-thread session pools don't work when mixing SSL with Non-SSL.
> -----------------------------------------------------------------
>
>                 Key: TS-2887
>                 URL: https://issues.apache.org/jira/browse/TS-2887
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP, SSL
>            Reporter: Brian Geffon
>            Assignee: Brian Geffon
>
> (this might be a known issue; however, I couldn't find an existing ticket, if one exists please link to this).
> This bug is trivial to reproduce, if you set share_server_sessions to 2 (per thread session pools) and you connect to TS on an insecure port and connect outbound to a secure origin, ie: map http://127.0.1/ https://www.anything.com, it will not properly acquire a session and will always create a new one.
> It's clear why this happens: when release_session is called it happens from an ET_SSL thread; however, when acquire session is called it happens on an ET_NET thread. So all of the created sessions pile up on ET_SSL threads until they timeout and are closed.
> At this point I'm not entirely sure what a fix for this should look like.



--
This message was sent by Atlassian JIRA
(v6.2#6252)