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

Reply via email to