:checkRetryAfterException}}}.

Added the {{{MarshalException}}} handling.
Added correct property lookup to the exception test.

1 files changed, 27 insertions, 2 deletions

diff --git a/cppe/src/IceE/ProxyFactory.cpp b/cppe/src/IceE/ProxyFactory.cpp
index 361e90a7585..fc38e162238 100644
--- a/cppe/src/IceE/ProxyFactory.cpp
+++ b/cppe/src/IceE/ProxyFactory.cpp
@@ -107,12 +107,37 @@ IceInternal::ProxyFactory::checkRetryAfterException(const LocalException& ex, co
 	ir->getLocatorInfo()->clearObjectCache(ir);
     }
     else
-#else
+#endif
     if(dynamic_cast<const RequestFailedException*>(&ex))
     {
 	ex.ice_throw();
     }
-#endif
+
+    //
+    // There is no point in retrying an operation that resulted in a
+    // MarshalException. This must have been raised locally (because if
+    // it happened in a server it would result in an UnknownLocalException
+    // instead), which means there was a problem in this process that will
+    // not change if we try again.
+    //
+    // The most likely cause for a MarshalException is exceeding the
+    // maximum message size, which is represented by the the subclass
+    // MemoryLimitException. For example, a client can attempt to send a
+    // message that exceeds the maximum memory size, or accumulate enough
+    // batch requests without flushing that the maximum size is reached.
+    //
+    // This latter case is especially problematic, because if we were to
+    // retry a batch request after a MarshalException, we would in fact
+    // silently discard the accumulated requests and allow new batch
+    // requests to accumulate. If the subsequent batched requests do not
+    // exceed the maximum message size, it appears to the client that all
+    // of the batched requests were accepted, when in reality only the
+    // last few are actually sent.
+    //
+    if(dynamic_cast<const MarshalException*>(&ex))
+    {
+	ex.ice_throw();
+    }
 
     ++cnt;