correct.
jerome
On Apr 23, 2009, at 11:18 AM, Anissa Lam wrote:
>
> Hi Jerome,
> I want to confirm this with respect to GUI. This means i should
> get and display thread pool under config like before, and not worry
> to even ask for any thread pool under network-config/network-
> listener, is this correct ?
>
> thanks
> Anissa.
>
> Jerome Dochez wrote:
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>