Chaining Request Processing
Hello Good People! I need your help! I can't find a good answer where I've looked. Here's my problem: I have a web application client that shows a user a form to fill out and then submits the form input to a servlet in an application server (Appserver A) running Tomcat. The servlet (in Appserver A) then processes part of the form input in the doGet method and then needs to send the rest of the form to another web server (Appserver B) to process and return the results (response code or something) to the calling servlet which is waiting for it. The servlet receives the results and based on the results, sends response back to the client, all within the same doGet method. Is this doable, and What's the best way to go about it? Should I make the call to Appserver B in a separate thread (I'm considering it)? Thanks for your help. Jeng Send instant messages to your online friends http://uk.messenger.yahoo.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chaining Request Processing
From: Jeng Yu [mailto:[EMAIL PROTECTED] The servlet (in Appserver A) then processes part of the form input in the doGet method and then needs to send the rest of the form to another web server (Appserver B) to process and return the results (response code or something) to the calling servlet which is waiting for it. The servlet receives the results and based on the results, sends response back to the client, all within the same doGet method. Is this doable, and What's the best way to go about it? Best or Easiest to code? :-) Best from a performance point of view is to change your application so that it's *not* all happening in the same doGet call. You don't know how long your call will take. You should submit the request via some appropriate mechanism and return a holding page to the user. Every so often, the holding page should poll to see whether the call has completed. You'll need some way of storing the results from appserver B, along with a way of managing timeouts and similar. Since you've not said how appserver B expects its data, we can't really suggest specific technologies. This approach minimises the number of threads that will be waiting at any time. Easiest to code is to use the same doGet call. Be aware that you may tie up a *lot* of Tomcat threads waiting for responses from B. Your worst case is when B black-holes at the busiest time for your application, meaning that A has to wait for a timeout on every call. You'll need at least that many threads configured unless you want unpleasant error messages returned to your users. Should I make the call to Appserver B in a separate thread (I'm considering it)? If you're doing this in the same doGet call, why bother? It's extra overhead for no good reason - you're already tying up the Tomcat thread for the duration of the call. If you're changing your architecture, you'll definitely need to do this. - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chaining Request Processing
--- Peter Crowther [EMAIL PROTECTED] wrote: From: Jeng Yu [mailto:[EMAIL PROTECTED] The servlet (in Appserver A) then processes part of the form input in the doGet method and then needs to send the rest of the form to another web server (Appserver B) to process and return the results (response code or something) to the calling servlet which is waiting for it. The servlet receives the results and based on the results, sends response back to the client, all within the same doGet method. Is this doable, and What's the best way to go about it? Best or Easiest to code? :-) Best from a performance point of view is to change your application so that it's *not* all happening in the same doGet call. You don't know how long your call will take. You should submit the request via some appropriate mechanism and return a holding page to the user. Every so often, the holding page should poll to see whether the call has completed. You'll need some way of storing the results from appserver B, along with a way of managing timeouts and similar. Since you've not said how appserver B expects its data, we can't really suggest specific technologies. This approach minimises the number of threads that will be waiting at any time. Sorry, I should have mentioned how appserver B expects its data. Essentially, it expects its data via a URL call - post or get. In other words, appserver B is another web server elsewhere. So what options or specific technologies do you have in mind? Thanks, Jeng Send instant messages to your online friends http://uk.messenger.yahoo.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chaining Request Processing
On Tue, Aug 12, 2008 at 3:11 AM, Jeng Yu [EMAIL PROTECTED] wrote: The servlet (in Appserver A) then processes part of the form input in the doGet method and then needs to send the rest of the form to another web server (Appserver B) to process and return the results (response code or something) to the calling servlet which is waiting for it. The servlet receives the results and based on the results, sends response back to the client, all within the same doGet method. Is this doable, and What's the best way to go about it? It's certainly doable -- it's the standard use case for submitting an online order to a credit-card-authorization gateway, among others. Look at the JavaDoc for java.net.Http(s)URLConnection. HTH, -- Hassan Schroeder [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
