ok, I finally scraped up some time and tracked down the broken asset bug.
The basic problem is that Tapestry is closing the http socket after
servicing every single request, regardless of the keep-alive header and
regardless of whether or not the client is pipelining http requests. So for
pages which are highly susceptible to pipelining, e.g. a page that contains
many inline images, the client pipelines requests, but the server disregards
all but the first. Sometimes, given the vagaries of timing, the requests for
one resource on a page may be pipelined and ignored (if it's not first in
the pipeline) several times, at which point the client gives up. So some
assets never make it and, maybe worse, certain http dialogs are vastly
lessly efficient than they should be.
Here's a little test problem that, with a high degree of probability,
reproduces the problem:
------Home.html---------
<span jwcid="imageIterator">
<span jwcid="anImage"/>
</span>
------Home.jwc---------
<specification class="com.pixory.iconorama.Home">
<component id="imageIterator" type="Foreach">
<binding name="source" property-path="imageList"/>
</component>
<component id="anImage" type="Image">
<binding name="image" property-path="components.imageIterator.value"/>
</component>
</specification>
------Home.java---------
public class Home extends BasePage
{
private static final int IMAGE_COUNT = 25;
private List _imageList;
public List getImageList()
{
if( _imageList == null)
{
_imageList = new ArrayList();
String aPackagePath = "/com/pixory/iconorama/";
for(int i=0;i<IMAGE_COUNT;i++)
{
String anImageName = "image" + i + ".jpg";
String aResourcePath = aPackagePath +
anImageName;
_imageList.add( new PrivateAsset( aResourcePath) );
}
}
return _imageList;
}
}
...just dump 25 images in the directory that you run this application from,
named image[0-25].jpg, and you should be able to see the problem.
The line in Tapestry that is closing the socket is at
ResponseOutputStream.forceClose().
// And close it.
out.close();
Closing the output stream closes the underlying socket, which is not being a
good citizen in the http 1.1 world. To a first approximation, I could fix
the problem this way:
//out.close();
out.flush();
Indeed, now there are no more broken assets, and pages that can be pipelined
now load much faster. The kicker is "to a first approximation". My hack has
created some side effects in tapestry that I don't yet understand. I'll try
to track those down next.
Joseph Panico
[EMAIL PROTECTED]
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
