Now I see. Yes, you're right, if you use custom thread for writing
data - racing could happen.
To enable/disable IOEvent processing - please use
NIOConnection.enableIOEvent/disableIOEvent (IOEvent).
WBR,
Alexey.
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>