Hi Steve,
Please see inline...
> Steve Curtis <mailto:stevo.curtis_at_googlemail.com>
> November 10, 2015 at 09:53
>
> Hi, I’m working on a project that is currently using SimpleFramework
> java web server. I suspect we are running out of worker threads but
> unfortunately the api does not give me a mechanism to get a hold of
> the thread executors.
>
>
> With this in mind I am looking at using Grizzly as an alternative,
> since on the face on it I should be able to get this information.
>
>
> I’m creating the server as follows:
>
>
> private HttpServer server;
>
> private NetworkListener listener;
>
> public static final String localhost = "localhost";
>
> public void runServer(int port) throws IOException
>
> {
>
> logger.info <http://logger.info>("starting grizzly framework server on
> port {}", port);
>
> server = new HttpServer();
>
> listener = new NetworkListener("grizzly", localhost, port);
>
> listener.setSecure(false);
>
>
> listener.getTransport().setIOStrategy(WorkerThreadIOStrategy.getInstance());
>
> server.addListener(listener);
>
> final ServerConfiguration serverConfiguration =
> server.getServerConfiguration();
>
> serverConfiguration.addHttpHandler(new HttpHandler()
>
> {
>
> public void
> service(Request request, Response response) throws Exception
>
> {
>
> final
> SimpleDateFormat format = new SimpleDateFormat("EEE, dd MMM yyyy
> HH:mm:ss zzz", Locale.UK);
>
> final String date =
> format.format(new Date(System.currentTimeMillis()));
>
>
> response.setContentType("text/plain");
>
>
> response.setContentLength(date.length());
>
>
> response.getWriter().write(date);
>
> }
>
> }
>
> );
>
> server.start();
>
> logger.info <http://logger.info>("bootstrap of grizzly framework
> server complete, running on http://{}:{}", localhost, port);
>
> }
>
> I was trying to print off details of the kernel and thread queue sizes
> but the queue object is null:
>
>
> logger.info <http://logger.info>("kernel thread pool queue {}",
> listener.getTransport().getKernelThreadPoolConfig().getQueue());
>
> logger.info <http://logger.info>("worker thread pool queue {}",
> listener.getTransport().getWorkerThreadPoolConfig().getQueue());
>
getQueue() will return null unless you explicitly set your own Queue
implementation. If it's null, when the thread pool is initialized,
Grizzly will choose its own implementation, but this won't be reflected
in the configuration object.
>
> I think the number of pending incoming requests and queued workers
> should be the size of each of these Queue objects if they not null?
>
Not necessarily. You can have a large number of queued tasks, but a
small fixed number of workers.
>
>
> Note maybe there is a better way of getting this sort of information?
>
Yes, you can look at providing a ThreadPoolProbe [1] implementation.
This will allow you to track thread
allocation/deallocation/queue/dequeue events within the pool. The probe
implementation can be registered by calling getInitialMonitoringConfig()
on the worker thread pool configuration before starting the server.
Additionally, you may want to review the thread pool documentation [2].
There are performance considerations when configuring the min/max values
of the pool size.
[1]
https://grizzly.java.net/docs/2.3/apidocs/org/glassfish/grizzly/threadpool/ThreadPoolProbe.html
[2]
https://grizzly.java.net/coreconfig.html#/Thread_Pool_Configuration
>
>
> Thanks
>