tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: RES: Configuring limits of requests/sessions/threads in Tomcat
Date Tue, 01 Apr 2014 20:15:01 GMT
André Warnier wrote:
> Danilo Amaral de Oliveira wrote:
>> Milo,
>> The video is embedded in a JWPlayer Javascript application.  The video 
>> is in the page too, but you need download it before watch it.
>> Summarizing, here the simulating process of watching the video:
>> User access the page              | Tomcat serve the page.
> Ok, so there can be 5000 users obtaining that page, and just to annoy 
> you, they all wait before they press the "play" button.
> (I would imagine that the page does not really "contain" the video when 
> they get it.  Or does the fact of simply viewing that page already 
> downloads the video ?)
>> User clicks "play" button 
> So now they all click "play" at the same time.
>       | Tomcat send the video to the user (it is the same if the user 
> download it)
> That's probably not what really happens, is it ?
> I mean, the "play" button must be sending something back to Tomcat.
>> User watches the video in the JWPlayer windows| The processing task of 
>> the video is in the local user machine - The interaction between the 
>> web application finishes after download the video.
> ...
> I searched Google for JWPlayer, and went to their homepage, which shows 
> one such video window.  I did this with Firefox, with the add-on HttpFox 
> enabled, to see what happens.
> Loading the page which contains the window showing the starting image of 
> the video, does not really download the video yet; just a lot of html, 
> stylesheets, javascript, gifs, jpegs etc.. But nothing very large 
> individually.
> When you click the "play" button however, /then/ the browser makes a 
> request for the "video/mp4" file (in this case 3.6 MB) and starts 
> downloading and playing it.
> The request to the server for the video, is just a "GET" request.
> (GET 
> /sEtaWjfL/videos/RxiqSWej-htxObmZA.mp4?5c877a8d15f183bb974dcdccb105a79495b4e5e3b1b6e4cf2779670f5893acd5fb2e2e0fa612e58d66b8691edfddfac95896931e691ea609ff9ddddf808064d5ebbefd315cdd991497cb4a0ea3fdf2a639831982a394

> HTTP/1.1)
> So is there some application on the server which responds to that GET 
> request from the page, or just the file itself ?
> As for the real solution to your problem, considering that this JWPlayer 
> is a commercial application, with probably some technical support 
> available, did you ask the supplier about this ?
Complement of information, for anyone interested :

The following is the complete sequence of requests sent by the browser (as per HttpFox), 
starting from the pressing of the "play" icon in the middle of the initial image, up to 
the end of the video.

00:00:09.681	1.663	568	3.6M	GET	200	video/mp4
00:00:10.648	0.150	830	200	GET	200	image/gif
00:00:21.681	0.158	829	200	GET	200	image/gif
00:00:37.860	0.157	829	200	GET	200	image/gif
00:00:48.764	0.169	829	200	GET	200	image/gif
00:00:59.551	0.228	830	200	GET	200	image/gif	

the above requests are sent during the play-back of the video in the page.
The following 2 requests are sent when the player reaches the end of the video.
00:00:59.625	0.044	497	(31374)	GET	(Cache)	image/jpeg
00:00:59.709	0.025	381	(5120)	GET	(Cache)	image/jpeg

During the playback above, I also pressed the "stop" (||) and "play" (>) buttons a couple

of times, and that did not result in any additional requests sent by the browser.
It looks like after the initial GET for the mp4 file, the other intermediate requests for

"gifs" are just some kind of keep-alive.  Note that they seem to be going to another 
server than the one from which the original mp4 file is obtained from.

So yes, to confirm what someone else was writing, it seems like the server is sending the

whole video at once, as a response to the original GET.
But there could still be some kind of application on the server, which returns the MP4 and

controls the rate, somehow. After all, there is a query-string after the video filename, 
in the original GET request.  It must go somewhere..

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message