[
https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054682#comment-13054682
]
James Baldassari commented on AVRO-842:
---------------------------------------
I have a patch that fixes this issue that I'll post shortly. The main changes
are:
* Allow a couple of methods in Transceiver and Requestor to throw IOException
* Don't try to use the Netty channel if it is null. Instead, we try to
reconnect, which will result in an IOException if the connection fails. This
also allows the NettyTransceiver to recover from temporary network outages.
* Fixed potential deadlock in NettyTransceiver (that I introduced in AVRO-539)
between close() and NettyTransceiver.handleUpstream(ChannelHandlerContext,
ChannelEvent)
If the connection to the server goes down and the client subsequently tries to
invoke another RPC:
* If using the Callback API an IOException will be thrown
* If using the non-Callback API, the IOException will be wrapped in an
AvroRemoteException because those methods can only throw AvroRemoteException
** The alternatives are to allow the proxy to throw
UndeclaredThrowableException or to throw a RuntimeException, but neither of
these options seemed like the best choice to me
I wrote a new unit test in TestNettyServerWithCallbacks that mimics the
behavior of Holger's test but also tests the Callback API. All existing unit
tests pass.
> Internal NPE when accessing proxy to a closed server endpoint
> -------------------------------------------------------------
>
> Key: AVRO-842
> URL: https://issues.apache.org/jira/browse/AVRO-842
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.5.1
> Environment: generic
> Reporter: Holger Hoffstätte
> Attachments: CrashTest.java
>
>
> For development of an avro-based transport for remote OSGi services I had to
> wrap & unwind transport-level exceptions into proper exceptions thrown to a
> client. One such scenario is accessing a disconnected/dead endpoint, which
> should be a detectable condition. This works fine with the
> SaslSocketTransceiver (where my wrapper can properly detect the IO
> Exception), but not with Netty which hiccups with an internal NPE.
> Generally speaking any transport-level and remote-endpoint exceptions must
> not only be clearly detectable (either directly by client code or wrapper
> infrastructure around avro) but also distinguishable from another.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
