Hi Gili,
I took a look at the issue.
"Expected behavior: destroy() methods should inform all other threads
that no further requests will be accepted, wait for pending requests to
complete, and terminate the handlers once that's done."
Not sure it is really expected. For sure it sounds good, but there might
be long-lasting requests in process, which may take long time to
complete, we shouldn't wait for such a requests, right? We might want to
introduce some destroy(long timeout), so it gives some time to requests
to complete and after timeout expires - just forces destroy. This may
require API extension and finally not sure if this method will be that
useful.
I propose to not assign null to filters and servletInstance fields in
ServletHandler.destroy(), in that case NPE won't be thrown and each
Filter will be able to throw some meaningful
FilterIsAlreadyDestroyedException, which we may "fine"ly log.
What do you think?
Thanks.
WBR,
Alexey.
On 06/19/2011 08:29 AM, cowwoc wrote:
> I am very close to getting parallel unit tests working under Jersey, Guice
> and Grizzly. I suspect the only remaining problem are race-conditions in
> Grizzly's code. I'm seeing Grizzly-specific exceptions and some behavior
> that leads me to believe that Grizzly is invoking Filters and
> ServletContextListener methods out of order.
>
> Please take a look at http://java.net/jira/browse/GRIZZLY-1030 for starters
> and we'll take it from there.
>
> Thanks,
> Gili
>
> --
> View this message in context: http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4502842.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.