Comments on: Improving JPSpan Performance with an Object Pool

By: BrianJava » AJAX FAQ for the Java Developer

BrianJava » AJAX FAQ for the Java Developer — Tue, 28 Feb 2006 07:28:51 +0000

[...] Using this closures insures that the proper callback function associated with a specific AJAX interaction is called. Caution should still be taken when creating multiple closure objects in that make XmlHttpRequests as to there is a limited number of sockets that are used to make requests at any given time. Because there are limited number of requests that can be made concurrently. Internet Explorer for example only allows for two conncurrent AJAX requests at any given time. Other browsers may allow more but it is generally between three and five requests. You may choose to use pool of AJAXInteraction objects. [...]

By: Joshua Eichorn

Joshua Eichorn — Thu, 07 Jul 2005 21:07:17 +0000

Well I have no clue what Konqueror supports I would guess it doesn’t have a full XmlHttpRequest implementation, if you know of any docs let me know and i’ll take a look.

By: LCardoso

LCardoso — Thu, 07 Jul 2005 20:58:07 +0000

I forgot to mention: “…it works fine with firefox but not with _Konqueror_.”
I tested with Konqueror 3.4 (Ubuntu 5.04).

By: Joshua Eichorn

Joshua Eichorn — Thu, 07 Jul 2005 16:52:24 +0000

I’m not seeing this error in either IE or Firefox, can you give me a step by step on what you did to get the error

By: LCardoso

LCardoso — Thu, 07 Jul 2005 16:47:28 +0000

Hi,

the helloworld demo produces an ” [Client_Error] [413] Request Entity Too Large while calling helloworld.randomstring()” but works fine with Firefox.

Do you know why?

By: Joshua Eichorn

Joshua Eichorn — Thu, 28 Apr 2005 19:56:31 +0000

Link is fixed.

I’m not sure what the solution memory wise is, im just creating more proxied objects so a pool seemed the way to go for that since the object might be quite large.

At just the XMLHTTPRequest level the overhead wouldn’t be quite so large but maybe a pool still makes sense since you’ll want the ability to limit the # of outstanding requests, both to limit server load and to keep the browser for having “weird” problems.

By: Harry Fuecks

Harry Fuecks — Thu, 28 Apr 2005 19:38:54 +0000

Oh - one other thing - the link to objectPool.js seems to be broken.

By: Harry Fuecks

Harry Fuecks — Thu, 28 Apr 2005 19:37:23 +0000

“I would like to see this fixed with an pool of XMLHttpRequest objects at the JPSpan level, however im sure this will take some time so I have a solution for you today.”

Got two minds about this. On the one hand - agree - this is something someone using JPSpan should, ideally, not have to care about and as I’m saying JPSpan is about making life easy, it should do just that.

On the other I’m not yet convinced it can be handled transparently in JPSpan without resulting in stranges bugs, and so “forcing” this onto the user means that the best decision will be made for their specific requirements. I really need to do some more testing to nail this stuff down exactly but here’s some of the issues;

- Using an XMLHttpRequest object that is already making an async request DOES result in wierdness. Exactly what kind of wierdness I can’t say exactly - had some strange experiences while working on the earlier parts of JPSpan but was able to narrow it down well enough thanks to other bugs and issues I was dealing with at that time.

- Creating more than “X” XMLHttpRequest objects and having them all make async requests at the same time _may_ also lead to wierdness. Andreas Halter (http://andreashalter.ch/) tipped me off about this. He’s done a fair deal with XUL and mentioned he’d run into a problem where when you have more than, say, 10 requests in progress at the same time, the responses start getting mixed and you might get the response from one request coming back via a seperate object. I haven’t been able to reproduce this myself but it makes me nervous.

- What are the memory / object setup costs here? Is it better to have a pool of objects ready to serve requests (as is done in libXMLRequest) reducing the perceived performance overhead once the page is loaded, at the cost of memory and extra code to manage the pool. Or is it better to simply create a new object when needed?

Anyway - going to experiment further in this direction and see how it goes.