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.
> 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.
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.
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
>