[
https://issues.apache.org/jira/browse/AVRO-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905684#action_12905684
]
Scott Carey commented on AVRO-650:
----------------------------------
The first two stack traces indicate that the parser's position is corrupted,
probably due to a race condition. It pulled a null symbol off the stack in the
second trace, and an invalid one in the first.
The second two traces look like they could happen if the catch block at
Responder.java:152 is hit before Responder.java:109 completes. This would
mean that handshake() threw an exception and I would suspect we would see a log
warning about that associated with that.
ResponderServlet.java has a single reference to one Responder that alll threads
use. This is probably the source of the problem. Responder.respond() looks
threadsafe, but handshake() does not.
handshake uses a handshakeReader member variable, that I'm pretty sure maps to
the race condition in the Parser.
That is my guess, I don't have things set up to be able to reproduce or
validate this however.
The simplest fix would be to change the Responder member variable in
ResponderServlet to a ThreadLocal<Responder>, and make sure that the Servlet
destroy() method clears the ThreadLocal.
> failures under client concurrency
> ---------------------------------
>
> Key: AVRO-650
> URL: https://issues.apache.org/jira/browse/AVRO-650
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.4.0
> Reporter: Eric Evans
> Assignee: Thiruvalluvan M. G.
> Priority: Blocker
> Attachments: exceptions.txt, tester.py
>
>
> I'm having trouble getting any client concurrency out of cassandra's rpc
> server. Running the attached `tester.py' from more than one terminal window
> is enough to generate the exceptions seen in `exceptions.txt'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
