[
https://issues.apache.org/jira/browse/AVRO-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453436#comment-13453436
]
Doug Cutting commented on AVRO-1156:
------------------------------------
I think this change will just close the connection rather than kill the JVM.
There are recoverable conditions that result in OutOfMemoryError, like 'new
long[Integer.MAX_VALUE]', so killing the JVM may be overkill. The net effect
of this change would be that clients, instead of receiving an exception that
names the server-side error that occurred, will just see the connection closed.
That seems like a step backwards, no?
If we really wanted to kill the JVM in a multi-threaded server I think we'd
need to call Runtime.exit(). In some cases this might be better, since the
alternative might leave a zombie server. But in other common cases, e.g.,
where a badly formatted request attempts a huge allocation, this will kill a
healthy server. So I'm not very enthusiastic about this approach. The normal
way to detect zombie servers is to add an isZombie() method to protocols and
ping periodically to see whether the server is still responding sensibly.
> Avro responder swallows thrown Errors
> -------------------------------------
>
> Key: AVRO-1156
> URL: https://issues.apache.org/jira/browse/AVRO-1156
> Project: Avro
> Issue Type: Bug
> Reporter: Mike Percy
> Assignee: Mike Percy
> Fix For: 1.7.2
>
> Attachments: AVRO-1156-1.patch
>
>
> The Avro responder wraps caught Errors, such as OutOfMemoryErrors, in
> Exceptions and rethrows them. That's problematic because an Error should be
> allowed to crash the JVM, since it's often irrecoverable.
--
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
