Thanks much for the response, and sorry for taking so long to respond
myself. I've just dug out from under a bit of a coding frenzy.
Comments inline below ...
Erkin wrote:
Hi David
Even though I dont know what kind of application you are trying to build, I
would like to give you some idea...
Outgoing messages....
As you know that there is some part of your business logic creates outgoing
messages. If you create an Executor filter between underlying transport
layer and business logic, there is no way business logic will know about
problems at transport layer unless you write some callbacks as well.
Not sure I understand.
The way my server code is set up is that I have a custom IOHandler
implementation that's handling the incoming messages and returning
responses. In this handler class I'm implementing the
exceptionCaught(IoSession session, Throwable cause) method to handle
errors that occur. This seems to be working fine, as I am seeing that
method called when an unexpected error occurs (e.g., when I alter the
code to force a null pointer exception).
So I'm not sure what you mean when you say that the business logic won't
know about problems at the transport layer. I'd think that the setup I
have shows that the logic does get notified about problems. Can you
elaborate then a bit more about what the problem is and why my code
wouldn't work correctly here?
Such as:
Business thread 1 starts processing your business logic, and send message
out. Executor Filter will buffer your outgoing message till a thread in
executor becomes available to send/process it. So Now your application
management issues can be buffer size, knowing whether you send message out
successfully or not and whether you send message on time or not.
Well, if there were, say some problem at the transport layer where MINA
was unable to send a queued response message ....
I guess my thinking is somewhat "so what"? I mean, the remote user
issued a command, my server carried out the command, and then it got an
error while trying to send a response back to the user indicating that
it carried it out. But I'm not sure what the business logic could do in
that case even if it were notified. The request has already been
carried out, so it can't really undo it. And there's no internal state
in the business logic that would need to be notified about the error
(e.g., in order to update its state). The only useful thing I could
really see happening with the error information would be for it to get
logged into the server logs - which I assume MINA will do for me anyway.
So again, not sure I see why I'd need to remove the 2nd thread pool here.
Inbound Messages:
Quick Question for you : What if codec fails decode incoming message, how
are you planing to return a response?
In my handler:
public void messageReceived(IoSession session, Object messageObj)
throws Exception {
String cmdStr = messageObj.toString().trim();
ProtocolResponse response;
try {
logger.debug("RECEIVED MESSAGE: {}", cmdStr);
ProtocolCommand cmd = parseCommand(cmdStr, session);
logger.debug("EXECUTING COMMAND: {}", cmd.toString());
response = cmd.execute();
}
catch(Exception e) {
response =
ProtocolResponse.createFailResponse(ProtocolUtils.getReasonCode(e),
e.getMessage());
}
writeResponse(session, response);
}
So within the messageReceived method the logic is to always return
either a success response or a fail response.
It wouldn't be a problem if sender
side waits for async response... But if it waits for sync response, when are
you planing to return the response?
Actually, I do have the client side waiting for a sync response. Why is
that a problem though? At worst I'd think there'd just be a brief (far
less than 1 second) bottleneck if the write thread pool had a lot of
response messages queued up. Doesn't seem to me like having a write
thread pool would ruin the sync response capability.
DR
