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