You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jonathan Hsieh (JIRA)" <ji...@apache.org> on 2012/11/22 04:00:58 UTC
[jira] [Created] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Jonathan Hsieh created HBASE-7206:
-------------------------------------
Summary: 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
Reporter: Jonathan Hsieh
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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "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 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502596#comment-13502596 ]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
Old error framework remains currently -- this patch only deletes the tests. The transition to this API happens and removal of the /main/* classes will in HBASE-7208.
I'm also considering the removal of the Barrier Protos (was Commit protos) -- this will be follow on work.
> 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
>
>
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503784#comment-13503784 ]
Hadoop QA commented on HBASE-7206:
----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12554852/hbase-7206.v3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author tags.
{color:green}+1 tests included{color}. The patch appears to include 26 new or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3401//console
This message is automatically generated.
> 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
[jira] [Updated] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Attachment: hbase-7206.v3.patch
Uploaded v3 from review board.
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510801#comment-13510801 ]
stack commented on HBASE-7206:
------------------------------
bq. I'm just going to use Foreign instead of the longer ForeignThread in most places
I was just going to say... having 'Thread' in the name is a little redundant on the day after. +1 on talking up the peer aspect of partipants. Once I got that part, the proposal made way more sense. Thanks.
> 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
[jira] [Updated] (HBASE-7206) Foreign Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Description:
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.
was:
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.
Summary: Foreign Exception framework v2 (simplifies and replaces HBASE-6571) (was: External Exception framework v2 (simplifies and replaces HBASE-6571))
> Foreign 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, hbase-7206.v4.patch, pre-hbase-7206.v4.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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (HBASE-7206) Foreign Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Attachment: pre-hbase-7206.v4.patch
hbase-7206.v4.patch
> Foreign 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, hbase-7206.v4.patch, pre-hbase-7206.v4.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
[jira] [Updated] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Attachment: 121122-external-exceptions.pdf
Attached a quick deck motivating and describing lifecycle of external exceptions framework.
> 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
>
>
> 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
[jira] [Updated] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Component/s: (was: Zookeeper)
(was: regionserver)
(was: master)
(was: Client)
> 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
>
>
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502598#comment-13502598 ]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
Review available here: https://reviews.apache.org/r/8182/diff/#index_header
> 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
>
>
> 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
[jira] [Updated] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Status: Patch Available (was: Open)
> 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
[jira] [Comment Edited] (HBASE-7206) External Exception framework
v2 (simplifies and replaces HBASE-6571)
Posted by "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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508129#comment-13508129 ]
stack commented on HBASE-7206:
------------------------------
Very nice design proposal. Definetly makes it easier reviewing this new addition. Thanks.
"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?
Why exceptions only and not general messages passing?
Looks like a Future? Or a DistributedFuture?
"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)?
ExternalExceptionSnare... nice class name. Poetic.
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?
Yeah, not clear on this one (I'm not the brightest so you'll have to bring me along).... look forward to answers above.
Good on you Jon.
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510775#comment-13510775 ]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
In conversation Jesse, Stack and I have agreed on calling this all "ForeignThreadException" instead of "ExternalException". Also there will be a little bit more documentation about the peer nature of the dispatchers.
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510781#comment-13510781 ]
Jonathan Hsieh commented on HBASE-7206:
---------------------------------------
I'm just going to use Foreign instead of the longer ForeignThread in most place.
> 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
[jira] [Comment Edited] (HBASE-7206) External Exception framework
v2 (simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510781#comment-13510781 ]
Jonathan Hsieh edited comment on HBASE-7206 at 12/5/12 9:19 PM:
----------------------------------------------------------------
I'm just going to use Foreign instead of the longer ForeignThread in most places
was (Author: jmhsieh):
I'm just going to use Foreign instead of the longer ForeignThread in most place.
> 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
[jira] [Commented] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509383#comment-13509383 ]
stack commented on HBASE-7206:
------------------------------
I see our building an inter-thread message passing system except the system only passes a single message type, the exception type. It makes me ask why not just make a system for message passing including exception message types.
Will we want to use this framework to do other than exception reporting?
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)
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?
> 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
[jira] [Updated] (HBASE-7206) External Exception framework v2
(simplifies and replaces HBASE-6571)
Posted by "Jonathan Hsieh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hsieh updated HBASE-7206:
----------------------------------
Assignee: Jonathan Hsieh
> 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
>
>
> 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