[
https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508137#comment-13508137
]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
bq. "We need a way of sending exceptions from other threads/processes to
another thread so that it can cancel the potentially long running process" What
is difference between this and a message bus?
I'm assuming message bus ala apache camel or mule?
http://camel.apache.org/message-bus.html
I'm not completely familiar with these so can you give confirm that is what you
are talking about so I can do a better comparison?
I think of this as something similar to errno (it contains information about
the initial failure), and a java's thread interrupted state. There are
out-of-band methods of passing state injected by a separate thread. The
"checking" thread is responsible for determine when and if there is a problem
by checking these state values. The penalty of for not checking is more
"wasted" effort due to doing more work before cancelling.
bq. Why exceptions only and not general messages passing?
Currenly the procedure mechanism takes care of successful execution conditions.
bq. Looks like a Future? Or a DistributedFuture?
It is not like a future. In a future, you basically get a reference to
something that will return a value, and then eventually call a method like
get() that will return the value if it is ready or block until it is.
The methods here on the checkable will be usually be no-ops and will never
block waiting for something. If an exception has been registered, then that
exception can be queried or rethrown.
bq. "Other threads periodically polls that container and aborts if there is an
‘external exception’" The focus is on 'exceptions'. Could we pivot and talk
about successes instead? The framework is about reporting result of remote
process. Usuaally they succeed but there is also provision for reporting why it
failed (the exception)?
similar to above -- we focus on exception because the procedure mechanism
assumes and handles the success cases. If they were rpc's the return values
come through the rpc. In the current procedure mechanism this is done through
the existence of zk nodes (as opposed to the existance and their contents which
could have return values). My guess is if we go toward usign the contents
we'll not be able to use the same double barrier mechanism (or have to at least
think of some other way to do it).
bq. ExternalExceptionSnare... nice class name. Poetic.
Stack, code is poetry in binary. :)
bq. What action does a watching process take on an ExternalException? It
cancels what it was doing? Or we are watching for ExternalException because in
their absence, we know whatever we set running is proceeding?
I think you got it -- if there are extenral exceptions registered, it is a
no-op -- the listening thread will just continue. if there is a registered
external exception the defaul tchecking function, rethrowException, will
rethrow the exception and it is up to the thread to decide how to handle it.
> 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
