[jira] [Comment Edited] (HBASE-7206) External Exception framework v2 (simplifies and replaces HBASE-6571)

["Jonathan Hsieh (JIRA)" <ji...@apache.org>]

    [ 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