Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 354468 - [Unit Test Failure] o.e.m.jee.webapp.discoverer.tests.TestNoUri.test001 stays stuck
Summary: [Unit Test Failure] o.e.m.jee.webapp.discoverer.tests.TestNoUri.test001 stays...
Status: CLOSED FIXED
Alias: None
Product: MoDisco
Classification: Modeling
Component: Technologies (show other bugs)
Version: 0.9.0   Edit
Hardware: PC Linux
: P1 normal (vote)
Target Milestone: 0.13.1 RC1   Edit
Assignee: Gregoire Dupe CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-11 05:24 EDT by Nicolas Bros CLA
Modified: 2015-06-05 07:27 EDT (History)
3 users (show)

See Also:
gdupe: kepler+
gdupe: luna+


Attachments
context stacktrace (4.99 KB, text/plain)
2011-08-19 08:56 EDT, Nicolas Bros CLA
gdupe: iplog-
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Bros CLA 2011-08-11 05:24:09 EDT
The test org.eclipse.modisco.jee.webapp.discoverer.tests.TestNoUri.test001 stays stuck and prevents the build to progress further.

I'll disable it so that the builds can finish.
Comment 1 Nicolas Bros CLA 2011-08-11 05:35:43 EDT
Timewise, I think this started happening after the Eclipse file server was replaced.

On my PC, the test took 33 seconds. On Hudson, I stopped the build after the test had been running for more than 20 minutes.

I suspect a network issue preventing some URLs from being contacted.
These URLs are accessed[1] when running this test:
http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/
http://www.w3.org/TR/html4/loose.dtd


[1] determined using Fiddler
Comment 2 Nicolas Bros CLA 2011-08-19 05:00:29 EDT
Note that these URLs should not be repeatedly accessed through the network according to the W3C, and they block IPs that do this:
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/

This is probably what happened with build.eclipse.org.
I tried on build.eclipse.org:
wget http://www.w3.org/TR/html4/loose.dtd

The result shows that www.w3.org never returns the resource, and wget keeps retrying:

--2011-08-19 04:54:25--  http://www.w3.org/TR/html4/loose.dtd
Resolving www.w3.org... 128.30.52.37
Connecting to www.w3.org|128.30.52.37|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2011-08-19 04:54:56--  (try: 2)  http://www.w3.org/TR/html4/loose.dtd
Connecting to www.w3.org|128.30.52.37|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2011-08-19 04:55:28--  (try: 3)  http://www.w3.org/TR/html4/loose.dtd
Connecting to www.w3.org|128.30.52.37|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

...
Comment 3 Nicolas Bros CLA 2011-08-19 06:23:59 EDT
I think the problem is that "http://java.sun.com/xml/ns/j2ee" is interpreted as an EPackage URI and EMF tries to load it, thereby accessing the network. So, this does not happen as part of the DTD validation or loading an external DTD by the parser (which are both disabled in NoExternalLoadXmlResourceImpl).
Comment 4 Nicolas Bros CLA 2011-08-19 08:56:43 EDT
Created attachment 201791 [details]
context stacktrace

See the attached stacktrace: this is where the URI "http://java.sun.com/xml/ns/j2ee" is resolved into an EPackage.
Comment 5 Fabien Giquel CLA 2011-09-12 14:06:54 EDT
It seems that call to 'createInputStream("http://java.sun.com/xml/ns/j2ee"
, null);' (in XMLHandlerImpl.getPackageForURI) cannot be avoided for TestNoURI.xml kind of file (without xsi:schema...), even in completing MoDisco URI Handler.
Comment 6 Eclipse Genie CLA 2015-06-04 04:10:16 EDT
New Gerrit change created: https://git.eclipse.org/r/49424
Comment 7 Gregoire Dupe CLA 2015-06-04 04:12:23 EDT
TestNoUri.test001 looks to work fine I've re-enable it.
Comment 9 Gregoire Dupe CLA 2015-06-05 07:27:48 EDT
Closing.