I have identified several cases where IBlockingBuffer.setFuture() was not being invoked until after the Future had already begun to execute. This could result in the producer (the Future is for the producer) not being cancelled if the consumer was closed before the setFuture() was invoked.  I have updated the code to use a FutureTask to wrap the computation, use setFuture(ft) for that FutureTask, and only then submit the FutureTask for evaluation. This ensures that the Future of the producer is set before the consumer starts to run.  Changes were made to the following files:

{{{
- AccessPath#asynchronousIterator()
- AbstractClientIndexView#newWriteBuffer()
- ClientIndexView#newWriteBuffer()
- ClientIndexView#parallelRangeIterator()
- ClientAsynchronousIterator#start()
- MappedTaskMaster#newResourceBuffer()
- DGExpander.InnerIterator#312
- TripleStoreUtility#notFoundInTarget()
}}} 

In addition, the following unit tests had the bad pattern and were fixed:
{{{
- TestBlockingBuffer
- TestFileSystemScanner
- TestMasterTask
- TestMasterTaskWithTimeout
- TestMasterTaskWithErrors
- TestMasterTaskWithRedirect
- TestMasterTaskWithSplits (note: this test is no in CI - never finished)
}}}

There were two places in the code where I could not apply this pattern because the consumer was started in a different lexical scope.  For these two cases, I wrapped the code to ensure that the Future was cancelled if it there was an exit by a code path that did not cause setFuture() to be invoked.  
ProgramTask#362
{{{
            try {
                // run the task.
                future = queryTask.submit();

                // set the future on the BlockingBuffer.
                buffer.setFuture(future);
            } finally {
                if (future != null && buffer.getFuture() == null) {
                    // Future exists but not set on BlockingBuffer.
                    future.cancel(true/* mayInterruptIfRunning */);
                }
            }
}}}

AbstractMasterTask#905:
{{{
                Future<? extends AbstractSubtaskStats> future = null;
                try {
                    // assign a worker thread to the sink.
                    future = submitSubtask(sink);
                    // set Future (can now be cancelled)
                    out.setFuture(future);
                } finally {
                    if (future != null && buffer.getFuture() == null) {
                        // Future exists but not set on BlockingBuffer.
                        future.cancel(true/* mayInterruptIfRunning */);
                    }
                }
}}}

See https://sourceforge.net/apps/trac/bigdata/ticket/707 (BlockingBuffer.close() leaks threads)

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7242 8f7bc0f5-282e-0410-95e3-8d296e9bb460
fixed 712 - SELECT ?x { OPTIONAL { FILTER (false) }}, including test cases

git-svn-id: https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_2_0@7243 8f7bc0f5-282e-0410-95e3-8d296e9bb460