Re: ThreadPoolProbeProvider
Oleksiy Stashok wrote:
> Hi,
>
>
>> What i'm tempted to do is to abstract this method in GrizzlyService to
>> simply create a StatsThreadPool in Grizzly and then override in
>> glassfish to create the Probe stuff. It looks like all this
>> ProbeParam stuff is for glassfish monitoring (and only in a very niche
>> case at that). Then I can move several classes back to glassfish.
> I agree here. Probes were introduced my Jan just for monitoring reasons
> as wrappers above Grizzly thread pool (worker threads), so IMHO, there
> is no reason to move it under Grizzly.
+1
-- Jeanfrancois
>
> WBR,
> Alexey.
>
>>
>> Justin Lee wrote:
>>> Hrm. It does not appear that ThreadPoolProbeProvider is used outside
>>> of GrizzlyService... What exactly does @ProbeParam provide? It's
>>> part of the glassfish flashlight module... I'll see if there's any
>>> javadoc worth reading.
>>>
>>> Justin Lee wrote:
>>>>
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Salut,
>>>>>
>>>>> Justin Lee wrote:
>>>>>> The grizzly related code in glassfish has a pretty convoluted.
>>>>>> I'm doing my best to sever that as much as possible but I'm seeing
>>>>>> some places where that might not be (cleanly) possible. I'm
>>>>>> hoping to be able to move stuff over and subclass in the glassfish
>>>>>> tree in some places to provide the additional hooks that glassfish
>>>>>> uses. I'm not sure that's going to be possible everywhere,
>>>>>> though. How bad would "small" deps be on certain glassfish
>>>>>> artifacts be inside the grizzly-config module?
>>>>>
>>>>> That's fine but I hope you don't have to bring the entire GF
>>>>> dependencies tree. Since Grizzly is pretty small, having too many
>>>>> dependencies might prevent adoption of that module.
>>>> Same here. I'm hoping to get rid of all of them. I'm not sure I
>>>> can fix the Result dep but I'll explore glassfish subclassing as
>>>> outlined below.
>>>>>
>>>>>
>>>>> e.g., Result is used in a number of places and
>>>>>> those might be hard to extract. I have the dep defined right now
>>>>>> for convenience and I'm going to try to work that dep back out but
>>>>>> it might be hard sailing.
>>>>>>
>>>>>> So with all that in mind, would it be the end of the world? I
>>>>>> don't like and I'm trying to avoid that but I'm afraid of ending
>>>>>> up with horribly convoluted code otherwise.
>>>>>
>>>>> Can you elaborate about the convoluted part?
>>>>>
>>>> e.g., there's GrizzlyService. For the most part, this is all
>>>> grizzly stuff and can be moved over. However, there are some
>>>> glassfish related lifecycle methods. Now, in this case, i think i
>>>> can move over the bulk of GrizzlyService and then subclass in
>>>> Glassfish to proved those extra hooks that glassfish needs but
>>>> grizzly doesn't. In this case, I think we can cut a clear line.
>>>> I'm less hopeful in other areas, but I'm doing some clean up of
>>>> static util classes like GrizzlyListenerConfigurator that seems to
>>>> be helping.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>