|IMHO, this kind of long transactions void scalability due to the
|locking issues. It should be avoided by jBoss users, but we
|should also be tolerant and allow it.
maybe it is a matter of time... one minute is short imho one hour long
|During server overload timeouts are normal. If we had no timeouts,
|or if the timeout is set to a very long time, users would call IT
|staff and complain: "The server does not reply, nothing happens
|when I try to use it."
good point...
|But if timeouts are set to a sensible value, the user of an
|overloaded server would get a "timed out" error before calling
|IT staff.
sensible is the key... 5 min? 10 min?
|We could, but please consider the consequences: Every bug report
|we get that would have been "timeout problem" will instead be
|"server hang problem", as no users are going to wait an hour
|to see if a timeout would happen. And this would not only be the
|user having a long transaction: Other users may be locked out
|because of a long transaction, and experience a "server hang
|problem" too.
Before we get to what the users percieve we must get past what the
developers and the J2EE administrators percieve of us :)))
hence this discussion by the way <g>
|TimeoutFactory only works with absolute time in milliseconds
|since epoch.
what's epoch
|I think that the next j2ee RI will send a mail with a
|"special offer" for a SUN server when it detects that
|this old 386 can't stand the heat ;-)
LOL, excellent
|A lot of server implementations get around this by
|taking extra steps to ensure that the server does not
|start working on more jobs than it can handle.
|This is often done by some kind of incoming request
|queue. When a request comes in and the server is
|experiencing overload the request is enqueued. This way
yes I was thinking about that yesterday. In fact our Metrics Interceptor
can be the first one to admit queued request (JMS) and turn the valve
"on-off" as the load goes....
we are in sync on that it seems. Wanna look at it?
|(almost) no processor time is spent on the request.
|When the server finds time to service the request, it
|is taken out of the queue to be serviced. But if the
|server cannot find time to service the request, the
|request is either simply dropped, or an error is
|returned to the client.
|This approach is sometimes called "request policing",
glad to hear it is standard procedure, it is also the way SAP does it btw
|as the server acts as a traffic controller for the
|incoming requests.
|Depending on how the input queue is implemented this
|can also help with some types of DOS attacks.
|
|Sorry for the length of this answer, but I am afraid
no, no don't be sorry, the whole made a lot of sense.
I still believe we should "prioritize" who we need to wooo with the server
and I think the short time outs make us a disservice with the admins and
developers... timeout setting to short can be done by the admin at a latter
stage but for now let's not missunderstand who we need to WIN RIGHT NOW!
(Admins, developers already love us :)))
Ease of use, stability, JMX all that is really targeted at the Admin the
real mac-coy.
|that setting the timeout value too high might cause
|other, worse problems for us and other jBoss users
|than a "timed out" exception.
|
|
|Best Regards,
|
|Ole Husgaard.
marc
|
|
