Thanks for the quick response. The race condition I mentioned could
actually occur between a Grizzly thread processing the IOEvent.READ and
an application thread installing the SSLFilter. Here is the sequence of
events:
1. App thread writes clear text response.
2. App thread installs SSLFilter.
3. Grizzly worker thread process the IOEvent.READ for the SSL handshake.
The race condition is between events 2 and 3. Is there a way to disable
reads for an connection to ensure the SSLFilter is installed? I guess I
could always write another filter to put in front of the SSLFilter to
enforce these semantics... Is that the best way to do this?
Thanks!
Bo
On 4/7/2010 3:20 AM, Oleksiy Stashok wrote:
> Hi Bo,
>
> there shouldn't be a problem.
> Only one thread at the time can process specific connection's event.
> So when you process IOEvent.READ - it's safe to do any changes and be
> sure that next IOEvent.READ processing will be started only after the
> current one will be completed.
>
> WBR,
> Alexey.
>
>
>> Hi Alaxey,
>>
>> I'm trying to implement LDAP StartTLS operation on the server side
>> and I'm running into a potential race condition. In LDAP, the client
>> initiates SSL/TLS with a StartTLS request in plain text. The server
>> then responds in plain text. If successful, the client initiates the
>> SSL handshake. Since responding in plain text and installing the
>> SSLFilter can not occur atomically, there is a potential race
>> condition. The client could start the SSL handshake before the
>> SSLFilter is installed. Is there a way to install the SSLFilter first
>> and bypass it for the last plain text response to the client?
>>
>> Thanks again
>> Bo
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>