https://issues.apache.org/bugzilla/show_bug.cgi?id=50648
--- Comment #3 from Olivier Costet <ocos...@zenprise.com> 2011-01-27 06:17:20 EST --- @Mark Sorry about that. I'll file seperate entries and will try to match the style. (In reply to comment #2) > 2. > What type of exceptions have you seen here? > Reply failed callback, is a strange callback, since the receiver, not the > sender would receive that callback. That would make for some confusing > programming logic. The sender will simply timeout, and not get the reply, and > has to act accordingly. But I'm not sure the receiver needs to be notified. I haven't /seen/ any exceptions, but I would assume any exception that can be thrown by a normal Channel#send could come up here, since a Channel#send is what happens. The RpcCallback interface contains both callbacks that are invoked on the sender (leftOver) and receiver (replyRequest) side. If that isn't confusing, I don't see why adding one would be. The specific case where I felt the need for such a callback was one where I was shuttling instances across nodes -- by "shuttling" I mean removing them from one and putting them on the other. I would receive a request through the RpcChannel for an instance, look it up, unregister it locally, pack it in the reply, send it. If the sending failed, I would want to re-register it locally, so as not to lose data. Whatever you may think of that usage, the fact remains that there's a discrepancy between requests on an RpcChannel, where the sender is notified of communication errors, and replies on the RpcChannel, where he (the sender of the reply) isn't. Even though in both cases it's the same Channel#send that is performed. > 3. > The external loaders IMHO don't belong here. > For the applications that wish to provide custom class loading, I would simply > send messages using the ByteMessage class. That way you have full control over > what is happening. It's true, you could use ByteMessages. Although as an API user, your code would become more clunky, and you'd lose the ability to quickly look up the message's class. Wouldn't it be nice to have, though? It makes things easier, cleaner and doesn't add any significant overhead. Also, as things stand, the tribes API is somewhat misleading in that it offers to send Serializable messages (methods like Channel#send take Serializable arguments), when in practice all your app's classes are excluded, no matter how Serializable they may be. -- 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
