On 29.01.2017 16:57, Abdessamed Mansouri wrote:
Hello,
Thank you all for your suggestions and thank you André and Mark, so as
André said that we can do it with servlet filters
Hm, be careful, I did not really say that. All I said, was that this would be my own first
idea of how one could possibly achieve this, *without* having to modify the servlet's code.
But my own knowledge of Java or Tomcat internals is not sufficient to allow me to know if
this is really possible (and Mark, who is infinitely more knowledgeable about this than I
am, seems to say that it is not possible to do this in the way I was suggesting).
and i prefer that because
it depends on servlet spec not on Tomcat internals as valves, we will see
how to hook up the code to make it checks periodically for interupt flag as
Mark said.
If you can modify the application code to make it check some condition periodically, then
it should not be very difficult.
If you cannot (or do not want to) modify the application code (the "runaway" servlets),
then it may be more difficult.
My idea was indeed :
1) to use a servlet filter, because
- it is standard servlet spec
- you can configure it to "wrap" any servlet, even if you do not know which ones are
the runaways
- you do not need to modify the wrapped servlet(s) in any way
2) that servlet filter starts a timer, of which you can configure the duration
3) when the timer expires, it calls some callback routine
4) and (crucial point), this callback routine can interrupt the currently
running servlet
"from the outside" using some existing Java mechanism, even if that servlet is not
"expecting" to be interrupted at that point.
And that is precisely what I do not know : if such an interrupt mechanism is
possible.
If not, then my servlet filter based suggestion is not worth considering.
In fact, I was thinking of some mechanism like this one of Apache httpd :
http://httpd.apache.org/docs/2.4/mod/mod_cgid.html#cgidscripttimeout
It does anyway sound like a nice feature suggestion for a future Tomcat release.
(We do have similar issues with some externally-provided tomcat applications which we use,
and for which we do not have the code to be able to modify them).
Thank you so much again for your help and your time and have nice day.
Welcome, and thank you in any case for this polite and interesting discussion.
2017-01-27 10:39 GMT+01:00 Mark Thomas <ma...@apache.org>:
On 27/01/2017 08:24, Abdessamed Mansouri wrote:
Thank you for your time and your suggestion and sorry for late response..
I don't know if that is possible in servlet filter, because we don't
really
want to kill the thread, we want only to stop it and return it to Tomcat
thread pool for it be used again to handles new requests, so i think we
should write a special thread pool which do that for us (that what is
currently in my head).
Unless the long running code is going to respond to an interrupt in
timely manner, this is never going to work.
If the long running code will respond to an interrupt, a relatively
simple filter or valve that tracks in progress requests (it will need a
dedicated thread to periodically loop through the requests and interrupt
the ones running longer than the given threshold) will do the trick.
Mark
2017-01-23 14:06 GMT+01:00 André Warnier (tomcat) <a...@ice-sa.com>:
On 23.01.2017 13:41, Abdessamed Mansouri wrote:
Hello, Thank you for your answers, we are integratting JSF (Mojarra)
and
using it, so in many cases, in the same page there's some
functionnalities
which work and other not, there's also some functionnalities which work
with a little data (reasonable time) but with a little larger data take
too
much time because of bad implementation and i have fear to say that we
really don't know all,the functionnalities which dont work (takes too
much
time).
We think this is the only (not necessary) temporary solution.
Thank you all.
Hi. Apart from the suggestions below, I don't think that there is
anything
"out of the box" which does the kind of thing you want.
So you might have to write this yourself.
I am not really an expert, but in terms of architecture this might be a
job for a "servlet filter", which starts a timer before forwarding the
call
to the real application.
How the filter would have to react, when it is called by the timer
after 5
minutes, in order to "kill" the running servlet and return an
informative
response to the caller, is beyond me though, specially without modifying
the servlet itself.
Generating an exception and catching it in the response part of the
filter
?
2017-01-23 12:43 GMT+01:00 André Warnier (tomcat) <a...@ice-sa.com>:
On 23.01.2017 12:37, Aurélien Terrestris wrote:
Hello,
if it is possible to know which servlet is involved in this problem,
maybe
could you update the web.xml and deactivate this servlet by
commenting
its
servlet mapping. You would then get 404 errors, but maybe it's better
than
your problem now.
regards
A.T.
I suppose that you could also, instead, map these servlets to some
nice
static html page, with a message telling the user that it is disabled,
and
ask them to use the "back" button to return to the previous page.
2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri <
amanso...@alti-dz.com>:
Hello all,
We have an application which turns on Tomcat and suffer from bad
performance (we are trying to find a solution by reimplementing
it), so
there's many many many simple functionnalities which take too much
time
(bad implementation) sometimes up to 30mins (and to hours), so our
client's
employees dont use these functionnalities but sometimes by mistake
they
run
some of it which make all the entire server slow for all other
employees
because the tomcat request handler threads still turning in
background,
so
temporarily we are seeking for a way (through config or code
hacking)
to
let Tomcat stops it's threads after some amout of time if they
didn't
completed, for exemple : Tomcat will stop any of its running thread
after 5
mins if the thread doesn't completed.
Tomcat version : 7.0.35
Thanks
--
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies - ALTI Algérie
Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour –
16106
–
Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
