i will take your word for it for the moment;
i have not been able to go to another site to test my gvf3 dnload/upload after changing the timeout parameters;
i cannot connect to my server from home -- from the internet side of the dsl modem unless i use a web-proxy -- which
could have its own timeout issues.
maybe i can put together something to let me talk to my server but deliberately slow the connection down.
BUT -- what about the more general question of WHY it works this way ???
why timeout connections that are moving data ? is there not a way to know the connection is in use
moving data and not just "idle".???
thanks
gary
----- Original Message -----
From: Oleksiy Stashok
To: users_at_grizzly.dev.java.net
Cc: users_at_glassfish.dev.java.net
Sent: Thursday, March 04, 2010 2:38 AM
Subject: Re: 30second timeout
Hi,
My guess is that the problem is in web proxy configuration.
I have just run simple sleep servlet (attached) and it works fine for 120+ seconds timeout (
http://localhost:8080/test/KeepAliveServlet?sleepTime=120).
If you can - please check this servlet w/ and w/o webproxy in place.
Thanks.
WBR,
Alexey.
------------------------------------------------------------------------------
On Mar 4, 2010, at 1:52 , emiddio-verizon wrote:
post is cut n paste from glassfish list posting for help -- was recommended i post to this list.
----
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=86400 which i learned about from
http://java.dzone.com/articles/putting-glassfish-v3 when 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. thanks gary ----- 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
------------------------------------------------------------------------------
Hi,
My guess is that the problem is in web proxy configuration.
I have just run simple sleep servlet (attached) and it works fine for
120+ seconds timeout (
http://localhost:8080/test/KeepAliveServlet?sleepTime=120
).
If you can - please check this servlet w/ and w/o webproxy in place.
Thanks.
WBR,
Alexey.
On Mar 4, 2010, at 1:52 , emiddio-verizon wrote:
> post is cut n paste from glassfish list posting for help -- was
> recommended i post to this list.
>
> ----
> 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=86400
>
> which i learned about from http://java.dzone.com/articles/putting-glassfish-v3
>
> when 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 the
> internet 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 pause
> the 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 the
> file dnloaded.
>
> whats going on? how do i fix ? please read info from prev post below.
>
> thanks
>
> gary
>
>
> ----- 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
>