hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-7206) External Exception framework v2 (simplifies and replaces HBASE-6571)
Date Sun, 02 Dec 2012 04:11:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508137#comment-13508137
] 

Jonathan Hsieh edited comment on HBASE-7206 at 12/2/12 4:11 AM:
----------------------------------------------------------------

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 no 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.

edit: added an important missing no.
                
      was (Author: jmhsieh):
    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

Mime
View raw message