On Apr 23, 2009, at 11:39 AM, Justin Lee wrote:
> 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.
>
right I just saw that method findThreadPool().
I think your idea seems worth trying, get the habitat and do a
getAllByType and then iterate until your find the right name...
> Is this a milestone 2 issue? or should it wait until the build is
> blessed?
you can wait until the build is blessed but considering the AdminGui
will not be capable of handling threadpools under network-config, we
should fix it for J1
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>