Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Component/s: None
    • Security Level: Public
    • Labels:
      None
    # Subject Project Status CR V
    For Gerrit Dashboard: &For+JCBC-343=message:JCBC-343

      Activity

      Hide
      thanhbv thanhbv added a comment -

      see the following scala code:

      val op: OperationFuture[T] = ... //an OperationFuture of type T
      op.addListener(new OperationCompletionListener {
      def onComplete(op2: OperationFuture[_]) {
      //I think op2 == op ???
      if(op.getStatus.isSuccess)

      { //Here, how to get the value (of type T) in the successfully completed OperationFuture op? //I want the result of op.get: https://github.com/couchbase/spymemcached/blob/fb6e0f01cfae13a180127cd65dbec7b025cfbc8e/src/main/java/net/spy/memcached/internal/OperationFuture.java#L158 //I think we shoud add the following check to (first line of method) OperationFuture#get: //if(op != null && op.getState() == OperationState.COMPLETE) return objRef.get(); }

      }
      })

      Show
      thanhbv thanhbv added a comment - see the following scala code: val op: OperationFuture [T] = ... //an OperationFuture of type T op.addListener(new OperationCompletionListener { def onComplete(op2: OperationFuture [_] ) { //I think op2 == op ??? if(op.getStatus.isSuccess) { //Here, how to get the value (of type T) in the successfully completed OperationFuture op? //I want the result of op.get: https://github.com/couchbase/spymemcached/blob/fb6e0f01cfae13a180127cd65dbec7b025cfbc8e/src/main/java/net/spy/memcached/internal/OperationFuture.java#L158 //I think we shoud add the following check to (first line of method) OperationFuture#get: //if(op != null && op.getState() == OperationState.COMPLETE) return objRef.get(); } } })
      Show
      thanhbv thanhbv added a comment - @see https://gist.github.com/thanh-buiviet/6649489
      Hide
      ingenthr Matt Ingenthron added a comment -

      Michael is out this week but he should look at this soon. Reopening for now though itmay be a separate request.

      Show
      ingenthr Matt Ingenthron added a comment - Michael is out this week but he should look at this soon. Reopening for now though itmay be a separate request.
      Hide
      daschl Michael Nitschinger added a comment -

      Hey,

      I'm not quite sure what you say here, can you elaborate a bit? I'm not sure if we should change the OperationFuture.get() behavior, but I'm open to everything if its a bug

      Also, yes, the future in the onComplete callback is the same. Just so that you could pass in a specific object that doesn't need to come out of the same scope.

      Show
      daschl Michael Nitschinger added a comment - Hey, I'm not quite sure what you say here, can you elaborate a bit? I'm not sure if we should change the OperationFuture.get() behavior, but I'm open to everything if its a bug Also, yes, the future in the onComplete callback is the same. Just so that you could pass in a specific object that doesn't need to come out of the same scope.
      Hide
      thanhbv thanhbv added a comment -

      I have a XXFuture[T] f that hold a future that when complete will produce a value v of type T if success, or produce a failure with some reason.
      XXFuture can be OperationFuture, GetFuture, HttpFuture,.. (not just OperationFuture)

      When I call f.addListener(some_handler) then, in some_handler (will be call when f is completed), spymemcache need provide a way for me to determine if f is success or not.
      "a way" here is f.getStatus.isSuccess. OK.

      When I see that f is successful, I need a way to get "the successful value" v.
      "a way" here is f.get. Right?

      So, I think the implementation of `get` method in OperationFuture, GetFuture,.. should check that if `this` future is already completed then the `get` method should return the completed value immediately.

      I think the behavior of the get methods should as the description above.
      get := if(completed)

      { return the completed value}

      else

      {value = do_get(); return value }

      Sorry. English is not my first language

      Show
      thanhbv thanhbv added a comment - I have a XXFuture [T] f that hold a future that when complete will produce a value v of type T if success, or produce a failure with some reason. XXFuture can be OperationFuture, GetFuture, HttpFuture,.. (not just OperationFuture) When I call f.addListener(some_handler) then, in some_handler (will be call when f is completed), spymemcache need provide a way for me to determine if f is success or not. "a way" here is f.getStatus.isSuccess. OK. When I see that f is successful, I need a way to get "the successful value" v. "a way" here is f.get. Right? So, I think the implementation of `get` method in OperationFuture, GetFuture,.. should check that if `this` future is already completed then the `get` method should return the completed value immediately. I think the behavior of the get methods should as the description above. get := if(completed) { return the completed value} else {value = do_get(); return value } Sorry. English is not my first language
      Hide
      daschl Michael Nitschinger added a comment -

      You are right, but that's whats happening (if I understand you correctly).

      If the latch is already counted down in the future, you'll get the response back immediately. So first checking for success (which implies that its completed) and then calling .get() is perfectly fine.

      Does that makes sense? It's not mine either

      Show
      daschl Michael Nitschinger added a comment - You are right, but that's whats happening (if I understand you correctly). If the latch is already counted down in the future, you'll get the response back immediately. So first checking for success (which implies that its completed) and then calling .get() is perfectly fine. Does that makes sense? It's not mine either
      Hide
      thanhbv thanhbv added a comment -

      The current implementation of #get, when the future is completed successfully:
      + OperationFuture#get will almost return immediately. It's OK.
      + BulkGetFuture#get is delegated to #internalGet that call some java.util.concurrent.FutureTask#get. It's OK too.
      + GetFuture#get is also OK.
      ...
      after digging into all subclasses of ListenableFuture, I found that all of it is OK! So I think this issue should be (re-)set to resolved now.

      thank you.

      Show
      thanhbv thanhbv added a comment - The current implementation of #get, when the future is completed successfully: + OperationFuture#get will almost return immediately. It's OK. + BulkGetFuture#get is delegated to #internalGet that call some java.util.concurrent.FutureTask#get. It's OK too. + GetFuture#get is also OK. ... after digging into all subclasses of ListenableFuture, I found that all of it is OK! So I think this issue should be (re-)set to resolved now. thank you.

        People

        • Assignee:
          daschl Michael Nitschinger
          Reporter:
          daschl Michael Nitschinger
        • Votes:
          0 Vote for this issue
          Watchers:
          3 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Gerrit Reviews

            There are no open Gerrit changes