The other diagram possibly had a consumer order issue. While the Queue
will guarantee that the messages will be pulled out of the Queue in order,
they do not guarantee that the processing of the messages will happen in
order.
The new diagram implements 3 synchronization objects. This will
Emmanuel,
The attached diagram is how I figured out we can solve this. The downside
is that it requires more concurrent queues and more lock/unlock but I think
it should ensure correct execution order.
I’m working on this now as SSLHandlerG1 so it stays separate from the
reference
Hi Jonathan,
I don'ty exclude we could also solve the issue by tweeking the
StateMachine filter. For instance, do we really need to take a lock
while processing the SessionOpened in the SM Filter?
I'm not very into the SM filter code, I have to study it, but that would
potentially save you
