[
https://issues.apache.org/jira/browse/TINKERPOP3-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP3-816.
---------------------------------------
Resolution: Fixed
I removed the string interning, but perhaps as importantly I stopped the driver
from closing the channel if a {{SerializationException}} was encountered. In
this way, it becomes possible for the connection to keep working in the face of
what might not be a permanent error. Not sure what other errors might raise
that fit that pattern, but as they occur we can add them to the list. I'd like
to save channel close for the kinds of errors that might not be one-offs -
something that's like permanently destructive such that that host will just
never work with the driver.
Anyway, this was a nice bug report. Thanks for posting it.
> Gryo deserialization of error response with null message causes NPE and
> protocol desync
> ---------------------------------------------------------------------------------------
>
> Key: TINKERPOP3-816
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-816
> Project: TinkerPop 3
> Issue Type: Bug
> Components: driver
> Affects Versions: 3.0.1-incubating
> Reporter: Geoff Reedy
> Assignee: stephen mallette
> Fix For: 3.1.0-incubating, 3.0.2-incubating
>
>
> The issue can be easily reproduced by submitting a query that throws an
> exception with a null message, e.g.
> :> throw new RuntimeException()
> This results in a NPE on the client end in GryoMessageSerializerV1d0.dese
> rializeResponse
> The offending code is the invocation of .intern() on statusMsg on [line
> 208|https://github.com/apache/incubator-tinkerpop/blob/d33fb15fd5d70e90b81edf16aba489b8eb8f7730/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/ser/GryoMessageSerializerV1d0.java#L208]
> There are several ways to fix this problem, but I don't see the utility
> behind interning the message so I suggest removing the call to intern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
