[jira] [Created] (AVRO-2403) Unable to access Metadata from RPC Plugin in implemented interfaces
Jagathpathi created AVRO-2403: - Summary: Unable to access Metadata from RPC Plugin in implemented interfaces Key: AVRO-2403 URL: https://issues.apache.org/jira/browse/AVRO-2403 Project: Apache Avro Issue Type: Wish Components: java Affects Versions: 1.8.2 Reporter: Jagathpathi We have transferred the Metadata from Avro RPC Client to server using RPCPlugin and received in server RPCPlugin. But unable to use/consume the RPCContext or metadata in interface implementation of IDL. In this case the metadata can only be used to log and Implementation was unable to use. Is there any way to consume the same in interface implementation classes. I can transfer the metadata using ThreadLocal which was not the permenant solution in multithreaded/executor service environments. It will be great if this feature was there. Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
[
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846683#comment-16846683
]
Raymie Stata commented on AVRO-2400:
Sorry for the delay getting back to you. Thanks for reporting this issue!
The underlying issue here is an ambiguity in the specification. The spec
reads: "both schemas are enums whose names match, [or] both schemas are fixed
whose sizes and names match, [or] both schemas are records with the same name."
But the specification is not clear as to whether the "name" here is the
name-space qualified name, or the unqualified name. The old implementation
took the position that "name" here meant the unqualified name, and there
doesn't seem like a good reason to reverse this approach right now.
The following would be a good way to fix this bug:
1) Yes, please do submit your reproduction as a test case for the future.
2) Please also update the spec to replace "name[s]" with "(unqualified)
name[s]" in the places just quoted.
3) On line 695 of Resolver.java (i.e., in the unionEquiv method), please
replace the three occurrences of ".getFullName" with ".getName" -- that should
fix the problem in the most surgical means possible. (I'm a bit nervous about
re-ordering the WRITER_UNION and READER_UNION cases as you do in your first,
suggested fix. And completely wiping out the guard on line 694 would
completely eliminate any name-based checking, which would relax the spec even
further, which I don't think we want to do).
> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema
> have an array of records with different full names (e.g. different
> namespace).
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.avro.Resolver$ReaderUnion cannot be cast to
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the
> jiras and code, I don't believe this was intentional ( AVRO-2275,
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
> ).
>
> It looks like there were some attempts to keep compatibility (
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
> , e.g. see the commented out check for w.getFullName() in resolve()) but
> this case was missed.
>
> See this simple example to reproduce.
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AVRO-2396) Huge performance regression on SpecificDatumReader for array reading
[
https://issues.apache.org/jira/browse/AVRO-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fokko Driesprong updated AVRO-2396:
---
Affects Version/s: (was: 1.9.1)
> Huge performance regression on SpecificDatumReader for array reading
>
>
> Key: AVRO-2396
> URL: https://issues.apache.org/jira/browse/AVRO-2396
> Project: Apache Avro
> Issue Type: Bug
> Components: csharp
>Affects Versions: 1.9.0
>Reporter: wangying
>Priority: Blocker
>
> The company where I'm working as a .NET developer is using Avro format for
> message.
> Recently, after upgrade to 1.9.0-rc2 and 1.9.0-rc4, there is a hug regression
> the read array object.
> Our test case reads a ETP defined object "Energistics.Datatypes.ChannelData"
> inside which contains 5000 dataitems, with previous avro version, it only
> took 300~ms to read the data, which with the last version it wooks 1+ min.
> (the protocol can found from
> [https://www.energistics.org/etp-developers-users/])
>
> After look through the code, I find that should be caused by a change in
> SpecificRecordAccess class
> public object CreateRecord(object reuse)
> {
> return reuse ?? ObjectCreator.Instance.New(typeName, Schema.Type.Record);
> }
> Here, the reuse is null, thus ObjectCreator.Instance.New is run 5000 times
> and each time use reflection to get specific types.
>
> the previously version only do it in constructor:
> private class SpecificRecordAccess : RecordAccess
> {
> private ObjectCreator.CtorDelegate objCreator;
> public SpecificRecordAccess(RecordSchema readerSchema)
> {
> objCreator = GetConstructor(readerSchema.Fullname, Schema.Type.Record);
> }
> public object CreateRecord(object reuse)
> {
> return reuse ?? objCreator();
> }
> }
>
> I'm trying to make a workaround and pass a reuse object in method public T
> Read(T reuse, Decoder decoder), but still not working since the
> SpecificDatumReader doesn't pass it through in below method.
> public void AddElements( object array, int elements, int index, ReadItem
> itemReader, Decoder decoder, bool reuse, object reuseobj)
> {
> var list = (IList)array;
> for (int i=0; i < elements; i++)
> {
> list.Add( itemReader(null, decoder ) );
> }
> }
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
