It's unclear to me that you wouldn't get better NUMA affinity with the
migration. The logic spends much more time messing with the IOBuffers than with
the socket buffers and if the socket is migrated the IOBuffers will be thread
local whereas currently they are not. That is, IOBuffers for server data are in
a different thread than the HttpSM so actions such as servicing READ_READY
events from the user agent are crossing thread boundaries.
On Friday, July 24, 2015 8:27 AM, Susan Hinrichs
<shinr...@network-geographics.com> wrote:
On 7/24/2015 2:11 AM, Leif Hedstrom wrote:
>> On Jul 24, 2015, at 3:16 AM, Susan Hinrichs
>> <shinr...@network-geographics.com> wrote:
>>
>> Hello,
>>
>> Another latent cross-thread race condition has become very active in our
>> environment (TS-3797). Given that we just spent time within the last month
>> squashing another cross thread race condition (TS-3486) that was active in
>> several environments, Alan and I would like to step back and try to reduce
>> the cross thread impact of the global session pools.
>>
>> I wrote up our thoughts and plan for implementation. Given that threading
>> and race conditions are always tricky, I'd appreciate more eyes looking for
>> flaws in our approach or suggestions for alternatives.
>>
>> https://cwiki.apache.org/confluence/display/TS/Threading+Issues+And+NetVC+Migration
>
>
> My gut reaction to this is that this makes our efforts for NUMA / thread
> affinity very, very difficult to achieve. The goal is to avoid memory
> migrating cross NUMA sockets, to avoid QPI traffic. This would encourage the
> opposite unless I misread it ? It also obviously violates the original design
> goals, where VCs do *not* migrate.
>
> It’d be very interesting to hear from John Plevyak and what their initial
> design had considered for these issues?
>
> Cheers,
>
> — Leif
>
Leif,
Thanks for the pointers to the historical precedence. I'll look over
them this morning.
I will think more into NUMA issues as well. I had been focusing on
reducing thread cross-talk and associated possibility for errors. I
thought this solution was all good since a new net VC is created in the
target thread and the socket and SSL object are copied over. But upon
reflection, I realize that there are buffers associated with the socket
and the SSL object.
Susan
