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
>