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
>