[jira] [Commented] (TS-1590) use_remap_processor crashes if share_server_sessions = 2

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

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

Leif Hedstrom commented on TS-1590:
-----------------------------------

I suspect a refactoring of remap processor is required, to allow it to schedule the appropriate events back to the calling ET_NET (net-thread). There's no reason why the do_http_server_open() should have to happen on a remap thread. You are definitely spot on, there is no l1_hash on the remap processor threads... A real ugly solution would be to add that to them, but a better solution is to change the remap processor to handle the continuation back to an Net-thread before it needs the l1_hash.

I'm going to move this out to v3.5.0, unless I hear otherwise. I think it's somewhat reasonable to say that you have to set share_server_sessions to 0 or 1 if you really have to use the remap processor (which I don't know of anyone using).
                
> use_remap_processor crashes if share_server_sessions = 2
> --------------------------------------------------------
>
>                 Key: TS-1590
>                 URL: https://issues.apache.org/jira/browse/TS-1590
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 3.3.0
>            Reporter: Conan Wang
>            Priority: Critical
>             Fix For: 3.3.3
>
>
> easy to reproduce:
> {code}
> CONFIG proxy.config.remap.use_remap_processor INT 1   (default is 0)
> CONFIG proxy.config.http.share_server_sessions INT 2  (0, 1 will be ok)
> {code}
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000001210
> [Switching to process 8927 thread 0x1a03]
> 0x00000001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138, hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
> (gdb) bt
> #0  0x00000001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138, hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
> #1  0x00000001000eb366 in HttpSessionManager::acquire_session (this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19 "127.0.0.1", ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
> #2  0x0000000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0, raw=false) at HttpSM.cc:4384
> ......
> (gdb) p this_ethread()->l1_hash 
> $2 = (SessionBucket *) 0x0
> (gdb) p this_ethread()->event_types
> $3 = 2  (ET_REMAP)
> {code}
> Using separate remap processor is a hidden option, and I enable it by accident.. (Does anyone use it in prod?)
> I noticed HttpSM::do_http_server_open is always executed by the remap processer ethread (because of action.continuation->handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if wrong). While the remap thread was not initialized as ET_NET and has no l1_hash, server session lookup in this ET_REMAP thread will crash.
> I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on ET_NET. So a fast workaround would be falling back to global server connection when use_remap_processor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira