Delaying server [servlet] response

> I'm with the Doc here; why? What are you really

> trying to do?

>

> On wait() though: to learn what wait() does read a

> threading tutorial. Google "java thread tutorial" to

> find some. Perhaps you are looking for Thread.sleep()

> instead?

After my second post I figured there was some knid of configuration setting to slow down the server / servlet response times. I'm still trying to slow it down and I didn't try thread.sleep in the servlet class.

I know know that the HTTPservlet framework runs on top of the event system and it doesn't rely on threads.

The only reason for why I'm trying to slow down my AJAX app servlet is to simulate a slow connection. I'm trying to see if I should add the focus element to the input text box and count how long it was since a key was pressed and released. By doing that my AJAX program would delay sending a request to say a Database until it was likely that an entire String was put in the text box. I've never done some fo that stuff before and I just want to see what happens if I type a few letters into my input box on a slow simulated connection and tab over to another input box before the response has come back from the servlet.

I think it'll work perfectly fine because it'll concatinate the String and return a value and the JS will modify the innerHTML of my DIV tag. Basically I was thinking that it could save bandwidth and CPU overhead on the DB server if it was hit less often. Even if the difference in overhead is neglidgable I'd still like to simulate a slow connection or delay.

Thanks in advance for any help

-ls6v

ls6va at 2007-7-16 13:51:22 >

> Backing up the other 2 guys here. Slowing the

> connection down to simulate a slow connection to see

> how your app responds is not good way to test it.

> Write your app so that it functions as you want it to

> in your current env, then if you wish to test it over

> a slow connection, find a slow connection to test it

> with. Otherwise

> you're just shooting in the dark as to the production

> behaviour of the app.

>

> Why slow the server down ? sounds like the sort of

> hack that has to be weeded out at a later date.

I personally didn't care or want to slow the server down, someone else did. I figured there might be a way to simulate through a config setting for the server / servlet to simulate a data transfer speed of 28.8, 128K, 7M.... I figured that since it's async that maybe it would be better to have a GUI component to show the actual server response status. A user entering info on an AJAX page could then see if the server is responding or if a request was sent to it. I could see how someone entering info into a "live" page could be confused if the page didn't update within a second or two.

I think that I'll set up a JS to listen to the input field and do stuff if it's in focus or 'in and out' of focus. That way the DB won't be hit with fragmented search strings.

ls6va at 2007-7-16 13:51:22 >

> it sort of sounds to me like you're used to thick

> client gui programming - not sure why - but trying to

> control the number of hits to a database in a web

> app

> by messing with javascript controls smells a bit (it

> may be because of the nature of AJAX which I admit I

> haven't used). Embedding in depth knowledge of the

> back end in the front end is always a bit odd.

>

> Would it not be better to implement this sort of

> control (as in programmatic logic) server side ? Is

> there a need for an AJAX request to hit a database

> each time ? Might create an awful load (maybe this is

> what you're addressing). Perhaps some cached server

> side data structure might be of better use than

> trying to hack the front end in this fashion.

Basically I'm going to use AJAX for the its look and feel, even if it isn't necessary. The load was what the other person brought up so I thought I could test it by slowing things down because I can't simulate 1,000 simultaneous connections. I'm not really worried about it because I figured that AJAX might actually help an over loaded server. If the server is too busy to respond I would catch that in my JS and and try to request it again after a few seconds. req.open("GET", url2, true);

req.onreadystatechange = callback;

req.send(null);

function callback()

{

if (req.readyState == 4)

{

if (req.status == 200)

else if(){...}

}

So if it comes back busy it'll wait before requesting the server again. I'll use DOM to manipulate the original login.html page so the input field will call a different JS function if it fails the first time. There's a bit more but that's what I'm going to try to do and hopefully bypassing this slow down testing won't matter.

ls6va at 2007-7-16 13:51:22 >