[jira] Closed: (DIRSEDA-5) Race condition between connect and input events

[ji...@apache.org]

Message:

   The following issue has been closed.

   Resolver: Alex Karasulu
       Date: Thu, 16 Sep 2004 12:04 AM

We were able to synchronize on the decoders map to guarantee that the ConnectEvent processing thread completes before the first InputEvent is processed.  Fixes have been committed to the DefaultDecoderManager in revision 46164.
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIRSEDA-5

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIRSEDA-5
    Summary: Race condition between connect and input events
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Seda Framework

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Wed, 15 Sep 2004 11:40 PM
    Updated: Thu, 16 Sep 2004 12:04 AM

Description:
When a client connects it causes a ConnectEvent to be published by the listener thread that accepts the new client connection.  This event's synchronous delivery drives the creation of stateful encoders and decoders in the EncoderManager and DecoderManager respectively.  These encoders and decoders are used to process input.

When a client sends input the InputManager sends out an InputEvent to be processed by the decoder.  Turns out sometimes a fast client can deliver the first chunk of input and hence an InputEvent before a ConnectEvent's processing is complete.  Both the ConnectEvent and the InputEvent handling occur in separate threads.  We must make sure ConnectEvent processing is complete before allowing InputEvent processing to proceed for a client.

Right off the top of my head a quick way to deal might be to wait a certain amount of time and check if the affects of ConnectEvent processing have occurred.  Namely wait until a client decoder is available which is the case once the ConnectEvent is processed by the DefaultDecoderManager.  Or better yet we can wait on the decoder map to be awaken when it is altered if it does not contain the decoder for the client.  The inform method can notify all on the decoder map after it has put the client decoder into the map.  Yes this is perhaps the best way for now to perform this synchronization.  


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira