Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/816
Think I've addressed everything except `getImmediately(unsubmittedTask)`.
> My expectation for what getImmediately(task) should do is: try to
evaluate the task immediately, but if it couldn't then leave the task in a good
state so if someone else does task.get() then it will still be usable.
I think the only way to support your expected behaviour is to run it in a
separate thread. And this defeats the point of most uses which is to be
lightweight and throw away the task afterward.
So I think the best thing to do is clarify the semantics in javadoc that
unsubmitted tasks will be cancelled (and clean up the tests a bit -- though
more would always be welcome -- and add the `isExecutingImmediately` guard you
noted), with a note that callers should use the `TaskFactory` pattern if that
behaviour is not desired (because the `TaskAdaptable` will cause it to create a
new task instance).
While a `getImmediatelyOrSubmitIfWeCant` would be nice, it is problematic.
We often won't know if a task doesn't support immediate until we've tried
running it, and it does a `wait` or similar, and throws. If we don't want it
to throw, then we can't neatly enforce that it doesn't block (without polling
the other threads state or maybe via low level hacks). So I think you probably
end up doing `submit(task).get(SHORT_TIMEOUT)`.
There might be room for a
`Tasks.getImmediatelyIfSafeElseSubmitAndShortWait()` utility method that does a
subset of the checks (including if it's being given a `TaskFactory`) and tries
to avoid unnecessary submits but doesn't risk cancelling an externally supplied
task. I'll review usages and see.
Thoughts @aledsage ?
---
