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
