Yes, that looks like exactly the same issue.
On 1/16/2015 9:15 AM, Leif Hedstrom wrote:
On Jan 16, 2015, at 6:49 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
Turns out others have been having problems here too. Yu Zou has a fix for
something in this area via bug TS-3140.
That fix addresses part of my issues, but I have a couple more resources to
free. I'll take over his bug and add my fixes to his.
Hi Susan,
could this at all also be related to this JIRA:
https://issues.apache.org/jira/browse/TS-3217
— Leif
On 1/15/2015 8:36 PM, Susan Hinrichs wrote:
Has anyone used redirection_enabled recently (in the last couple years?). I'm
debugging an ink_release_assert reported by someone running in production. But
when I run even the most basic 301 through it in debug mode, I get ink_asserts
in HttpSM::state_cache_open_read(). It is checking that server_entry == NULL
before it assigns server_entry.
In production mode, these asserts are ignored, and the server data structures
set up when talking to the original server are overwritten and presumably
leaking memory. There is logic that sets t_state.api_release_server_session
which should later cause release_server_session() to be called. The flag is
set, but release_server_session() is never called.
I did most of my testing on variants of 5.x. But Alan had 4.2.x and 3.2.x
builds laying around, and we see the same asserts on those builds as well.
I assume the logic leading to the cleanup call got messed up somewhere along
the way. But since it has been that way for so long, perhaps we are not
setting up the redirect_enabled correctly or missing something else obvious.
Please let me know of you are actively using this feature successfully.
Thanks,
Susan
