[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers
[ https://issues.apache.org/jira/browse/GEODE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364870#comment-16364870 ] ASF subversion and git services commented on GEODE-4377: Commit e44bf9e7bdbd9684c3194fc56468fdcd4b910b80 in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e44bf9e ] GEODE-4377: Don't catch encoding exceptions in OperationHandlers Galen pointed out that the changes for this ticket changed behavior when we get an encoding error. The changes cause the connection to be closed but we used to leave it open. This commit reverts to the old behavior. The connection will remain open and the client can continue to do goofy things and get error responses. > Don't catch encoding exceptions in OperationHandlers > > > Key: GEODE-4377 > URL: https://issues.apache.org/jira/browse/GEODE-4377 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h > Remaining Estimate: 0h > > In the protobuf protocol, we are currently catching EncodingException due to > values that we can't deserialize or result values that we can't serialize. > Encoding and decoding exceptions should be handled differently, so clients > can tell if a value was present but could not be serialized. > Encoding and decoding errors should be handled consistently across operation > handlers. > Probably we could throw Encoding or Decoding exceptions and handle them at a > higher level than the individual op handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers
[ https://issues.apache.org/jira/browse/GEODE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364658#comment-16364658 ] ASF subversion and git services commented on GEODE-4377: Commit dec2cfe1e650d5adcfd41ecabe9b0c9a3f3dc91f in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dec2cfe ] GEODE-4377: Don't catch encoding exceptions in OperationHandlers This adds DecodingException and moves the handling of EncodingException and this new exception to ProtobufOpsProcessor. I've also added tests for getAll and putAll to ensure that their handlers properly process all entries in the presence of a Key or Entry decoding error. This closes #1434 > Don't catch encoding exceptions in OperationHandlers > > > Key: GEODE-4377 > URL: https://issues.apache.org/jira/browse/GEODE-4377 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > In the protobuf protocol, we are currently catching EncodingException due to > values that we can't deserialize or result values that we can't serialize. > Encoding and decoding exceptions should be handled differently, so clients > can tell if a value was present but could not be serialized. > Encoding and decoding errors should be handled consistently across operation > handlers. > Probably we could throw Encoding or Decoding exceptions and handle them at a > higher level than the individual op handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers
[ https://issues.apache.org/jira/browse/GEODE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362863#comment-16362863 ] ASF subversion and git services commented on GEODE-4377: Commit 6f251af8830a728eaedfda6f72e949e344710504 in geode's branch refs/heads/feature/GEODE-4377 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6f251af ] GEODE-4377: Don't catch encoding exceptions in OperationHandlers Addressing review comments. I've added unit tests to ensure that a Success response is returned to the client if there are any encoding/decoding errors encountered while processing entries. In ProtobufResponseUtilities I've modified the error message to contain the toString() of the exception, which will include the exception class name and the exception's message. > Don't catch encoding exceptions in OperationHandlers > > > Key: GEODE-4377 > URL: https://issues.apache.org/jira/browse/GEODE-4377 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > In the protobuf protocol, we are currently catching EncodingException due to > values that we can't deserialize or result values that we can't serialize. > Encoding and decoding exceptions should be handled differently, so clients > can tell if a value was present but could not be serialized. > Encoding and decoding errors should be handled consistently across operation > handlers. > Probably we could throw Encoding or Decoding exceptions and handle them at a > higher level than the individual op handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers
[ https://issues.apache.org/jira/browse/GEODE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361624#comment-16361624 ] ASF subversion and git services commented on GEODE-4377: Commit 8989ab58ee21c8095449764eac4589adb6624b5a in geode's branch refs/heads/feature/GEODE-4377 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8989ab5 ] GEODE-4377: Don't catch encoding exceptions in OperationHandlers Adding missing file: DecodingException.java > Don't catch encoding exceptions in OperationHandlers > > > Key: GEODE-4377 > URL: https://issues.apache.org/jira/browse/GEODE-4377 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In the protobuf protocol, we are currently catching EncodingException due to > values that we can't deserialize or result values that we can't serialize. > Encoding and decoding exceptions should be handled differently, so clients > can tell if a value was present but could not be serialized. > Encoding and decoding errors should be handled consistently across operation > handlers. > Probably we could throw Encoding or Decoding exceptions and handle them at a > higher level than the individual op handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers
[ https://issues.apache.org/jira/browse/GEODE-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361523#comment-16361523 ] ASF subversion and git services commented on GEODE-4377: Commit 6e255ecf1fddde7440079d148fdcfca5c6bcbf5b in geode's branch refs/heads/feature/GEODE-4377 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6e255ec ] GEODE-4377: Don't catch encoding exceptions in OperationHandlers This adds DecodingException and moves the handling of both EncodingException and DecodingException to ProtobufOpsProcessor's processOperation() method. > Don't catch encoding exceptions in OperationHandlers > > > Key: GEODE-4377 > URL: https://issues.apache.org/jira/browse/GEODE-4377 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > > In the protobuf protocol, we are currently catching EncodingException due to > values that we can't deserialize or result values that we can't serialize. > Encoding and decoding exceptions should be handled differently, so clients > can tell if a value was present but could not be serialized. > Encoding and decoding errors should be handled consistently across operation > handlers. > Probably we could throw Encoding or Decoding exceptions and handle them at a > higher level than the individual op handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
