On 06/20/2011 03:53 PM, cowwoc wrote:
>
> I'm initializing the server with a PortRange(1, 65535):
> final NetworkListener listener = new NetworkListener("grizzly",
> host, new PortRange(1, 65535));
>
> I assume this guarantees that, although servers are presented with
> the same range, no two servers will bind to the same port.
Yes, it should work.
>
> PS: The documentation should probably indicate somewhere that port 0
> is not allowed (and the code should prevent its use). If I recall
> correctly, using port 0 causes the server to fail silently (you don't
> get back an exception).
Port 0 should work. May be it's what you might want to use. When you set
0 - it means you let OS to assign a port number.
You can try the code bellow.
WBR,
Alexey.
public static void main(String[] args) throws Exception {
HttpServer httpServer = new HttpServer();
final NetworkListener listener =
new NetworkListener(LISTENER_NAME,
NetworkListener.DEFAULT_NETWORK_HOST,
0);
httpServer.addListener(listener);
httpServer.getServerConfiguration().addHttpHandler(new
PingHttpHandler());
configureServer(httpServer);
try {
httpServer.start();
System.out.println("TCP PORT=" +
httpServer.getListener(LISTENER_NAME).getPort());
System.out.println("Press enter to exit...");
System.in.read();
} catch (IOException e) {
e.printStackTrace();
} finally {
httpServer.stop();
}
}
>
> Gili
>
> On 20/06/2011 9:46 AM, oleksiys [via Grizzly] wrote:
>> Hi,
>>
>> how are you initializing the server? Is it possible they reuse the
>> same TCP port?
>>
>> WBR,
>> Alexey.
>>
>> On 06/20/2011 03:21 PM, cowwoc wrote:
>>> Hi Oleksiys,
>>>
>>> I guess first of all I'm wondering why the Filter is in
>>> mid-execution when destroy() is being invoked. It shouldn't be in my
>>> case. I'm running a single client connection per unit test and shut
>>> down when it returns. Is it possible to improve logging to help
>>> figure out what is going on?
>>>
>>> Once I understand exactly what is going on I'd be in a better
>>> position to decide on how destroy() should behave.
>>>
>>> Thanks,
>>> Gili
>>>
>>> On 20/06/2011 4:42 AM, oleksiys [via Grizzly] wrote:
>>>> 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.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> If you reply to this email, your message will be added to the
>>>> discussion below:
>>>> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4505579.html
>>>>
>>>> To unsubscribe from Parallel unit tests, click here.
>>>
>>>
>>> ------------------------------------------------------------------------
>>> View this message in context: Re: Parallel unit tests
>>> <http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506369.html>
>>> Sent from the Grizzly - Users mailing list archive
>>> <http://grizzly.1045725.n5.nabble.com/Grizzly-Users-f3726882.html>
>>> at Nabble.com.
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>> http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506426.html
>>
>> To unsubscribe from Parallel unit tests, click here.
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Parallel unit tests
> <http://grizzly.1045725.n5.nabble.com/Parallel-unit-tests-tp4502842p4506455.html>
> Sent from the Grizzly - Users mailing list archive
> <http://grizzly.1045725.n5.nabble.com/Grizzly-Users-f3726882.html> at
> Nabble.com.