https://issues.apache.org/bugzilla/show_bug.cgi?id=50667
--- Comment #4 from Olivier Costet <ocos...@zenprise.com> 2011-01-27 12:55:27 EST --- (In reply to comment #3) > I still don't understand this enhancement. What is the possibly use case for > implementing replyFailed. > The callback method replyFailed would get called to the receiver. And this is > backwards. There is nothing the receiver can do if reply fails. There are no > actions to be taken. It wont allow the receiver to retry the attempt. So the > method is at best a no-op, but really just a method one has to implement with > zero benefit. The sender still has to make a decision on what to do without a > reply. To reiterate: The specific case where I felt the need for such a callback was one where I was shuttling objects across nodes -- by "shuttling" I mean removing them from one and putting them on the other. I would receive a request for a specific object through the RpcChannel, look the object up, unregister it locally, pack it in the reply, send the reply. If the sending failed, I would want to re-register the object locally, so as not to lose data. What is it that makes you consider this use-case invalid? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org