[jira] [Commented] (DIRMINA-777) IoSessionConfig.setUseReadOperation(true) doesn't seem to work

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

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

Emmanuel Lecharny commented on DIRMINA-777:
-------------------------------------------

Not sure the readFuture mechanism is working at all. first, we create the ReadFuture queue on the fly, with no synchonization :

{code}
    private ReadFuture newReadFuture() {
        Queue<ReadFuture> readyReadFutures = getReadyReadFutures();
        ...

    private Queue<ReadFuture> getReadyReadFutures() {
        Queue<ReadFuture> readyReadFutures = (Queue<ReadFuture>) getAttribute(READY_READ_FUTURES_KEY);
        if (readyReadFutures == null) {
            readyReadFutures = new ConcurrentLinkedQueue<ReadFuture>();

            Queue<ReadFuture> oldReadyReadFutures = (Queue<ReadFuture>) setAttributeIfAbsent(READY_READ_FUTURES_KEY,
                    readyReadFutures);
            if (oldReadyReadFutures != null) {
                readyReadFutures = oldReadyReadFutures;
            }
        }
        return readyReadFutures;
    }
{code}

and second, I don't even see what it could be used for. We generate ReadFuture containing either the received message, or an exception or a close event. All those elements will be received by the Handler anyway. 

I think it puts a lot of burden on the shoulder of an implementer for a little benefit.

At the very minimum, I would suggest we rethink the whole mechanism in MINA 3, and avoid trying to fix that in MINA 2.

> IoSessionConfig.setUseReadOperation(true) doesn't seem to work
> --------------------------------------------------------------
>
>                 Key: DIRMINA-777
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-777
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.0-RC1
>         Environment: Mac OS X 10.6.2, Java 1.6, Android SDK
>            Reporter: Matt Huggins
>            Priority: Blocker
>              Labels: config, session, synchronized
>             Fix For: 2.0.8
>
>
> I'm attempting to perform a synchronous write/read in a demux-based client application with MINA 2.0 RC1, but it seems to get stuck. Here is my code:
> {code}
> public boolean login(final String username, final String password) {
>     // block inbound messages
>     session.getConfig().setUseReadOperation(true);
>     // send the login request
>     final LoginRequest loginRequest = new LoginRequest(username, password);
>     final WriteFuture writeFuture = session.write(loginRequest);
>     writeFuture.awaitUninterruptibly();
>     if (writeFuture.getException() != null) {
>         session.getConfig().setUseReadOperation(false);
>         return false;
>     }
>     // retrieve the login response
>     final ReadFuture readFuture = session.read();
>     readFuture.awaitUninterruptibly();
>     if (readFuture.getException() != null) {
>         session.getConfig().setUseReadOperation(false);
>         return false;
>     }
>     // stop blocking inbound messages
>     session.getConfig().setUseReadOperation(false);
>     // determine if the login info provided was valid
>     final LoginResponse loginResponse = (LoginResponse)readFuture.getMessage();
>     return loginResponse.getSuccess();
> }
> {code}
> I can see on the server side that the LoginRequest object is retrieved, and a LoginResponse message is sent. On the client side, the DemuxingProtocolCodecFactory receives the response, but after throwing in some logging, I can see that the client gets stuck on the call to `readFuture.awaitUninterruptibly() `.
> I can't for the life of me figure out why it is stuck here based upon my own code. I properly set the read operation to true on the session config, meaning that messages should be blocked. However, it seems as if the message no longer exists by time I try to read response messages synchronously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)