On Sun, 1 Jul 2001, Ole Husgaard wrote:
> 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.
Absolutely. Monitoring is crucial and enforcing resource constraints is as
well part of the whole picture. Some people in our group have done work on
resource constraining a Win32 application in a user-level
sandbox. Perhaps, this work can be extended further into application
server domain. The costs, though may have to be measured in advance by
profiling an application under real-life usage patterns and measuring
costs of invocations in a given path. The profiling support is what I am
aiming for.
>
> 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.
>
You can even think of different service providers 'lending' each other
their service resources (our group is working on developing infrastructure
for setting up the agreements) See the page of publications:
http://www.cs.nyu.edu/pdsg/projects/cc/cc.htm
> 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.
There are also ideas of making the AS 'adapt' to overload by asking the
router to start dropping certain packets. But that would require
cooperation between the router and the AS. Same applies for denial of
service attacks.
>
> 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?
>
It is a mess. Right now we are thinking of doing it through profiling a
running application and detemining hot request paths and significant
server actions (like transaction creation, database access, etc.) along
the request path. This may not be perfect, but we do have to start
somewhere.
Anatoly.
>
> Best Regards,
>
> Ole Husgaard.
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
