I think I might already have a duck typed method for fetching those from
a NetworkListener. That should help from the outside, but tracking down
where those live might still be tricky.
Is this a milestone 2 issue? or should it wait until the build is blessed?
Jerome Dochez wrote:
> a few duck typed methods might help you there, grizzly should only go
> through the duck typed methods to retrieve the threadpool information.
> The duckType method would do the necessary lookups...
>
> On Apr 23, 2009, at 11:18 AM, Justin Lee wrote:
>
>> Given that the same code would be used at runtime in glassfish as is
>> used in grizzly to process those ThreadPool objects, that could get
>> messy. I'll see what I can do with things like @Inject or
>> getByContractType to help hide the structural differences. A little
>> disappointing to have to support disparate schemas like that. I'll
>> see what I can do, though. Is this required for the milestone 2 build?
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>