[jira] [Commented] (TS-3061) API: Cached URL MLocs prevent the HttpSM from detecting Url Changes.

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

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

Leif Hedstrom commented on TS-3061:
-----------------------------------

How long is the plugin caching the MLoc / MBuf? I'm fairly certain that you can *not* keep those beyond the point of enabling the continuation. This is as per design, because after you enable the continuation, all sorts of changes can happen to the marshall buffers etc.

The point being, IF your API "caches" the MBuf before enabling the continuation, and you modify the URL, can't you detect the "dirtiness" within your APIs? I.e. if your setters modifies something that would have marked the URL dirty, on the next getter you simply force it to reload?



> API: Cached URL MLocs prevent the HttpSM from detecting Url Changes.
> --------------------------------------------------------------------
>
>                 Key: TS-3061
>                 URL: https://issues.apache.org/jira/browse/TS-3061
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core, CPP API, TS API
>            Reporter: Brian Geffon
>            Assignee: Brian Geffon
>
> The HttpSM contains a cached version of the client request url to avoid re-generating strings repeatedly. The problem is that if a plugin caches the MLoc and MBuf they can modify the URL without the cached copy being updated. Unfortunantely, moving the dirty flag into UrlImpl would be incredibly messy, so I will propose that after api callouts are complete we mark the cached url as dirty. It seems like the only reasonable approach that has minimal performance impact while maintaining the caching.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)