> Salut,
>
> Oleksiy Stashok wrote:
>> Hi Sebastien,
>>> I want to discuss about how we could add JMX into grizzly
>>> framework. JF give a good sample how to enable JMX into
>>> Grizzlywebserver but there nothing into the framework itself. I
>>> need to be able to monitor my gateway build on grizzly. I could
>>> use spring jmx, mx4j or others frameworks, but I don't want to
>>> hack the source of grizzly to be able to monitor.
>> Cool! :)
>> Ken Cavanaugh is currently working on implementation of JMX
>> framework (based on annotations), which will be also used by
>> Glassfish. IMHO it could be good idea, if you can reuse as much as
>> possible work Ken has done. This way Grizzly JMX, ideally, could be
>> reused by GF as it is, or with a minimum changes.
>
> -0 We should not tie yourself to a single JMX framework and try to
> craft an API that can be used by any JMX tool/framework. I'm not
> saying we cannot use Ken's framework (on the contrary), but the way
> we expose the information needs to be genrics enought so we can add
> Wrapper based on the JMX framework used. The GrizzlyWebServer has a
> simple enough API that it can be used with any JMX framework.
Well, I'm not sure how general is the JMX framework Ken is working on,
but if it general and easy to use - why not reuse it.
For sure it could do something extra specifically for GF, but in that
case we can take just a core part from it.
Ken, do you think it will be possible for Grizzly to reuse just core
part of the JMX framework and not be dependent on any GF specific APIs?
>>> Here some features that I found interesting
>>>
>>> - monitor the parsers
>>> - monitor the filters
>>> - be able to add or disabled parsers and filters within the
>>> protocolchain
>>> - a way to change the logging level (I have a way for log4, but I
>>> don't know if java.util.logging support that on runtime)
>>> - we have grizzlywebserver, maybe we can add a web console to
>>> manage all the beans
>>> - be able to change port at runtime
>>> - close / reconnect the listeners
>> It could be good to have statistics
>> - number of live connections
>> - total number of sent/received bytes
>> - number of sent/received bytes by channel
>> Control of:
>> - number of worker-threads
>> - number of selector threads
>> - size of temporary selector pool
>
> +1 That's why we need to fix:
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=279
It is fixed in 2.0 ;)
WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>
>
>> Thank you.
>> WBR,
>> Alexey.
>>>
>>>
>>> - be able to offer custom monitoring : like a cache.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>