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

Holger Hoffstätte commented on AVRO-842:
----------------------------------------

I've given this a try; it applies cleanly and runs. Nice! A few more/new 
observations. When I run this against my initial test I've noticed that:

- the client Transceiver now hangs on close() and the VM does not exit properly 
any longer
- because the Transceiver's threads hang around
- because the Transceiver's factory.releaseExternalResources() is never called
- because close() calls disconnect(true, true) which waits for channel shutdown 
forever or hiccups, throwing more exceptions.

There also seems to be an awful lot of exception logging in various places (in 
-ipc in general). This makes things a lot harder to read or track and very 
confusing - propagate, handle or log but not all three at once :)

As far as the propagated exception goes, wrapping the IOException into an 
AvroException with cause is fine and consistent with the SaslSocketServer. We 
just need some consistent way to figure out that something went kaput.


> 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: AVRO-842-v2.patch, AVRO-842.patch, 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


Reply via email to