[
https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509849#comment-13509849
]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
bq. Will we want to use this framework to do other than exception reporting?
Right now, no.
bq. I was thinking it like a Future because you can call isDone or isCancelled
– you'd call these rather than your noop checkable – before you go block on the
getting of the result (I suppose can't get failure reason out of a Future so
not best analogy)
The point of the rethrowException which acts like a noop is that the exception
is coming in asynchronously while work is still being done in the
"non-external" main thread. The main thread is assumed to be "slower" than
potential external notifications and we don't necessarily get to the point
where it will block waiting for others to finish. We actually want the main
thread to continue, periodically check if there are any "external" exception.
If the external exception is detected, it cancels. If it succeeds, there will
never be any exceptions. (With the barrier work, whatever signals leaving
barrier acts as the "success" condition notification.
bq. Are the processes that throw these 'ExternalExceptions' children of the
'checking' thread? What is the relation? I want to know to see if can have
better name than ExternalException. ChildException? DependencyException? The
latter is not too bad in that it says there is a relationship between the
process throwing the exception and the 'checking' thread?
They aren't necessarily children (in the barrier, the member or the coordinator
could throw the external exception, cancelling all others). They aren't
necessarily on separate processes. They all just are somehow in the same
group. (in the procedure, all are members or coordinators of the specific
procedure instance). I'm not a fan of dependency exception -- it doesn't
capture the idea of coming from a separate thread/process. They are supposed
to only be out-of-band -- from a separate thread. I've thought about "Foreign"
or "Remote" as names but chose ExternalException. How about
ExternalThreadException?
> External Exception framework v2 (simplifies and replaces HBASE-6571)
> --------------------------------------------------------------------
>
> Key: HBASE-7206
> URL: https://issues.apache.org/jira/browse/HBASE-7206
> Project: HBase
> Issue Type: Sub-task
> Components: snapshots
> Reporter: Jonathan Hsieh
> Assignee: Jonathan Hsieh
> Fix For: hbase-6055, 0.96.0
>
> Attachments: 121122-external-exceptions.pdf, hbase-7206.v3.patch
>
>
> This provides a way of sending exceptions from 'external' threads/processes
> (not the main executing thread) to others that poll cooperatively for
> external exceptions. Some examples of how this can be used include: having a
> separate timeout thread that injects an exception when a time limit has
> elapsed (TimeoutExceptionInjector, was OperationAttemptTimer), or having an
> exception from an separate process delivered to a local thread.
> This simplified version is centered around the ExternalException class.
> Instead of using generics and ErrorListener interfaces, this more
> straight-forward implementation eliminates many of the builders/factories and
> generics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
