You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tim Funk <fu...@joedog.org> on 2004/06/16 19:22:21 UTC
Re: What's the right way to handle a long process without occupying
a tomcat processor/thread?
Use a backgorund thread to do the processing.
Then spit a page back to the user which uses a meta refresh to check the
status of the background thread. Place an animated gif on the meta refresh
page and the user will be none the wiser.
-Tim
Xiao F Chen wrote:
>
>
> Hello all, I have a scenario related to long process in handling a
> servlet request. I am using tomcat 4.1 with apache 1.3.9. In one of our
> applications, when a user logs in, we will determine if the account's
> email address has been verified or not. If not, the application will
> ask the user submit an email address for verification using JavaMail.
> The process to verify the address is to send an email message to the
> email address immediately. Most of times, the process is quick and we
> can get the real time info about whether or not the user account on the
> mail server is valid or not. But sometimes when the user's email server
> is down or slow, the process could take pretty long time to finish. In
> the later case, Tomcat's max processors could be used up and 'no
> processor available' error is thrown.
>
> I guess I can increase the maxProcessor number in server.xml (currently
> it is set to 75), but it seems not the ideal way. I am wondering
> whether or not I can spawn a new thread in the servlet and hand the
> email verification to the new thread for processing, then the main
> thread will return and be available for new request to reduce the 'no
> processor error'? One problem I can see is that even I can do what I
> stated above, some document suggest that after the main thread returns
> (for example, exit from the doGet method of a servlet), the
> HttpServletResponse's outputstream is closed and I can't send response
> to the user anymore. Is this right?
>
> Any suggestions for my situation.
>
> Thanks for your help.
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: What's the right way to handle a long process without occupying
a tomcat processor/thread?
Posted by Tim Funk <fu...@joedog.org>.
Here's some bad pseudo code ...
-- process.jsp --
/*
Make ThreadyThing implements Runnable, its constructor will start itself
as a background thread and do your processing. Expose a method
isDone() to be flag to let you know when its done.
*/
<%
session.setAttribute("thread", new ThreadyThing(args));
response.sendRedirect("wait.jsp");
%>
==========
-- wait.jsp --
<%
ThreadyThing thing = (ThreadyThing)session.getAttribute("thread");
if (thing.isDone()) {
//cleanup
return
}
%>
<META HTTP-EQUIV=Refresh CONTENT="10;">
<img src='still_doningcrap.gif'/>
-Tim
Michael Cardon wrote:
> Tim,
>
> Do you have a code example of this solution? I would be very interested in
> setting something like this up.
>
> Thanks.
>
> Michael
>
> -----Original Message-----
> From: Tim Funk [mailto:funkman@joedog.org]
> Sent: Wednesday, June 16, 2004 10:22 AM
> To: Tomcat Users List
> Subject: Re: What's the right way to handle a long process without
> occupying a tomcat processor/thread?
>
>
> Use a backgorund thread to do the processing.
>
> Then spit a page back to the user which uses a meta refresh to check the
> status of the background thread. Place an animated gif on the meta refresh
> page and the user will be none the wiser.
>
> -Tim
>
> Xiao F Chen wrote:
>
>
>>
>> Hello all, I have a scenario related to long process in handling a
>> servlet request. I am using tomcat 4.1 with apache 1.3.9. In one of our
>> applications, when a user logs in, we will determine if the account's
>> email address has been verified or not. If not, the application will
>> ask the user submit an email address for verification using JavaMail.
>> The process to verify the address is to send an email message to the
>> email address immediately. Most of times, the process is quick and we
>> can get the real time info about whether or not the user account on the
>> mail server is valid or not. But sometimes when the user's email server
>> is down or slow, the process could take pretty long time to finish. In
>> the later case, Tomcat's max processors could be used up and 'no
>> processor available' error is thrown.
>>
>> I guess I can increase the maxProcessor number in server.xml (currently
>> it is set to 75), but it seems not the ideal way. I am wondering
>> whether or not I can spawn a new thread in the servlet and hand the
>> email verification to the new thread for processing, then the main
>> thread will return and be available for new request to reduce the 'no
>> processor error'? One problem I can see is that even I can do what I
>> stated above, some document suggest that after the main thread returns
>> (for example, exit from the doGet method of a servlet), the
>> HttpServletResponse's outputstream is closed and I can't send response
>> to the user anymore. Is this right?
>>
>> Any suggestions for my situation.
>>
>> Thanks for your help.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: What's the right way to handle a long process without occupying a tomcat processor/thread?
Posted by Michael Cardon <mi...@bendcable.com>.
Tim,
Do you have a code example of this solution? I would be very interested in
setting something like this up.
Thanks.
Michael
-----Original Message-----
From: Tim Funk [mailto:funkman@joedog.org]
Sent: Wednesday, June 16, 2004 10:22 AM
To: Tomcat Users List
Subject: Re: What's the right way to handle a long process without
occupying a tomcat processor/thread?
Use a backgorund thread to do the processing.
Then spit a page back to the user which uses a meta refresh to check the
status of the background thread. Place an animated gif on the meta refresh
page and the user will be none the wiser.
-Tim
Xiao F Chen wrote:
>
>
> Hello all, I have a scenario related to long process in handling a
> servlet request. I am using tomcat 4.1 with apache 1.3.9. In one of our
> applications, when a user logs in, we will determine if the account's
> email address has been verified or not. If not, the application will
> ask the user submit an email address for verification using JavaMail.
> The process to verify the address is to send an email message to the
> email address immediately. Most of times, the process is quick and we
> can get the real time info about whether or not the user account on the
> mail server is valid or not. But sometimes when the user's email server
> is down or slow, the process could take pretty long time to finish. In
> the later case, Tomcat's max processors could be used up and 'no
> processor available' error is thrown.
>
> I guess I can increase the maxProcessor number in server.xml (currently
> it is set to 75), but it seems not the ideal way. I am wondering
> whether or not I can spawn a new thread in the servlet and hand the
> email verification to the new thread for processing, then the main
> thread will return and be available for new request to reduce the 'no
> processor error'? One problem I can see is that even I can do what I
> stated above, some document suggest that after the main thread returns
> (for example, exit from the doGet method of a servlet), the
> HttpServletResponse's outputstream is closed and I can't send response
> to the user anymore. Is this right?
>
> Any suggestions for my situation.
>
> Thanks for your help.
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org