Hi Alexey,
I hope following code can explain my idea.
--- D:/grizzly/code/modules/grizzly/src/main/java/com/sun/grizzly/Controller.java (original)
+++ D:/grizzly/code/modules/grizzly/src/main/java/com/sun/grizzly/Controller.java
@@ -256,6 +256,11 @@
*/
private boolean useLeaderFollowerStrategy = true;
+ /**
+ * Indicate max/read thread number is configured automatically.
+ */
+ private boolean autoConfigure = true;
+
// -------------------------------------------------------------------- //
/**
* Controller constructor
@@ -286,11 +291,12 @@
* SelectorHandler(s) or ConnectorHandlerPool.
*/
private void initializeDefaults() {
- autoConfigureCore();
+ if (autoConfigure)
+ autoConfigureCore();
if (threadPool == null) {
threadPool = new DefaultThreadPool();
}
- if (threadPool instanceof ThreadPoolExecutor){
+ if (threadPool instanceof ThreadPoolExecutor && autoConfigure){
((ThreadPoolExecutor)threadPool).setMaximumPoolSize(maxThreads);
((ThreadPoolExecutor)threadPool).setCorePoolSize(maxThreads);
}
@@ -1166,4 +1172,24 @@
public void useLeaderFollowerStrategy(boolean useLeaderFollowerStrategy) {
this.useLeaderFollowerStrategy = useLeaderFollowerStrategy;
}
+
+ /**
+ * Max/read thread number is configured automatically?
+ *
+ * @return <tt>true</tt>, if max/read thread number is configured automatically, or
+ * <tt>false</tt> otherwise.
+ */
+ public boolean isAutoConfigure(){
+ return autoConfigure;
+ }
+
+ /**
+ * Is max/read thread number configured automatically?
+ *
+ * @return <tt>true</tt> if configured automatically, or
+ * <tt>false</tt> otherwise.
+ */
+ public void setAutoConfigure(boolean autoConfigure){
+ this.autoConfigure = autoConfigure;
+ }
}
> Hi Minoru,
>
> >>>
> >>> So maximum pool size and core pool size parameters of
> >>> DefaultThreadPool
> >>> conctructor are actually ignored. These parameters should be removed
> >>> from the constructor. What do you think?
> >> Grizzly automatically configures thread pool, only when you create
> >> new
> >> Controller. But after that, everyone is free to change pool settings,
> >> or even provide custom thread pool, which will not be reconfigured by
> >> Grizzly.
> >> So, IMHO, DefaultThreadPool constructor with parameters may be still
> >> useful.
> >
> >
> > You are right. DefaultThreadPool constructor with parameters are
> > useful.
> >
> > DefaultThreadPool constructor with parameters in creating a new
> > Controller is confusing to programmers (and in some cases, it may be
> > error prone).
> Sorry, can you pls. provide more details here, line of code?
>
> Thank you!
>
> WBR,
> Alexey.