So I interacted this morning with a few people and it seems we are
getting towards the consensus that we should leave the threadpool
where they used to be.
The ThreadPool.java can stay in the grizzly-config module, the thread-
pool element under network config should be used in the grizzly
standalone use case.
We should have an upgrade service that moves any threadpool definition
from network-config to the config element so that if people just copy/
paste the grizzly config from a standalone config to a glassfish
installation, we will still recognize those entries and upgrade them
accordingly.
GlassFish runtime should only use threadpool under config like in
previous releases.
Jerome
On Apr 22, 2009, at 9:28 PM, Jerome Dochez wrote:
> Kedar Mhaswade wrote:
>>
>>
>> Jerome Dochez wrote:
>>>
>>> On Apr 22, 2009, at 3:52 PM, Kedar Mhaswade wrote:
>>>
>>>>
>>>>
>>>> Jerome Dochez wrote:
>>>>> I understand that part. I am confused why it can't be in both
>>>>> places (under network-config for grizzly) and under config for
>>>>> the rest)
>>>>
>>>> Won't we then need additional qualification for create/delete/list
>>>> thread-pool commands so they can disambiguate between the thread-
>>>> pool
>>>> under <config> against <network-config>?
>>> by that, you mean different admin commands ? yes they would need
>>> that although I suppose a parameter on the existing admin command
>>> could suffice to disambiguate.
>>
>> Right. We would need that, although it might be rather clumsy and
>> would
>> relate the "structure" of domain.xml which we want to avoid from
>> getting
>> exposed to asadmin. Would you say something like:
>>
>> asadmin create-thread-pool --traffic [iiop/http/tcp ...] my-uber-
>> thread-pool?
> something like that if we feel it is becoming necessary
>>
>>
>>
>>>> Or are you saying that their
>>>> ID's must be unique across elements?
>>> depends what the referencing elements expect. I suppose we could
>>> enforce that uniqueness across elements.
>>
>> Not sure.
>> <config>
>> <thread-pools>
>> <thread-pool id="id1" .../>
>> </thread-pools>
>> ...
>> <network-config>
>> <thread-pool id="id2" .../>
>> </network-config>
>> </config>
>>
>> It would be rather awkward to say that /config/thread-pools/thread-
>> pool[i]@id
>> and /config/network-config/thread-pool[i]@id need to be unique.
> yeah but then the referencing would need to be change to indicated
> which threadpool type is being referenced.
>
> another possibility is that thread-pool under network config would
> only be used in glassfish standalone while we would only use thread-
> pool under config.
>>
>>>
>>> at the end, I find it a bit strange that in the normal appserver
>>> case, we would define our threadpools under network config. I
>>> understand this is needed for standalone grizzly but should that
>>> have ripple effects in glassfish is undesirable imo.
>>
>> I agree. But isn't the plan that all listeners and thread-pools
>> move under
>> network-config? That's the reason I thought we should move iiop-
>> listener
>> too under network-config. Since the http-listeners have already
>> moved under
>> <network-config> maybe iiop-listeners should move too.
> I am not sure that was a decision, certainly I would like to get
> Siva's opinion on that matter. I suppose that for the time being, we
> can leave it under network-config and revisit it with the right
> quorum.
>>
>>>
>>> jerome
>>>
>>>>
>>>> -Kedar
>>>>
>>>>> On Apr 22, 2009, at 3:33 PM, Justin Lee wrote:
>>>>>> We just filed this https://grizzly.dev.java.net/issues/show_bug.cgi?id=557
>>>>>> to make a little more semantic sense. ThreadPool elements
>>>>>> have to live somewhere under NetworkConfig at a minimum for
>>>>>> grizzly-config to be usable in grizzly standalone.
>>>>>>
>>>>>> Jerome Dochez wrote:
>>>>>>> I am a bit confused as well. I understand the ThreadPool
>>>>>>> configured interface went into the grizzly-config module,
>>>>>>> however I don't understand why there would be a reference from
>>>>>>> iiop-listeners to threadpools defined in network-listeners.
>>>>>>>
>>>>>>> jerome
>>>>>>>
>>>>>>> On Apr 22, 2009, at 1:37 PM, Justin Lee wrote:
>>>>>>>
>>>>>>>> No other questions/complaints? Can I commit this?
>>>>>>>>
>>>>>>>> Justin Lee wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kedar Mhaswade wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK. Thanks.
>>>>>>>>>> So the plan is iiop-listeners stay wherever they are, but
>>>>>>>>>> will reference
>>>>>>>>>> thread-pools from under network-listeners?
>>>>>>>>> Correct.
>>>>>>>>>>
>>>>>>>>>> Does it make more sense then to make ORB initialize from
>>>>>>>>>> convenient network-listeners and deprecate the iiop-
>>>>>>>>>> listener(s) element(s)?
>>>>>>>>> I could go either way on this one. As I understand it,
>>>>>>>>> though, the ORB code needs a much different thread pool
>>>>>>>>> than, say, HTTP processing.
>>>>>>>>>>
>>>>>>>>>> I guess we will need a blanket compatibility waiver for
>>>>>>>>>> affected dotted names.
>>>>>>>>> There's a request for this in already, actually.
>>>>>>>>>>
>>>>>>>>>> -Kedar
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Kedar
>>>>>>>>>>>>
>>>>>>>>>>>> Justin Lee wrote:
>>>>>>>>>>>>> Attached are the diffs for integrating the new version
>>>>>>>>>>>>> of grizzly-config that should hopefully fix the open
>>>>>>>>>>>>> issues against it. There is also a fix for a test that
>>>>>>>>>>>>> broke from the grizzly-config merge last week.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-
>>>>>>>>>> unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>