dev@glassfish.java.net

Fw: 30second timeout

From: emiddio-verizon <emiddio_at_verizon.net>
Date: Wed, 03 Mar 2010 16:22:34 -0800

i got no response from the user_at_glassfish.dev.java.net list;

the question remains.

i still seem to get the 30 second and/or 3MByte limit after adding
-Dcom.sun.grizzly.readTimeout=86400-Dcom.sun.grizzly.readTimeout=86400which i learned about from http://java.dzone.com/articles/putting-glassfish-v3when connecting to gfv3 at localhost:8080 i can dnload a 80MByte file without problems -- even before these-D additions. the failures occur when connecting to my gfv3 at home from some other location -- on theinternet side of my home.they occur when i use a web proxy to test my server or when i visitied a friend and conneted from his home computer.i found that when using firefox -- to dnload an 80 MByte video file -- if i used firefox's dnload manager to pausethe dnload about every 2MByte, then un-pause i could dnload the entire file.but if i just attempt a non-pause dnload -- it fails after 30seconds -- says its completed -- with only about 3MB of thefile dnloaded.whats going on? how do i fix ? please read info from prev post below.thanksgary----- Original Message -----
From: emiddio-verizon
To: users_at_glassfish.dev.java.net
Sent: Tuesday, March 02, 2010 2:44 PM
Subject: 30second timeout


i was/am using gfv3 to host a little web site for some personal stuff.

i put some video's there --
and discovered if someone tries to download more than 3MByte of video -- which takes more than 30 seconds,
(my upload is limited to 768Kbit) the upload to the client terminates.

googling i found some discussion of "timeouts" with glassfish-- but questions remain .

where should i put the -D <specific options> at -- in the gfv3 console jvm config area ?
i am thinking this stuff would go into domain.xml ?

i believe some of these timeouts are for the purpose of avoiding some kind of "attack".

would it not be smarter if gfv3 could not just look at the age of the request -- but also at the traffic that is moving
on the link -- an idle link is one thing.

but a link moving data at 500=Kbits /second doesnt seem like an "attack".

thanks

gary