Hi,
I am not sure it is connected with JERSEY-710 if tests are run in serial.
Eric, can you please extract a simple test case and create a new bug? The best would be to have a simple maven project that reproduces this problem. It is difficult to say what is wrong for such kind of problem. We basically need more information (if you use async processing, what your resource methods looks like) and having the code with problem would really help.
Thanks
Mira
On Jan 10, 2014, at 5:19 AM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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
>