[jira] [Comment Edited] (DIRAPI-310) We most certainly don't need a Queue in operation futures

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRAPI-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349626#comment-16349626 ] 

Emmanuel Lecharny edited comment on DIRAPI-310 at 2/2/18 1:22 AM:
------------------------------------------------------------------

We need to define two abstract classes, inheriting from a {{ResponseFuture}} interface :

* {{UniqueResponseFuture}} for operations that will always get one single response
* {{MultipleResponseFuture}} for operations that may get multiple responses ({{Bind}}, {{Extended}} and {{Search}})

For {{UniqueResponseFuture}}, we use a lock to protect the response setting,and a {{wait}}/{{notify}} to block the access to it.



was (Author: elecharny):
We need to define two abstract classes, inheriting from a {{ResponseFuture}} interface :

* {{UniqueResponseFuture}} for operations that will always get one single response
* {{MultipleResponseFuture}} for operations that may get multiple responses ({{Bind}}, {{Extended}} and {{Search}})
For {{UniqueResponseFuture}}, we use a lock to protect the response setting,and a {{wait}}/{{notify}} to block the access to it.


> We most certainly don't need a Queue in operation futures
> ---------------------------------------------------------
>
>                 Key: DIRAPI-310
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-310
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 1.0.0
>            Reporter: Emmanuel Lecharny
>            Priority: Major
>             Fix For: 2.0.0
>
>
> Currently, each operation future holds a {{BlockingQueue}} that will contain the response. This queue is stored in the inherited {{ResponseFuture}} class.
> This is a waste for most of the operation except {{SearchFuture}} and {{ExtendedFuture}} that might get more than one response. We could move the queue to the classes that nees it, and use a simple field for the other classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)