search

ari-ban / issue-test

0 stars 0 forks source link

gfv3 upload timeouts at 30seconds #804

Closed arinban closed 14 years ago

arinban commented 14 years ago

first observed with client dnload/gfv3 upload of file over dsl modem – when took more than 30 seconds got a file that was short of proper file length.

developed small java pgm to HttpURLConnection/GET a file locally from gfv3 – where i can Thread.sleep the dnload/upload in the GET java pgm.

worked with a 5MByte file – usually with a Thread.sleep(100) – will only get about 794363 byte of 5247825 byte length file.

occasionally succeeds — rarely.

gfv3 close seems to be called because of expire in grizzly-1-9-18k\trunk\code\modules\http\src\main\java\ com\sun\grizzly\http\SelectorThreadKeyHandler.java

the timeout there is 30000 – 30 seconds

gfv3 build 74.2, manifest of grizzly jars in modules says version 1.9.18k

Environment

Operating System: All Platform: All

Affected Versions

[1.9.18]

arinban commented 6 years ago
arinban commented 14 years ago

@glassfishrobot Commented Reported by emiddio@java.net

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: sample program used for testing locally,

/*

import java.io.BufferedInputStream; import java.io.BufferedReader; import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import java.io.OutputStreamWriter; import java.io.Reader; import java.lang.reflect.Proxy; import java.net.HttpURLConnection; import java.net.InetSocketAddress; import java.net.MalformedURLException; import java.net.SocketAddress; import java.net.URL;

/*

static byte[] ba = new byte[1024]; private static boolean POST = false;

/**

Object o = huc.getContent(); System.out.println("Content.toString:" + o.toString()); if (false)

{ InputStreamReader isr = new InputStreamReader(is); Reader reader = new InputStreamReader(is); BufferedReader br = new BufferedReader(isr); }

BufferedInputStream bis = new BufferedInputStream(is); File f = new File("wgfaSftCapture3.wmv"); FileOutputStream fos = new FileOutputStream(f);

int c; int rc = 0; int cnt = 0; if (false) { while ((c = bis.read()) != -1)

{ cnt++; fos.write(c); //System.out.print((char) c); }

} System.out.println(new java.util.Date().toString()); try { while ((c = bis.read(ba)) != -1)

{ rc++; cnt += c; fos.write(ba); Thread.sleep(100); }

} catch (Exception e)

{ System.out.println(e.toString()); }

System.out.println(new java.util.Date().toString());

bis.close(); fos.close(); System.out.format("rc:%d, cnt:%d\n", rc, cnt); } }

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: used same test program with gfv211 – there are no problems with gfv211;

there are with gfv3.

arinban commented 14 years ago

@glassfishrobot Commented oleksiys@java.net said: I've just tested your client code on out-of-the-box GFv3 and it works fine... I tried sleep(100) and sleep(1000) and didn't see any timeout for 20+ mins. Are you using default GFv3 configuration?

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: using default gfv3; have not tested with a different gfv3 installation; tested with gfv2.1.1 worked fine;

also – initially discovered by using over internet to dnload file from my gfv3 server – always was getting short files; before testing with this program discovered if use firefox – dnload manager and pause the dnload every say 25seconds – before the 30second timeout – i was able to dnload the 80MByte file i wasnted to dnload/upload; otherwise with 768KBit upload only got about 2.5--3MByte of file; – and error occurred at 30seconds.

i trapped later the close from a timeout in the grizzly – at gfv3 close seems to be called because of expire in grizzly-1-9-18k\trunk\code\modules\http\src\main\java\ com\sun\grizzly\http\SelectorThreadKeyHandler.java

deggging showed the timeout having expired at 30seconds;

the upload/dnload and test program work find on same win 7 64bit – 64bit jdk 1.6.0_17 with gfv2.1.1 – no issues;

i experimented with some changes – to many to mention – but sometimes was able to get to work - however – even after i thougt i have fixed with some -D jvm options – if i ran the program with multiple instances do dnload/uploads at time time – it would always fail.

very reproduce able except for some reason it works for you –

gfv3 build 74.2 grizlly 1.x.18k

gary

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: try running multiple instances at same time – force the dnload/uploads to take more than 30seconds.

gary

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: tested again on a new win 7 pc – it worked – fresh install of gfv3 74.2;

after return to home tested and it also worked – was prepared to re-install gfv3 – but it worked – that was yesterday after returning from a 2wk trip.

today does not work – issue seems to be if gfv3 is started in debug mode;

i usually run in debug mode; yest tested in non-debug mode – worked; today tested in debug mode – failed; then restarted in non-debug mode – works without issues.

issue appears related to debug / non-debug mode

please re-test with provided program.

gary

arinban commented 14 years ago

@glassfishrobot Commented cheeser@java.net said: We've recently fixed a bug with timeout settings. Are you able to build the grizzly tree at all? if so, take the jar in modules/config and drop it in place of the grizzly-config.jar in glassfish/modules and restart. Run your test with that and see if things still break. I'll try in the morning and see if I can reproduce this with the latest trunk code.

arinban commented 14 years ago

@glassfishrobot Commented oleksiys@java.net said: Hi Gary,

I suspect it's not related to debug , it looks like some racing issue.

i trapped later the close from a timeout in the grizzly – at gfv3 close seems to be called because of expire in grizzly-1-9-18k\trunk\code\modules\http\src\main\java\ com\sun\grizzly\http\SelectorThreadKeyHandler.java"

Strange, normally it shouldn't happen with the connection, which is being processed. Do you see any exception in the GFv3 log after connection gets prematurely closed?

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: typical output from my test pgm when fails when in debug mode – netbeans output – there is NO output in the gfv3 log.

init: Deleting: G:\Sun\JavaProjects\nb67\httpFileGet1\build\built-jar.properties deps-jar: Updating property file: G:\Sun\JavaProjects\nb67\httpFileGet1\build\built- jar.properties compile: run: DoInput default:true DoOutput default:false ContentEncoding:null ContentType:video/x-ms-wmv ContentLength:5247825 ConnectTimeout:0 ReadTimeout:0 Content.toString:sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@2fe 4cbc4 Mon Mar 29 12:50:45 PDT 2010 Mon Mar 29 12:51:19 PDT 2010 rc:3336, cnt:3415803 BUILD SUCCESSFUL (total time: 33 seconds)

typical output when running NON-Debug mode – successful

init: Deleting: G:\Sun\JavaProjects\nb67\httpFileGet1\build\built-jar.properties deps-jar: Updating property file: G:\Sun\JavaProjects\nb67\httpFileGet1\build\built- jar.properties compile: run: DoInput default:true DoOutput default:false ContentEncoding:null ContentType:text/plain;charset=iso-8859-1 ContentLength:5247825 ConnectTimeout:0 ReadTimeout:0 Content.toString:sun.net.www.content.text.PlainTextInputStream@40133796 Mon Mar 29 12:55:40 PDT 2010 Mon Mar 29 12:56:31 PDT 2010 rc:5125, cnt:5247825 BUILD SUCCESSFUL (total time: 51 seconds)

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: there are much newer builds of grizzly than 1.9.18k –

which version do you want me to build grizzly-config.jar from ?

gary

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: do i need to build grizzly-config.jar – can i simply download the jar – such as grizzly-config-1.9.19-SNAPSHOT.jar

thanks

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: i updated my grizzly 1.8.18-k checkout and built everything.

assumed i could simply keep a copy of the gfv3 modules directory so made a copy of it, and then replaced some grizzly jars with the new jars i had built;

initially kept the new filenames, deleting the old jars; initially tried replacing all jars starting with grizzly where i had new ones.

gfv3 startup failed with errors similar to the following: Error while starting bundle: file:/G:/Sun/sges- v3/glassfish/modules/autostart/osgi-web-container.jar: org.osgi.framework.BundleException: Unresolved constraint in bundle com.sun.grizzly.utils [230]: package; (package=com.sun.grizzly.lzma.compression.lzma) org.osgi.framework.BundleException: Unresolved constraint in bundle com.sun.grizzly.utils [230]: package; (package=com.sun.grizzly.lzma.compression.lzma) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.ja va:1027) at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.ja va:1013) at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(Directory Watcher.java:1006) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher. java:396)

so then tried to recover by restoring the modules directory to the original contents – the copy i had made;

no way to start gfv3 now without getting errors like above;

do not understand why cannot simply restore the modules directory – and recover gfv3's ability to run correctly ????

will now have to re-install gfv3 and try some experiments again;

perhaps keeping a full copy of gfv3 will enable a quicker recovery ???

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: i updated my grizzly 1.9.18-k checkout and built everything.

i updated my grizzly 1.8.18-k checkout and built everything – was a typo.

arinban commented 14 years ago

@glassfishrobot Commented emiddio@java.net said: Created an attachment (id=122) discussion – copied from a post

arinban commented 14 years ago

@glassfishrobot Commented cheeser@java.net said: the LongDownloadTest in modules/http shows that this is not a bug but a configuration issues. A new test in the glassfish devtests confirm that, with the correct configuration, long download times are allowable. The default transaction timeout (http.timeout-seconds) is 30 seconds which is why your download dies after that time.

arinban commented 14 years ago

@glassfishrobot Commented File: gfv3Info2.txt Attached By: emiddio@java.net

arinban commented 14 years ago

@glassfishrobot Commented Was assigned to cheeser@java.net

arinban commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA GRIZZLY-804

arinban commented 14 years ago

@glassfishrobot Commented Marked as incomplete on Wednesday, April 14th 2010, 6:05:43 am