3

I have a software design question on what's the best way to handle a client javascript program that relies in multiple (but mostly consecutive, not simultaneous), short-lived AJAX calls to the server as a response to user interaction [in my particular case, it will be a facebook-GAE/J app, but I believe the question is relevant to any client(browser)/server design].

First, I asked this question: What is the life span of an ajax call? . Based on BalusC answer (I encourage it to read it there), the short answer is "that's up to the browser". So, right now I do not have really control of what's happening after the server sent the response.

  • If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?

  • Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?

  • Is it possible to manually set the limit per domain?

  • And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.

Thank you in advance

Community
  • 1
  • 1
Aleadam
  • 40,203
  • 9
  • 86
  • 108
  • I'm not really an UI- or JavaScript-programmer and could be wrong, but I seem to recall that there was some sort of upper limit (depending on browser) for how many connections you could keep open to same host simultaneously (I think that's why something like map-applications use differently named domains to get their data with multiple connections) – esaj Apr 01 '11 at 14:57
  • 1
    @esaj: That's *concurrent* connections, and yes, there is a limit. What that limit is depends on the browser. It can be as low as 2, and for a long time it *was* that low. Recent desktop browsers tend to be more in the 6-8 range, but mobile browsers stick to low numbers. – T.J. Crowder Apr 01 '11 at 15:03
  • So the browser limit is already low (I was expecting it to be MUCH larger) – Aleadam Apr 01 '11 at 15:12
  • Yes, but again, that's a limit on *concurrent* connections, and I really, really should have said above that it's *per server*. So, no more than six connections to S3, or to your `www` server. Here's a good roundup from a couple of years back: http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/ – T.J. Crowder Apr 01 '11 at 15:15

2 Answers2

7

The usage paradigm for XHR is that you don't have to worry about what happens to the object -- the browser's engine takes care of that behind the scenes for you. So I don't see any point in attempting to "improve" things manually. Browser developers are certainly aware that 99.9999% of JS programmers do not do that, so they have not only taken it into account but probably optimized for that scenario as well.

You should not worry about it unless and until you have a concrete problem in your hands.

As for limiting the number of AJAX calls per domain (either concurrent outstanding calls, or total calls made, or any other metric you might be interested in), the solution would be the venerable CS classic: add another layer of abstraction.

In this case, the extra layer of abstraction would be a function through which all AJAX calls would be routed through; you can then implement logic that tracks the progress of each call (per domain if you want it to) and rejects or postpones incoming calls based on that state. It won't be easy to get it correctly, but it's certainly doable.

However, I suggest also not worrying about this unless and until you have a concrete problem in your hands. :)

Update:

Browsers do enforce their own limits on concurrent AJAX calls; there's a very good question about that here: How many concurrent AJAX (XmlHttpRequest) requests are allowed in popular browsers?

Also, as T. J. Crowder mentions in the comments: make sure you are not keeping references to XHR objects when you are done with them, so that they can be garbage collected -- otherwise, you are creating a resource leak yourself.

Second update:

There is a good blog post about reusing XHR here -- it's actually the start of a chain of relevant posts. On the down side, it's dated and it doesn't come to any practical conclusion. But it covers the mechanics of reusing XHR well.

Community
  • 1
  • 1
Jon
  • 428,835
  • 81
  • 738
  • 806
  • +1 Just as an adjunct: Be sure you don't hang on to any references to the XHR objects by accident. That's the full extent to which it's your problem rather than the browser's. – T.J. Crowder Apr 01 '11 at 15:00
  • @Jon Interesting alternative. Could you reuse the XMLHttpRequest that way or it would not make sense? – Aleadam Apr 01 '11 at 15:13
  • @T.J. Crowder all the requests are created as local variables inside short functions, so I think I have that covered. I tried so far to avoid any global variable – Aleadam Apr 01 '11 at 15:15
  • @Aleadam: Sounds like you're in good shape, so long as you're not creating *long-lived* closures or anything (short-lived is fine; normal, in fact). – T.J. Crowder Apr 01 '11 at 15:18
  • @Aleadam: Updated again -- check out that blog post. – Jon Apr 01 '11 at 15:20
  • Thank you all for the great info. I wish I could accept both answers... @Jon lots of data in those posts. I'll be busy for a few hours :) – Aleadam Apr 01 '11 at 18:43
4

If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?

It only aborts the running request. It does not close the connection.

Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?

Not possible. It's the browser's responsibility.

Is it possible to manually set the limit per domain?

Not possible from the server side on. This is a browser specific setting. Best what you could to is to ask in some page dialog the enduser to change the setting if not done yet. But this makes after all no sense, certainly not if the enduser does totally not understand the rationale behind this.

And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.

Yes, you should certainly worry about browser specific bugs. You want your application to work without issues, do you? Why wouldn't you just use an existing ajax library like jQuery? It has already handled all nasty bugs and details under the covers for you (which is many more than only MSIE memory leaking). Just call $.ajax(), $.get(), $.post() or $.getJSON() and that's it. I wouldn't attempt to reinvent the XHR handling wheel when you're fairly new to the materials. You can find some jQuery-Servlet communication examples in this answer.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • indeed, I started using jQuery for the calls. I used plain javascript in the example because it is more a conceptual question than anything else. Also, that's why in the previous question about the life span of the call I asked if $.post() behaved the same way, thinking that there could some post-response handling of the connection. I understood from your previous response that it rather covered mostly the browser specific creation. I will go though that code, but I'm sure I'll miss lots of implementation details. – Aleadam Apr 01 '11 at 15:21