[
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)
