I would file a new bug report and vote for JERSEY-710 while you're at it ;)
Gili
On 09/01/2014 8:04 PM, Eric Stein wrote:
> I don't disagree. Should I take that to mean I'm stuck using Thread.sleep() and waiting for a resolution to JERSEY-710?
>
> Eric
>
> -----Original Message-----
> From: cowwoc [mailto:cowwoc_at_bbs.darktech.org]
> Sent: Thursday, January 09, 2014 5:02 PM
> To: users_at_jersey.java.net
> Subject: [Jersey] Re: Threading issue with Integration tests
>
> For what it's worth: unit tests would be *far* more robust if Jersey didn't hard-code the server port. The fact that this allows use to run unit tests in parallel is purely a bonus (but a huge one).
>
> Gili
>
> On 09/01/2014 3:34 PM, Eric Stein wrote:
>> Er, correction, Jersey 2.4, not 2.4.1.
>>
>> Eric
>>
>> -----Original Message-----
>> From: Eric Stein
>> Sent: Thursday, January 09, 2014 3:34 PM
>> To: users_at_jersey.java.net
>> Subject: Threading issue with Integration tests
>>
>> Hi,
>> I'm running a set of simple end-to-end integration tests against a jersey 2.4.1 wep application. All the tests are JUnit tests extending JerseyTest.
>>
>> Test 1
>> GET /some/uri/1
>> Test 2
>> GET /some/other/uri/1
>> GET /some/other/uri/2
>> GET /some/other/uri/3
>> Test 3
>> POST /another/uri/1/something -> server does a redirect to GET /another/uri/1
>> GET /another/uri/2
>>
>> The POST test is consistently failing - my RuntimeExceptionHandler is catching a 404. It looks like it gets thrown by my server code somewhere in the response builder:
>> final Response response = Response
>> .status(Status.SEE_OTHER)
>> .location(location.build())
>> .entity(message)
>> .cacheControl(cacheControl)
>> .build();
>>
>> The 404:
>> javax.ws.rs.NotFoundException: HTTP 404 Not Found
>> at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255) ~[jersey-server-2.4.jar:na]
>> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:318) [jersey-common-2.4.jar:na]
>> at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236) [jersey-server-2.4.jar:na]
>> at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:983) [jersey-server-2.4.jar:na]
>> at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:334) [jersey-container-grizzly2-http-2.4.jar:na]
>> at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:209) [grizzly-http-server-2.3.3.jar:2.3.3]
>> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) [grizzly-framework-2.3.3.jar:2.3.3]
>> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) [grizzly-framework-2.3.3.jar:2.3.3]
>> at java.lang.Thread.run(Thread.java:662) [na:1.6.0_31]
>>
>> The reason I think threading is involved is that if I stick a Thread.sleep(5000) at the beginning of my POST test, the code works and returns normally. If I put a Thread.sleep(4000), it continues to fail. Is this a known issue? I saw JERSEY-710, but that refers to running junit tests in parallel, and I am running them in serial.
>>
>> Thanks,
>> Eric Stein