avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte (JIRA) <j...@apache.org>
Subject [jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
Date Tue, 28 Jun 2011 08:44:18 GMT

    [ 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

       

Mime
View raw message