dschneider-pivotal commented on a change in pull request #6561:
URL: https://github.com/apache/geode/pull/6561#discussion_r658169307
##########
File path:
geode-core/src/main/java/org/apache/geode/cache/client/internal/QueryOp.java
##########
@@ -120,7 +122,16 @@ protected Object processResponse(Message msg) throws
Exception {
queryResult = resultPart.getObject();
} catch (Exception e) {
String s = "While deserializing " + getOpName() + " result";
- exceptionRef[0] = new SerializationException(s, e);
+ if (e instanceof PdxSerializationException) {
Review comment:
The conversion of PdxSerializationException to an IOException while
reading a query response seems like a hack to fix a problem that we do not yet
understand. What do you think of it being disabled by default and only enabled
if a system property "gemfire.enableQueryRetryOnPdxSerializationException" is
true? This would give the current customer a workaround if they set the new
system property.
You should also document that this workaround will only work if the client
is configured to connect to more than one cache server AND the pool's
"retry-attempts" is -1 (the default which means try each server) or > 0. It is
possible that if you closed the current connection and got a new connection to
the same server and retried the query to it that it would also workaround this
issue and it would not have the limitations of needing multiple servers and
would not depend on the retry-attempts configuration.
Since we have not been able to reproduce this issue can we get the customer
to test this workaround in their environment to confirm it will solve their
issue?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
