Hi,
Anatoly Akkerman wrote:
> Beware, you are entering the twilight zone. This is the direction
> 'adaptive' system take -- very active research area in CS.
I guess this also overlaps a little with
advanced monitoring and policing.
Coming from the networking world, I have been
thinking about adding support for policing
incoming invocations, using advanced queueing
strategies for incoming invocations like the
class based queueing (or even simple priority
queueing) used in some network routers.
For example:
A server has two kinds of clients: Those who
pay and those who get the same for free.
Lots of people want the service for free, so
the server is overloaded. Overloaded servers
do not perform well, so the overload hurts
the paying clients.
Now, let us assume that we can classify incoming
requests into "pay" and "free" requests, and
that we can measure the processor time used
for each invocation when it is done.
When under load, we want the server to spend
about 80% of the time to handle "pay" requests,
and the remaining 20% to handle "free" requests.
If there are not enough requests of one class
to fill the quota, the requests of the other
class can "borrow" from the not quite utilized
quota of the other class, so the server will
not be idle while there is work to do.
I think this would be possible in JBoss if we
could measure the hardware usage of each bean
invocation.
Similar queueing and policing is done routinely
in modern IP routers (see Traffic Control in
your Linux kernel) for the output queues, and
the differences are only a few:
Instead of packet size we measure processor
time spent. That means that we do not have the
measurement for a particular invocation until
after we have scheduled it, and that may
introduce some small short-term error to the
scheduling algorithm.
Also, in case of extreme overload, IP routers
start dropping packets. JBoss does not drop
invocation requests, or throw "Server overload,
please try later" exceptions at the client. I
think it would be a good idea if JBoss could do
that, but unfortunately we do not currently
know when we have a serious overload situation.
But if we have input queueing for invocation
requests, knowing is simple: When the input
queue is full, we have overload and throw
exceptions at clients coming with new requests.
While I have these ideas in the back of my head
I am not actually thinking about implementing
them in the near future. Main obstacle is that
have no good and fast way of measuring the
hardware utilization of a thread. Another
obstacle is that the low-level, server-side RMI
implementation probably would have to be
changed, as we do not want to have a RMI thread
waiting for each invocation request enqueued.
How do you get the measurements needed for the
adaptation?
Best Regards,
Ole Husgaard.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
