[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810437#comment-16810437 ] Hudson commented on AVRO-732: - FAILURE: Integrated in Jenkins build AvroJava #638 (See [https://builds.apache.org/job/AvroJava/638/]) [AVRO-732] Remove AvroRemoteException from generated interfaces Patch (dkulp: [https://github.com/apache/avro/commit/4c0e41cebc0804c563dffe98a58c06b1c39098e1]) * (edit) lang/java/ipc-jetty/src/test/java/org/apache/avro/ipc/jetty/TestStatsPluginAndServlet.java * (edit) lang/java/compiler/src/main/velocity/org/apache/avro/compiler/specific/templates/java/classic/protocol.vm * (edit) lang/java/ipc/src/test/java/org/apache/avro/compiler/specific/TestSpecificCompiler.java * (edit) lang/java/grpc/src/test/java/org/apache/avro/grpc/TestAvroProtocolGrpc.java * (edit) lang/java/ipc-netty/src/test/java/org/apache/avro/ipc/netty/TestNettyServerWithCallbacks.java * (edit) lang/java/archetypes/avro-service-archetype/src/main/resources/archetype-resources/src/main/java/service/SimpleOrderService.java * (edit) lang/java/avro/src/main/java/org/apache/avro/AvroRemoteException.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/TestNamespaceSpecific.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/ipc/TestLocalTransceiver.java * (edit) lang/java/archetypes/avro-service-archetype/src/main/resources/archetype-resources/src/main/java/transport/SimpleOrderServiceClient.java * (edit) lang/java/ipc-jetty/src/test/java/org/apache/avro/ipc/jetty/StatsPluginOverhead.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/TestProtocolSpecific.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/TestProtocolGeneric.java * (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/specific/SpecificRequestor.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/ipc/TestRpcPluginOrdering.java * (edit) lang/java/ipc-jetty/src/test/java/org/apache/avro/ipc/jetty/TestProtocolHttp.java * (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/Requestor.java * (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/specific/SpecificResponder.java * (edit) lang/java/ipc/src/test/java/org/apache/avro/TestProtocolReflect.java * (edit) lang/java/avro/src/main/java/org/apache/avro/reflect/ReflectData.java * (edit) lang/java/ipc-netty/src/test/java/org/apache/avro/ipc/netty/TestNettyServerConcurrentExecution.java * (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/SocketServer.java * (edit) pom.xml * (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/generic/GenericRequestor.java > Generated protocol's method should not throw AvroRemoteException > > > Key: AVRO-732 > URL: https://issues.apache.org/jira/browse/AVRO-732 > Project: Apache Avro > Issue Type: Bug > Components: java >Reporter: Sharad Agarwal >Assignee: Daniel Kulp >Priority: Major > Fix For: 1.9.0 > > Attachments: > AVRO-732-remove-generated-remote-exception-2012-12-11.patch, > AVRO-732-remove-generated-remote-exception-2012-12-17.patch > > > If user does NOT define the throws clause in the idl, the code is generated > with "throws AvroRemoteException" clause. However on throwing the > AvroRemoteException from the implementation, the serialization fails. This is > not intuitive to users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810422#comment-16810422 ] ASF subversion and git services commented on AVRO-732: -- Commit 4c0e41cebc0804c563dffe98a58c06b1c39098e1 in avro's branch refs/heads/master from Daniel Kulp [ https://gitbox.apache.org/repos/asf?p=avro.git;h=4c0e41c ] [AVRO-732] Remove AvroRemoteException from generated interfaces Patch from Sebastien Launay applied > Generated protocol's method should not throw AvroRemoteException > > > Key: AVRO-732 > URL: https://issues.apache.org/jira/browse/AVRO-732 > Project: Apache Avro > Issue Type: Bug > Components: java >Reporter: Sharad Agarwal >Priority: Major > Fix For: 1.9.0 > > Attachments: > AVRO-732-remove-generated-remote-exception-2012-12-11.patch, > AVRO-732-remove-generated-remote-exception-2012-12-17.patch > > > If user does NOT define the throws clause in the idl, the code is generated > with "throws AvroRemoteException" clause. However on throwing the > AvroRemoteException from the implementation, the serialization fails. This is > not intuitive to users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[
https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537221#comment-13537221
]
Sébastien Launay commented on AVRO-732:
---
The two interfaces looks cleaner indeed plus we could remove the callback
structure on the responder side but it could be a bit confusing for developers
to know the one to use I guess.
This approach is actually used in Spring for RMI and the implementation of
JAX-RPC, two somewhat deprecated technologies.
The recommended technologies by Spring (JAX-RS, JMS, Burlap, Hessian, ...) use
the following runtime exception not declared in a single business interface
defined by the user:
https://github.com/SpringSource/spring-framework/blob/v3.2.0.RELEASE/spring-context/src/main/java/org/springframework/remoting/RemoteAccessException.java
{quote}
A client object simply receives an implementation for the interface that
it needs via a bean reference, like it does for a local bean as well.
A client may catch RemoteAccessException if it wants to, but as
remote access errors are typically unrecoverable, it will probably let
such exceptions propagate to a higher level that handles them generically.
In this case, the client code doesn't show any signs of being involved in
remote access, as there aren't any remoting-specific dependencies.
{quote}
They insist on the unrecoverable error aspect of such remoting interfaces and
they are known to be advocates of RuntimeException especially through their
famous template pattern.
I guess these remoting facilities are more targeted towards J2EE applications
rather than highly available distributed applications where you expect things
to fail and need explicit control.
The two interfaces available might actually be the best of both worlds, I am
wondering if we could use both of them on the client side with the same
\*Requestor code.
That is by introspecting the interface's method exceptions in the
InvocationHandler we can choose whether to throw an AvroRemoteException if
declared or else an AvroRuntimeException.
We can even choose at generation if the user want to have both interfaces or
else just the business one or else the current one for backward compatibility
(might be confusing again if not properly documented).
The performance impact should be negligible especially if the behaviour is
cached per method.
Today using ReflectResponder will wrap a transport error into an
AvroRemoteException except if it is a runtime or a declared exception.
This means that if somebody uses an interface without AvroRemoteException
declared in the methods, the only way to recover is to catch Exception and
check it is an AvroRemoteException because catching it directly
AvroRemoteException won't compile.
Generated protocol's method should not throw AvroRemoteException
Key: AVRO-732
URL: https://issues.apache.org/jira/browse/AVRO-732
Project: Avro
Issue Type: Bug
Components: java
Reporter: Sharad Agarwal
Fix For: 1.8.0
Attachments:
AVRO-732-remove-generated-remote-exception-2012-12-11.patch,
AVRO-732-remove-generated-remote-exception-2012-12-17.patch
If user does NOT define the throws clause in the idl, the code is generated
with throws AvroRemoteException clause. However on throwing the
AvroRemoteException from the implementation, the serialization fails. This is
not intuitive to users.
--
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
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13536572#comment-13536572 ] Doug Cutting commented on AVRO-732: --- you don't want to have a transport exception when implementing your interface You don't have to throw or even declare every exception in an interface that you implement. Still, having it in the interface may be confusing. Generating two interfaces, one for remote clients and one for implementors, like Spring, would be cleaner. Or we might just improve the documentation around this. AvroRemoteException in methods is viral [ on clients ] This is like IOException. A checked exception for transport errors seems appropriate on the client. Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal Fix For: 1.8.0 Attachments: AVRO-732-remove-generated-remote-exception-2012-12-11.patch, AVRO-732-remove-generated-remote-exception-2012-12-17.patch If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- 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
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534159#comment-13534159 ] Doug Cutting commented on AVRO-732: --- I'm now starting to worry that switching to an unchecked exception might make it more difficult to write distributed applications. Remote procedure calls are more likely to fail in than local procedure calls and those failures are often recoverable. Distributed applications often explicitly consider the failure of every remote call. Every RPC involves i/o, so always throwing some IOException might be reasonable. Does that make any sense? What is the bug we're trying to fix here? Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal Fix For: 1.8.0 Attachments: AVRO-732-remove-generated-remote-exception-2012-12-11.patch, AVRO-732-remove-generated-remote-exception-2012-12-17.patch If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- 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
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530461#comment-13530461 ] Doug Cutting commented on AVRO-732: --- Using a RuntimeException for undeclared errors is an improvement. But we should perhaps also split the uses of AvroRemoteException into more than one class. Its uses include: - undeclared errors - a base class for declared errors - a wrapper for error data in the generic API We might keep AvroRemoteException for the second use, add a new RuntimeException named AvroUndeclaredException, a new GenericException extending AvroRemoteException that's used by the Generic API. Is that overkill? Can you think of a different re-factoring might break less user code? Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal Fix For: 1.8.0 Attachments: AVRO-732-remove-generated-remote-exception-2012-12-11.patch If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- 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
[jira] [Commented] (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13474868#comment-13474868 ] Tino Kissig commented on AVRO-732: -- This issue is still present in 1.7.2. Are there any plans to do this improvement in one of the next releases? Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- 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
[jira] Commented: (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986570#action_12986570 ] Doug Cutting commented on AVRO-732: --- For specific and reflect code, the natural mapping to me is that errors declared in the protocol should be declared as thrown in the generated interface methods. Generic code needs to throw something that's both an exception and contains GenericRecord. Currently this is done by wrapping a GenericData.Record within a AvroRemoteException. I am still +1 for removing AvroRemoteException from the list of exceptions thrown by generated code. Perhaps other exception-related improvements could be made, but I'd prefer to limit this issue to that improvement if possible. Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985746#action_12985746 ] Holger Hoffstätte commented on AVRO-732: My vote would be to: - get rid of AvroRemoteException in interfaces - serialize service-level remote exceptions pass them through (most exceptions are serializable) - throw AvroRemoteExceptions for caught non-RuntimeExceptions, i.e. transport errors as cause AvroRemoteException should therefore not be a subclass of IOException. This allows clients and any client-side infrastructure (proxy interceptors etc.) to distinguish between interface-declared service exceptions and undeclared transport exceptions via AvroRemoteExceptions with a cause. Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985775#action_12985775 ] Philip Zeyliger commented on AVRO-732: -- Serializing Java exceptions only works for Java: I think you've more or less got to coerce the exception into a string. Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[
https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985032#action_12985032
]
Scott Carey commented on AVRO-732:
--
The code always adds AvroRemoteException if is not a one-way message:
in the compiler's velocity template protocol.vm there is:
{quote}
)#if (! $message.isOneWay())
throws org.apache.avro.AvroRemoteException##
{quote}
and corresponding logic in the Avro14SpecificCompiler test class.
Is it OK to remove this? Or is the suggestion that if an exception is
declared, then omit the AvroRemoteException? If we get rid of it completely,
what is the expected behavior when the remote side sends back an error? I'm
not familiar enough with the protocols to fix this, but we should do so for
1.5.0 since the exception signature is changing due to AVRO-737.
Generated protocol's method should not throw AvroRemoteException
Key: AVRO-732
URL: https://issues.apache.org/jira/browse/AVRO-732
Project: Avro
Issue Type: Bug
Components: java
Reporter: Sharad Agarwal
If user does NOT define the throws clause in the idl, the code is generated
with throws AvroRemoteException clause. However on throwing the
AvroRemoteException from the implementation, the serialization fails. This is
not intuitive to users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-732) Generated protocol's method should not throw AvroRemoteException
[ https://issues.apache.org/jira/browse/AVRO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981384#action_12981384 ] Doug Cutting commented on AVRO-732: --- This sounds like it would be a good improvement. I can't recall why I did things this way. It looks to be a mistake. Generated protocol's method should not throw AvroRemoteException Key: AVRO-732 URL: https://issues.apache.org/jira/browse/AVRO-732 Project: Avro Issue Type: Bug Components: java Reporter: Sharad Agarwal If user does NOT define the throws clause in the idl, the code is generated with throws AvroRemoteException clause. However on throwing the AvroRemoteException from the implementation, the serialization fails. This is not intuitive to users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
