j_future 0.0.1-java → 0.0.2-java

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: d3b8dbfabd5a6e294509d71902e15bce2bf06177
-  data.tar.gz: 8d8fc608cb785e0ebfa1f119bac804b184def594
+  metadata.gz: 00b0a43b77c0e32921d507604901d0dbc4045072
+  data.tar.gz: 447e712634661f23eafc7fb70c2acb257e780af9
 SHA512:
-  metadata.gz: b63fdccd5b652bc3b7f96200bb071bebfbd856cf3d8411e455c168a23b6e2f7c6501cef840f0ac3dacc3221be168dfd248d190bc7ed2b2f3850828510a329960
-  data.tar.gz: a6ae8f5245ef4dd7b3a1a601b887211fa08eb427378d7f3ede7bb186a311d86ed514683a3f5894a8933c237337686f5cf1a6c657c99eec25f0d4d47e55f2ee00
+  metadata.gz: 24a505392f39154831e94396585de36b4a5997c62ab39870494a6d87347f3b615069d71e0a14a54d1a38befdc4bcb554ac02250bb814a85f59b18212abeff820
+  data.tar.gz: de087dd28219bbb8d86bf506c81a81514b016b0310bc4ca76105d10f9a04134291cb564dcafe188f0062dc996d2a18cb56bc743542c291c915b5e2f7fab21ae6

data/README.md

@@ -91,6 +91,16 @@ JFuture.new(access_timeout_millis: 1) {Restaurant.find(id)}.on_complete do
   end
 end
 ```
+Chaining with on_complete
+-------------------------
+`.on_complete` returns a `JFuture` object of the result of on_complete block. Its therefore possible to create a chain with `.on_complete`:
+``` ruby
+JFuture.new { Restaurant.all[0]}.on_complete{|res| res.name}.on_complete{|res|  puts res}
+```
+Its recommended to avoid chaining when possible as it blocks as many workers as the links in the chain. The workers get unblocked in the order of the chain links.
+Its possible to specify the `executor` and `access_timeout_millis` for the `.on_complete` as well.
+While the `executor` specified for `.on_complete` will be used to run the `block` of `.on_complete`, the `access_timeout_millis` will apply to the consumer of the result of the `.on_complete` when it tries to read the result of on complete (`access_timeout_millis` always applies to the consumer of the JFuture object)
+JFuture objects for each link in the chain are created and consumed in one shot. So the timer for each of the timeouts starts almost at the same time. Hence the timeouts in the chain should be in increasing order (i.e. cumulative of the timeout of the previous link in the chain)
 Note:
 -----
 The `access_timeout_millis` only applies to the thread blocking on future object. the worker thread which computes the future will be blocked for as long as it takes to compute the future object without any timeout applicable to it. So, only pass things into future that will complete.

data/lib/j_future.rb

@@ -7,9 +7,9 @@ class JFuture < ::BasicObject
   MILLIS = ::Java::JavaUtilConcurrent::TimeUnit::MILLISECONDS
   METHODS = [:is_done?, :on_complete]
 
-  def initialize(executor: :default, access_timeout_millis: nil, &block)
+  def initialize(executor: :default, access_timeout_millis: nil, arg: nil, &block)
     @access_timeout_millis = access_timeout_millis
-    callable = Callable.new(&block)
+    callable = Callable.new(arg, &block)
     if (executor.is_a? ::Java::JavaUtilConcurrent::AbstractExecutorService)
       @executor = executor
     else
@@ -31,9 +31,8 @@ class JFuture < ::BasicObject
     @future.isDone
   end
 
-  def on_complete(&block)
-    callback = Callable.new(self, &block)
-    @executor.submit callback
+  def on_complete(executor: :default, access_timeout_millis: nil, &block)
+    ::JFuture.new(executor: executor, access_timeout_millis: access_timeout_millis, arg: self, &block)
   end
 
   def method_missing(name, *args, &block)

data/lib/j_future/version.rb

@@ -1,3 +1,3 @@
 class JFuture < ::BasicObject
-  VERSION = "0.0.1"
-end
+  VERSION = "0.0.2"
+end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: j_future
 version: !ruby/object:Gem::Version
-  version: 0.0.1
+  version: 0.0.2
 platform: java
 authors:
 - Sumanth K N
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2017-02-08 00:00:00.000000000 Z
+date: 2017-02-10 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   requirement: !ruby/object:Gem::Requirement