[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058260#comment-13058260 ] Holger Hoffstätte commented on AVRO-842: Just gave patch v3 a try and it now works fine. The VM even correctly exits when the client is not shut down explicitly, since the ExecutorService reaps its thread after a minute and then cleanly exits. This shows that there are no accidental leaks. nice :) 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 Assignee: James Baldassari Fix For: 1.5.2 Attachments: AVRO-842-v2.patch, AVRO-842-v3.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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058025#comment-13058025 ] Doug Cutting commented on AVRO-842: --- Holger, have you had a chance to try this? Also, should we target this fix for 1.5.2? 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 Assignee: James Baldassari Attachments: AVRO-842-v2.patch, AVRO-842-v3.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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058069#comment-13058069 ] James Baldassari commented on AVRO-842: --- Hi Doug, Yes, this patch should go into 1.5.2. It has some important fixes, and it should apply cleanly to the 1.5 branch. If Holger has time to test it out one more time, that would be great, but I'm pretty confident that the most recent version of the path fixes the issues reported here (and in AVRO-747). 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 Assignee: James Baldassari Attachments: AVRO-842-v2.patch, AVRO-842-v3.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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056523#comment-13056523 ] James Baldassari commented on AVRO-842: --- Holger, thanks for trying out the patch! I investigated the hang on close() issue you reported, and I found the cause. It's strange that the unit tests I wrote were not affected by this. It only happened when I ran the test as a normal java process rather than a unit test. Anyway, I'll prepare a new patch. I would appreciate it if you could test this one out too. 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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054427#comment-13054427 ] Holger Hoffstätte commented on AVRO-842: I believe this is related to AVRO-747, which seems to mention the same problem. 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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054560#comment-13054560 ] James Baldassari commented on AVRO-842: --- I reproduced this in trunk (thanks for the test!), and I assume it's a problem in the 1.5 branch as well. I'll see if I can put together a patch to fix this issue as I've recently done some work on the Netty server and transceiver. 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
[jira] [Commented] (AVRO-842) Internal NPE when accessing proxy to a closed server endpoint
[ https://issues.apache.org/jira/browse/AVRO-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
