ricetons at gmail.com
Sat Aug 4 11:48:51 CDT 2007
Thanks for your reply.
C++NPv2 states that the order of event handler dispatching is based on
empirical results and application should be rely on the order. However, many
servers tend to disconnect with the clients if they are idle in order to
release the resources for performance concerns, for example, the default
configuration of ACE limits applications can only open FD_SETSIZE (typically
1024 on Linux) handles simultaneously, which means the Reactor can handle
1024 TCP connections at best, and disconnecting idle connections would
benefit the throughput.
A common practice is that to disconnect the connection in handle_timeout(),
which cause the problem.
It is okay for the client that the server refuses connections from the
clients, but it might be a bit of frustrating for the clients if they sent
the request and disconnected without any responses :-(. In those cases,
timeout events just indicates the clients are idle which does not need to be
precise, so it seems that the current order in dispatch_i() would be unfit
for some application.
I check the code again and I found the comments are still here:
ACE 5.5.10, Line 217:
// If there are no signals and if we had received a proper
// event_count then first look at dispatching timeouts. We need to
// handle timers early since they may have higher latency
// constraints than I/O handlers. Ideally, the order of dispatching
// should be a strategy...
And I'm free now, I will work on the issue and write some codes to add a new
strategy for the reactors. I think it will take a day or two,
but how can I submit these codes?
----- Original Message -----
Please use the PROBLEM-REPORT-FORM.
> Currently I'm working on a HTTP server based on ACE, and I found
> that the implementation of TP Reactor on ACE 5.5.10 might cause some
> problems when there're many connections.
> The implementation of dispatch_i() is the following (simplified):
> this->handle_timer_events (event_count, guard);
> this->handle_notify_events (event_count, guard);
> this->handle_socket_events (event_count, guard);
Right. C++NPv2 section 4.2 describes this ordering and the rationale a
bit more. For more info on C++NPv2, please see
> I have to register a timeout event on the reactor when a new
> comes, in order to disconnect it when it is idle. However, the
> might be buggy considering the following timing sequence:
> Connection A comes
> Connection B comes
> The peer of connection B send some data
> Handle_events() ( Invoke handle_input() to process B's request)
> The peer of connection A send some data
> A timeout
> Handle_events() ( Invoke handle_timeout() for A)
> We can see that the request from connection A is lost.
That depends on what you do when you get the timeout.
> When the server has many connections and limited threads for
> them, it seems that the sequence above happens occasionally, which
> frustrating for a HTTP server, making HTTP client gets nothing.
> It seems that making handle_socket_events() comes first in
> would solve the problem. But I also noticed that Prof. Schmidt once
> mentioned the primary concern of the implementation is to maximize
> throughput, yet it would be useful for TCP server to change the
> of the events for better services.
The reason timeouts are services first is that they're often required
to be fairly precise. If you wanted a timeout every 100 msec, for
example, then doing all the socket work prior to timeouts may prohibit
your timer from being delivered correctly.
> The comments of ACE 5.5.1 says that introducing an Strategy class
> would solve problem, but those comments are gone in ACE 5.5.10. Does
> means that the problem is solved?
What problem ;-) I'm not sure where the comment went, but if you have
a need for this type of strategizing, it would be great if you can
develop such a capability and submit it to ACE!
Steve Huston, Riverace Corporation
Would you like ACE to run great on your platform?
More information about the Ace-users