You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/06/16 21:26:10 UTC
Server statistics (was: Personal IP blacklists)
This topic just came up, again, in james-user last week
(http://archives.apache.org/eyebrowse/ReadMsg?listId=21&msgNo=6059), and is
related to a discussion from last summer
(http://archives.apache.org/eyebrowse/BrowseList?listName=james-dev@jakarta.
apache.org&by=thread&from=225096). If you want to skip other discussion,
you could go directly to
http://archives.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apac
he.org&msgNo=4076.
Perhaps you, Chris, Steve, Jason and others would like to work on it?
--- Noel
-----Original Message-----
From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
Sent: Monday, June 16, 2003 14:57
To: James Developers List
Subject: Re: Personal IP blacklists
My dream SMTP server has a GUI reminiscent of the control room at a
power plant, with gauges which show every parameter which might be
important to the operator, and with valves to throttle or completely
shut down any segment of the operation which seems to be getting out
of hand.
Parameters such as the following would have both gauges (and/or
warning lights and whistles) and values (operator-settable limits):
total incoming messages/(unit time)
total incoming connections/(unit time)
total incoming bytes/(unit time)
total outgoing ... (the same three as above)
total volume of mail held in local mailboxes
total volume of mail held in local spools
ip addresses generating most of the traffic/(recent unit of time)
ip addresses generating most of the connections/(recent unit of time)
local addresses receiving large quantities of mail
local addresses sending large quantities of mail
Also, another approach, I would prefer to have the server return an
error upon RCPT TO: <unknownJoe>, rather than accept the message as
James does at present. I think Noel said there were plans to change
this in an upcoming James.
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Jason Webb <jw...@inovem.com>.
Cool! No worries then.
My preferred option would be to ship James with JMX turned off.
If you want it then turn it on - if to turn it on, then you asked for
it...
I shall start to think a bit more about what and how to control and
instrument James.
I would like to JMX James 3.0 rather than v2 mainly because v3 is in dev
and I may need to make some fairly serious changes to James internals.
Any comments on this?
Jason Webb
Director iNovem Ltd
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 19:34
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
> Jason,
>
> I suggest to you that the JMX MBeans are orthogonal from authenticated
> user.
> Let's get JMX into James, and let me go talk to Avalon about helping
us
> lock
> out unauthorized users. In fact, they are voting today to give James
> Committers access to the components area of their CVS module.
>
> We won't release James with JMX until we've secured it, but lets get
the
> instrumentation part of the project going. Fair enough? :-)
>
> --- Noel
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Wednesday, June 18, 2003 4:01
> To: 'James Developers List'
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> I'd still like to do this (give James real JMX usability), but I have
> one hang-up with the current Avalon implementation in that I need
Avalon
> to provide authentication which it currently doesn't do. Once this is
> done then I can start Mbean'ing up James properly for control. Without
> this I won't start any work as it would James a serious security hole.
>
> My eventual goal is to instrument James as completely as possible :)
> I have the JMX book and I am ready...
>
> -- Jason
>
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: 18 June 2003 08:05
> > To: James Developers List
> > Subject: RE: Server statistics (was: Personal IP blacklists)
> >
> >
> > JMX is very conceptually compatible with the ad hoc approach
> > Jason and I had discussed last summer. Remember what I said
> > about using a statistics object and a registry? From the JMX
> > specification: "The MBean server is a registry for MBeans [in
> > the application.]" Very similar concepts. Not that I would
> > claim uniqueness. SNMP, /proc, and other schemes are all in
> > the same pattern.
> >
> > JMX is the right way to do this for James, since it is a
> > standard, provides control, is embedded in Phoenix, is
> > growing in use, and provides a replacement for the aging
> > remote manager interface.
> >
> > > I imagine that the class doing the work would have a variable
which
> > > holds the statistic we care about.
> >
> > Classes. Plural. Lots of beans. :-)
> >
> > > This would cause SMTPHandler to refuse or defer some incoming
> > > connections.
> >
> > Minor nit, but this is wrong. You need to understand the
> > archtectural relationships between some of the components.
> > The protocol handler is used after a new connection is
> > established. Rejecting a new connection based upon busy
> > state would happen elsewhere.
> >
> > As I've said before, please feel free to contribute. If
> > you're interested in working on JMX for James, got for it. :-)
> >
> > Avalon has been using http://mx4j.sourceforge.net/.
> >
> > --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
I suggest to you that the JMX MBeans are orthogonal from authenticated user.
Let's get JMX into James, and let me go talk to Avalon about helping us lock
out unauthorized users. In fact, they are voting today to give James
Committers access to the components area of their CVS module.
We won't release James with JMX until we've secured it, but lets get the
instrumentation part of the project going. Fair enough? :-)
--- Noel
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Wednesday, June 18, 2003 4:01
To: 'James Developers List'
Subject: RE: Server statistics (was: Personal IP blacklists)
I'd still like to do this (give James real JMX usability), but I have
one hang-up with the current Avalon implementation in that I need Avalon
to provide authentication which it currently doesn't do. Once this is
done then I can start Mbean'ing up James properly for control. Without
this I won't start any work as it would James a serious security hole.
My eventual goal is to instrument James as completely as possible :)
I have the JMX book and I am ready...
-- Jason
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 08:05
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> JMX is very conceptually compatible with the ad hoc approach
> Jason and I had discussed last summer. Remember what I said
> about using a statistics object and a registry? From the JMX
> specification: "The MBean server is a registry for MBeans [in
> the application.]" Very similar concepts. Not that I would
> claim uniqueness. SNMP, /proc, and other schemes are all in
> the same pattern.
>
> JMX is the right way to do this for James, since it is a
> standard, provides control, is embedded in Phoenix, is
> growing in use, and provides a replacement for the aging
> remote manager interface.
>
> > I imagine that the class doing the work would have a variable which
> > holds the statistic we care about.
>
> Classes. Plural. Lots of beans. :-)
>
> > This would cause SMTPHandler to refuse or defer some incoming
> > connections.
>
> Minor nit, but this is wrong. You need to understand the
> archtectural relationships between some of the components.
> The protocol handler is used after a new connection is
> established. Rejecting a new connection based upon busy
> state would happen elsewhere.
>
> As I've said before, please feel free to contribute. If
> you're interested in working on JMX for James, got for it. :-)
>
> Avalon has been using http://mx4j.sourceforge.net/.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Jason Webb <jw...@inovem.com>.
I'd still like to do this (give James real JMX usability), but I have
one hang-up with the current Avalon implementation in that I need Avalon
to provide authentication which it currently doesn't do. Once this is
done then I can start Mbean'ing up James properly for control. Without
this I won't start any work as it would James a serious security hole.
My eventual goal is to instrument James as completely as possible :)
I have the JMX book and I am ready...
-- Jason
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 08:05
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> JMX is very conceptually compatible with the ad hoc approach
> Jason and I had discussed last summer. Remember what I said
> about using a statistics object and a registry? From the JMX
> specification: "The MBean server is a registry for MBeans [in
> the application.]" Very similar concepts. Not that I would
> claim uniqueness. SNMP, /proc, and other schemes are all in
> the same pattern.
>
> JMX is the right way to do this for James, since it is a
> standard, provides control, is embedded in Phoenix, is
> growing in use, and provides a replacement for the aging
> remote manager interface.
>
> > I imagine that the class doing the work would have a variable which
> > holds the statistic we care about.
>
> Classes. Plural. Lots of beans. :-)
>
> > This would cause SMTPHandler to refuse or defer some incoming
> > connections.
>
> Minor nit, but this is wrong. You need to understand the
> archtectural relationships between some of the components.
> The protocol handler is used after a new connection is
> established. Rejecting a new connection based upon busy
> state would happen elsewhere.
>
> As I've said before, please feel free to contribute. If
> you're interested in working on JMX for James, got for it. :-)
>
> Avalon has been using http://mx4j.sourceforge.net/.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
JMX is very conceptually compatible with the ad hoc approach Jason and I had
discussed last summer. Remember what I said about using a statistics object
and a registry? From the JMX specification: "The MBean server is a registry
for MBeans [in the application.]" Very similar concepts. Not that I would
claim uniqueness. SNMP, /proc, and other schemes are all in the same
pattern.
JMX is the right way to do this for James, since it is a standard, provides
control, is embedded in Phoenix, is growing in use, and provides a
replacement for the aging remote manager interface.
> I imagine that the class doing the work would have a variable which
> holds the statistic we care about.
Classes. Plural. Lots of beans. :-)
> This would cause SMTPHandler to refuse or defer some incoming
> connections.
Minor nit, but this is wrong. You need to understand the archtectural
relationships between some of the components. The protocol handler is used
after a new connection is established. Rejecting a new connection based
upon busy state would happen elsewhere.
As I've said before, please feel free to contribute. If you're interested
in working on JMX for James, got for it. :-)
Avalon has been using http://mx4j.sourceforge.net/.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Server statistics (was: Personal IP blacklists)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Note that on its face JMX is a services framework similar to avalon but with
less cruft and without the compiler-time checks (for better or worse). My
stuff is a JMX SMTP Service for Jboss + later I'll do POP, IMAP and
Exchange...
If you know who I am, you know I'm the guy to do such a crackheaded thing.
-Andy
On 6/16/03 5:45 PM, "Richard O. Hammer" <RO...@EarthLink.net> wrote:
> A week or more ago on this list I saw mention of JMX
> <http://java.sun.com/products/JavaManagement/>, though I did not pay
> close attention to that thread, so perhaps I'm repeating something
> here. I've read the first 15% of the JMX spec, and I have the
> impression that JMX is intended for uses such as monitoring server
> statistics and setting server control parameters, such as number of
> incoming connections per unit time and others which I listed earlier.
>
> I imagine that the class doing the work would have a variable which
> holds the statistic we care about. For instance SMTPHandler might
> keep an int connectionsDuringLastMinute, which value could be sampled
> and displayed on a little gauge like the temperature gauge on the
> dashboard of my car.
>
> Similarly, that class could have a control variable, an int
> connectionsPerMinuteLimit, which the administrator could set, if
> needed, with a knob (or the best GUI equivalent) right under the
> gauge. This would cause SMTPHandler to refuse or defer some incoming
> connections.
>
> That class might also keep a SortedSet of the IP addresses currently
> sending in the most mail, giving the administrator ability to limit
> the incoming rate from any given IP, just as easy as closing one of
> the windows a little bit in a car with electric windows.
>
> Logging comes to us from an age before GUIs. It still serves some
> purposes well, but, for managing current, ongoing problems, much
> better pictures and real-time controls are within reach (hopefully
> speaking).
>
> Anyhow, do others think of JMX as useful for such monitoring and control?
>
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Steve Brewin <sb...@synsys.com>.
> -----Original Message-----
> From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
> Sent: 16 June 2003 22:46
> To: James Developers List
> Subject: Re: Server statistics (was: Personal IP blacklists)
>
>
> A week or more ago on this list I saw mention of JMX
> <http://java.sun.com/products/JavaManagement/>, though I did not pay
> close attention to that thread, so perhaps I'm repeating something
> here. I've read the first 15% of the JMX spec, and I have the
> impression that JMX is intended for uses such as monitoring server
> statistics and setting server control parameters, such as number of
> incoming connections per unit time and others which I listed earlier.
>
JMX is a greatly enhanced, Java flavoured version of SNMP. It really is the
way to go for publishing server-side statistics in a Java environment. These
statistics can then be viewed in any JMX enabled tool, or using a JMX to
SNMP bridge, an SNMP tool. All enterprise class monitoring tools watch SNMP
statistics, a few speak JMX. Some J2EE app. servers include JMX monitors and
Sun has a reference implementation.
It is hard to see why any effort aimed at producing a range of James server
stats. should be doing anything other than publishing them via JMX. Maybe
open-source JMX monitors exist? I don't know, but leveraging or developing
one would be better than developing a James specific monitoring tool.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Server statistics (was: Personal IP blacklists)
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
A week or more ago on this list I saw mention of JMX
<http://java.sun.com/products/JavaManagement/>, though I did not pay
close attention to that thread, so perhaps I'm repeating something
here. I've read the first 15% of the JMX spec, and I have the
impression that JMX is intended for uses such as monitoring server
statistics and setting server control parameters, such as number of
incoming connections per unit time and others which I listed earlier.
I imagine that the class doing the work would have a variable which
holds the statistic we care about. For instance SMTPHandler might
keep an int connectionsDuringLastMinute, which value could be sampled
and displayed on a little gauge like the temperature gauge on the
dashboard of my car.
Similarly, that class could have a control variable, an int
connectionsPerMinuteLimit, which the administrator could set, if
needed, with a knob (or the best GUI equivalent) right under the
gauge. This would cause SMTPHandler to refuse or defer some incoming
connections.
That class might also keep a SortedSet of the IP addresses currently
sending in the most mail, giving the administrator ability to limit
the incoming rate from any given IP, just as easy as closing one of
the windows a little bit in a car with electric windows.
Logging comes to us from an age before GUIs. It still serves some
purposes well, but, for managing current, ongoing problems, much
better pictures and real-time controls are within reach (hopefully
speaking).
Anyhow, do others think of JMX as useful for such monitoring and control?
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org