[
https://issues.apache.org/jira/browse/AVRO-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-12:
-----------------------------
Attachment: AVRO-12.patch
This will also happen if you call hashCode() on such a schema.
A simple, yet slow, solution would be to implement both equals and hashCode in
terms of toString(), since that already does loop detection. We could
alternately add loop detection to equals and hashCode(). An efficient way
might be to keep fast and slow pointers as we walk, to detect loops
(http://franz.com/support/documentation/6.2/ansicl/dictentr/list-len.htm) but
that would require re-implementing equals and hashcode for collection classes.
So an expedient way might be to use a ThreadLocal<Set> to keep track of what's
been seen.
I've attached a patch that does this. I use an IdentityHashMap for hashCode,
and no memory is allocated once this table is initialized. For equals we track
the pair of values being compared, so must use a set and allocate a short-lived
object per call.
Does this look reasonable?
> Bug in comparison of recurisive schemas
> ---------------------------------------
>
> Key: AVRO-12
> URL: https://issues.apache.org/jira/browse/AVRO-12
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.0
> Reporter: Hong Tang
> Fix For: 1.0
>
> Attachments: AVRO-12.patch
>
>
> Comparison of recursive schema will lead to infinite recursion (eventually
> leading to java.lang.StackOverflowError.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
