gfv3 upload timeouts at 30seconds

glassfishrobot 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]

glassfishrobot commented 14 years ago

Reported by emiddio@java.net

glassfishrobot commented 14 years ago

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

/*

To change this template, choose Tools | Templates
and open the template in the editor. */ package httpfileget1;

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;

/*

@author emiddio */ public class Main {

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

/**

@param args the command line arguments */ public static void main(String[] args) throws MalformedURLException, IOException { // TODO code application logic here URL u = new URL("http://localhost:8080/wgfaSftCapture3.wmv"); HttpURLConnection huc2 = (HttpURLConnection) u.openConnection(); HttpURLConnection huc = huc2; if (false) { InetSocketAddress isa = new InetSocketAddress("amd4800", 8888); SocketAddress sa = isa; java.net.Proxy p = new java.net.Proxy(java.net.Proxy.Type.HTTP, sa); huc = (HttpURLConnection) u.openConnection(p);//proxy }

System.out.println("DoInput default:" + huc.getDoInput()); System.out.println("DoOutput default:" + huc.getDoOutput()); huc.setRequestMethod("GET");//will be POST if doing output if (POST)

{ huc.setDoOutput(true); }

huc.connect(); if (POST)

{ OutputStream os = huc.getOutputStream(); OutputStreamWriter out = new OutputStreamWriter(os); out.close(); }

InputStream is = huc.getInputStream(); System.out.println("ContentEncoding:" + huc.getContentEncoding()); System.out.println("ContentType:" + huc.getContentType()); System.out.println("ContentLength:" + huc.getContentLength()); System.out.println("ConnectTimeout:" + huc.getConnectTimeout()); System.out.println("ReadTimeout:" + huc.getReadTimeout());

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); } }

glassfishrobot commented 14 years ago

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

there are with gfv3.

glassfishrobot commented 14 years ago

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?

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

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

gary

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

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.

glassfishrobot commented 14 years ago

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?

glassfishrobot commented 14 years ago

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)

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

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 ???

glassfishrobot commented 14 years ago

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.

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

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.

glassfishrobot commented 14 years ago

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

glassfishrobot commented 14 years ago

Was assigned to cheeser@java.net

glassfishrobot commented 7 years ago

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

glassfishrobot commented 14 years ago

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

javaee / grizzly