RE: Monitoring
James does have rudimentary JMX support at the moment, thanks to Avalon. What James really needs is instrumentation points (or whatever) in the code so whatever monitoring framework we use we can get useful data out. However I think the implementing some of the RFC 2789 structures would be a good idea as it would give future JMX implementations somewhere to start. -- Jason > -Original Message- > From: Steve Short [mailto:[EMAIL PROTECTED] > Sent: 04 December 2003 22:49 > To: [EMAIL PROTECTED] > Subject: Monitoring > > > > I've been taking a look at what it would take to add some > monitoring to James. I think it would be useful to base > James monitoring on the SNMP MTA MIB as defined in RFC 2789 > (http://www.ietf.org/rfc/rfc2789.txt?number=2789). I'll > briefly summarise the data structures defined in the RFC. > Firstly, there is a top-level structure for the MTA as a > whole called mtaEntry, this contains the following fields: > >mtaReceivedMessages >mtaStoredMessages >mtaTransmittedMessages >mtaReceivedVolume >mtaStoredVolume >mtaTransmittedVolume >mtaReceivedRecipients >mtaStoredRecipients >mtaTransmittedRecipients >mtaSuccessfulConvertedMessages >mtaFailedConvertedMessages >mtaLoopsDetected > > Following this there is a table of 'group' entries each > called mtaGroupEntry, where a group can be anything we define > it to be. Groups can also be hierarchic, so there might be > one group called "Queues" and this could have children such > as "Spool Queue", "Outgoing Queue" and there might be another > group called "Processors" with children "root", "transport", > "error", "spam" etc. The following is a partial list of the > group fields: > >mtaGroupIndex >mtaGroupName >mtaGroupDescription >mtaGroupMailProtocol >... >mtaGroupReceivedMessages >mtaGroupRejectedMessages >mtaGroupStoredMessages >mtaGroupTransmittedMessages >... >mtaGroupReceivedVolume >mtaGroupStoredVolume >mtaGroupTransmittedVolume >... >mtaGroupReceivedRecipients >mtaGroupStoredRecipients >mtaGroupTransmittedRecipients >... >mtaGroupOldestMessageStored >... >mtaGroupLastInboundActivity >mtaGroupLastOutboundActivity >... > > Not all fields need be used by all groups. Value fields > within groups may or may not be additive. So the > mtaGroupStoredMessages value for "Spool Queue" and "Outgoing > Queue" would be accumulated in the mtaGroupStoredMessages > value of their parent group "Queues" to show the total number > of messages currently queued. But the > mtaGroupReceivedMessages field of the Processor children need > not accumulate in the "Processor" record. Likewise the group > records may or may not accumulate into the top level mtaEntry record. > > So does it seem to the members of this list like a good idea > to base James monitoring on these basic structures? > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring
> I've been taking a look at what it would take to add some monitoring to > James. > So does it seem to the members of this list like a good idea to base > James monitoring on these basic structures? Without doing more than scanning the rfc it looks like a good idea. Perhaps you could save me some leg(brain?)work by describing (briefly at a high-ish level) how you see implementation being achived in James? d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
On Wednesday 03 December 2003 15:19, Noel J. Bergman wrote: > Soeren Hilmer wrote: > > On Monday 01 December 2003 16:30, Noel J. Bergman wrote: > > > What about modifying DNSServer.findMXRecords to use getAllByName > > > instead > > of > > > > getByName in the event that there are no MX records? > > > > But there is an MX record, but with multiple A records associated. > > What do you mean? That you have this? > > MX 10 mail > > mail A aaa.bbb.ccc.ddd > mail A sss.ttt.uuu.vvv Yes, this is exactly what I mean. > > > I believe that I need to do a double loop in RemoteDelivery to solve this > > In my view, it should be done by our DNS lookup code. See RFC 2821, > section 5: > >The destination host (perhaps taken from the preferred MX record) may >be multihomed, in which case the domain name resolver will return a >list of alternative IP addresses. It is the responsibility of the >domain name resolver interface to have ordered this list by >decreasing preference if necessary, and SMTP MUST try them in the >order presented. > > So it is handling a multihomed destination that needs to be addressed. Yes, this is what needs to be addressed. Now the problem of handling it at the DNS lookup level (which I agree is the conceptually right thing to do) is that the logging from RemoteDelivery gets more cryptic as the link to the MX record is lost, you will get log lines like: Attempting delivery of Mail1069955581999-mail to host aaa.bbb.ccc.ddd to addresses [EMAIL PROTECTED] where I would prefer to get something like: Attempting delivery of Mail1069955581999-mail to host mail at address aaa.bbb.ccc.ddd to addresses [EMAIL PROTECTED] --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring
Steve Short wrote: I've been taking a look at what it would take to add some monitoring to James. I'm very interested in SNMP w/Java in general, but not particularly James. Do you have a library in mind to use it? I remember finding one or two poorly-maintained projects, and I think LGPL as well. I'd be curious in rate (#/time) and bandwidth (mb/time) of transfer, and storage info (# in spool, # in inboxes, mb in spool, mb in inboxes, etc...) I'm not sure how they map to all the named you suggested. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
Søren Hilmer wrote: > Noel J. Bergman wrote: > > In my view, it should be done by our DNS lookup code. See RFC 2821, > > section 5: > > > > The destination host (perhaps taken from the preferred MX record) may > > be multihomed, in which case the domain name resolver will return a > > list of alternative IP addresses. It is the responsibility of the > > domain name resolver interface to have ordered this list by > > decreasing preference if necessary, and SMTP MUST try them in the > > order presented. > > > > So it is handling a multihomed destination that needs to be addressed. > the problem of handling it at the DNS lookup level (which I > agree is the conceptually right thing to do) is that the > logging from RemoteDelivery gets more cryptic as the link > to the MX record is lost The return is a Collection of String objects. Each one is currently of the form "host", but if we were to handle multi-homed hosts by using "host/IP", it seems to me that we could either parse it directly, or change the way we construct the URLName. Thoughts? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
> > What do you mean? That you have this? > > MX 10 mail > > mail A aaa.bbb.ccc.ddd > mail A sss.ttt.uuu.vvv Yes, this is exactly what I mean. Apparrently this is not an uncommon setup, and the current code will only try the aaa.bbb.ccc.ddd address. > > > I believe that I need to do a double loop in RemoteDelivery to solve this > > In my view, it should be done by our DNS lookup code. See RFC 2821, > section 5: > >The destination host (perhaps taken from the preferred MX record) may >be multihomed, in which case the domain name resolver will return a >list of alternative IP addresses. It is the responsibility of the >domain name resolver interface to have ordered this list by >decreasing preference if necessary, and SMTP MUST try them in the >order presented. > > So it is handling a multihomed destination that needs to be addressed. Yes, that is exactly what needs to be addressed, the problem of doing it at the DNS lookup level (which I agree is the conceptually right thing to do) is that then the returned addresses (by the getMailServers call) bears no information to the original MX record, and the log-lines from RemoteDelivery gets more cryptic like: James.Mailet: RemoteDelivery: Attempting delivery of Mail1056370039520 to ho st [aaa.bbb.ccc.ddd] to addresses [EMAIL PROTECTED] where I would prefer: James.Mailet: RemoteDelivery: Attempting delivery of Mail1056370039520 to ho st mail at [aaa.bbb.ccc.ddd] to addresses [EMAIL PROTECTED] Now to achive both nice logging and handling of multihornedness. I would (going back to the original question) either add a new method to MailetContext or use DNSServer directly in RemoteDelivery, the easiest (which is what I currently have done) is to add the MailetContext method, but unfortunately this is not just an addition to James but to the Mailet API as well. Not that this bothers me a lot, as additions of methods does not break backwards compatibility. -Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
Søren, For some reason, you've answered twice. Was the first one from this morning the one that you e-mailed me to say you thought was lost? > > MX 10 mail > > mail A aaa.bbb.ccc.ddd > > mail A sss.ttt.uuu.vvv > Yes, this is exactly what I mean. Apparrently this is not an uncommon setup, > and the current code will only try the aaa.bbb.ccc.ddd address. > Yes, that is exactly what needs to be addressed, the problem of doing it at > the DNS lookup level (which I agree is the conceptually right thing to do) is > that then the returned addresses (by the getMailServers call) bears no > information to the original MX record I believe that I addressed that in an earlier post this morning (the "host/IP" proposal). InetAddress.getAllByName(String host) gets all of the IP addresses, and InetAddress.toString() provides the correct format for each. That ought to address the issues you raised. Thoughts? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
Firstly to answer Serge's question: I've looked around for Java SNMP libraries and the most fully developed ones are commercial (obviously) or GPL. The only decent usable LGPL one I've found is Joesnmp, which is currently part of the Opennms project but is in the process of becoming an independent project at Sourceforge. While Joesnmp is currently a client only library - I have created a simple server session class and implemented a very crude SNMP agent using it. It's really ugly hackery but I can load my agent as a JMX Mbean (in JBoss) and I can map simple SNMP OIDs to attributes within MBean instances. No prizes for guessing where I'm going with this! However my knowledge of SNMP is severely limited and I need to find out more about how JMX SNMP adaptors are expected to behave before doing any more on this front. Back to Monitoring in James. I was thinking in broad terms of implementing a Monitor service block. The Monitor service would be exposed via JMX (automatically thanks to Phoenix and hopefully Merlin). The monitor service configuration would allow declaration of groups and act as a factory for other components that wish to be monitored. The pre-declared groups would likely be the aggragating groups and the individual services could then acquire a monitor record as a child of any of the predeclared groups. E.g the monitor config might look like this: (The group elements can nest recursively if need be). Each component the wishes to register for monitoring would have a config element like this: ... SMTP Protocols AggregateToParentAndRoot This causes the SMTPServer to create a new monitor record as a child of Protocols and with an aggregation strategy that causes it to propagate counter updates to its parent "Protocols" and to the top level MTA Entry record. I'm not yet sure whether it is sufficient to declare the aggregation stragety for the whole record or whether we would need to specify this at the individual field level. I'm not too worried about this as the aggregation strategy would be realised by a Java class so we could always add a new strategy specific for, say, SMTP called SMTPAggregationStrategy which only propagates the fields it needs to. However any better ideas in this are would be most welcome. I di think about declaring all of the group records in the monitor config section, but that wont work so well for James entities such as the RemoteDelivery Queues and Processors because the monitor service should not need additional confiruation when a new processor is added, hence the approach above where each component registers with the monitor service. I've already knocked up a quick test and I have the SMTP Server received message counts being exposed via JMX and I've used MC4J to create a real-time graph of messages received - jumping the gun a little but so very cool I couldn't resist. What remains to be done: - agree a design - decide on a default monitor hierarchy - determine which stats get updated by each service - decide which service stats get propagated to the root mta record I'd like to be able to expose the individal group records, e.g. spool queue or the outgoing queue as JMX Mbeans so make it possible to monitor these via JMX directly - however I don't think the container exposes its ServiceManager to James. I can do it using JMX calls but if Stephen McConnell is reading - please treat this as a feature request for Merlin's JMX implemtation. Oh, as part of this effort, it would make sense to split the RemoteDelivery mailet into a block and a mailet, with all of the threading and repository management taken care of by the block and the mailet would simple invoke the block when it has a message to send. All thoughts welcome. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
> The Monitor service would be exposed via JMX (automatically > thanks to Phoenix and hopefully Merlin). > The monitor service configuration would allow declaration of > groups and act as a factory for other components that wish > to be monitored. My suggestion would be to use JNDI for this purpose, and to have a JNDI context containing the metrics. ../metrics/protocols/SMTP/.. An SNMP service would expose an SNMP protocol view of the information in the metrics context. A component would get its metrics context and interact with the beans that we'll probably store there. So long as we have a suitably common interface, the rest is automagic. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring
Steve Short wrote: I can do it using JMX calls but if Stephen McConnell is reading - please treat this as a feature request for Merlin's JMX implemtation. I'm reading ;-) Right now I'm in the process of pulling together the next release of Merlin. The main *feature* of the new release will be a much cleaning embedding strategy based on a bunch of improvements from Alex (Apache Directory Project). This is resulting in the cleanup of the high level kernel classes. Another feature that that is somewhat exploritory (blame this one on Eric from the Turbine project) is the introduction of a seperate root container for system services. This system container will enable the plugging in of system extensions (e.g. a full blown logging sub-system, or a JMX server, or JMX adapter, etc.). Basically this will make things a lot easier for Merlin users to change what it is that is Merlin - much in the same way as a block defintion changes what it is that Merlin does. I'm not sure how much of the adaptive profiling will make it into the next release (target end of Decemner) but anyway - I figure it's worth mentioning the relevant developments. As far as JMX is concerned the root kernel is already MBean enabled and is an active event generator (reflecting changes to kernel state). What still needs to be done is the exposure (via the kernel) of the subsidiary applicance mbeans - but more internal event structure is needed before this becomes available. However - this means that the exposure of client MBeans is not far off - but that opens up the question of how a client declares an mbean - should we be using the @ tags, if so, which tags, phoenix stle or or there something we can synchronize with in terms of Gerinimo development? If you or other have thoughts on this I'm real interested in getting feedback, suggestions, options, etc. Cheers, Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring
Noel J. Bergman wrote: The Monitor service would be exposed via JMX (automatically thanks to Phoenix and hopefully Merlin). The monitor service configuration would allow declaration of groups and act as a factory for other components that wish to be monitored. My suggestion would be to use JNDI for this purpose, and to have a JNDI context containing the metrics. I would have thought you would have used something like javax.management.NotificationBroadcasterSupport I.e. things happen - raise an event. Ok - so this is what I'm doing inside the Merlin Kernel. Thing is that at the end of the day you want to expose these event via JMX ... no? Stephen. ../metrics/protocols/SMTP/.. An SNMP service would expose an SNMP protocol view of the information in the metrics context. A component would get its metrics context and interact with the beans that we'll probably store there. So long as we have a suitably common interface, the rest is automagic. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
It was not my intention to provide direct SNMP access to these stats in the near term. I thought about using JNDI but would rather focus more on the JMX approach and wait until JNDI is a part of the Container / James architecture before going that way. At that point SNMP access is avaialable to anyone using an SNMP Agent from Sun, AdventNet, iReasoning etc. Using JMX I was also thinking of providing a command line tool a la vmstat / iostat but I guess that could be done with RemoteManager. Steve > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Friday, December 05, 2003 10:13 AM > To: James Developers List > Subject: RE: Monitoring > > > > The Monitor service would be exposed via JMX (automatically > thanks to > > Phoenix and hopefully Merlin). > > > The monitor service configuration would allow declaration of groups > > and act as a factory for other components that wish to be monitored. > > My suggestion would be to use JNDI for this purpose, and to > have a JNDI context containing the metrics. > > ../metrics/protocols/SMTP/.. > > An SNMP service would expose an SNMP protocol view of the > information in the metrics context. A component would get > its metrics context and interact with the beans that we'll > probably store there. So long as we have a suitably common > interface, the rest is automagic. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
> As far as JMX is concerned the root kernel is already MBean > enabled and is an active event generator (reflecting changes > to kernel state). > What still needs to be done is the exposure (via the kernel) > of the subsidiary applicance mbeans - but more internal event > structure is needed before this becomes available. However - > this means that the exposure of client MBeans is not far off > - but that opens up the question of how a client declares an > mbean - should we be using the @ tags, if so, which tags, > phoenix stle or or there something we can synchronize with in > terms of Gerinimo development? > > If you or other have thoughts on this I'm real interested in > getting feedback, suggestions, options, etc. I like the xdoclet tags because it means you don't have to create the .mxinfo files by hand. I couldn't find out a whole lot about the approach being taken by Geronimo on the Apache incubator site. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
> > My suggestion would be to use JNDI for this purpose, and to have a JNDI > > context containing the metrics. > I would have thought you would have used something like > javax.management.NotificationBroadcasterSupport The J2EE Management Specification (aka JSR 77) uses events for management. But I don't see anything in Chapter 6 (Performance Monitoring) to indicate that the event mechanism is expected to be used for metric gathering. The specification talk about the external side of the Stats and StatisticsProvider interfaces. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
Noel J. Bergman wrote:
Søren Hilmer wrote:
...
So it is handling a multihomed destination that needs to be addressed.
I want to make sure I understand this issue. I've put some debugging
statements into org.apache.james.dnsserver.DNSServer, which print out
Record.toString() in places of interest. Today, when I call
findMXRecords("yahoo.com"), the subsequent lookup("yahoo.com",
Type.MX); returns the following three records, shown here before they
are sorted for priority order.
yahoo.com. 2320 IN MX 1 mx2.mail.yahoo.com.
yahoo.com. 2320 IN MX 5 mx4.mail.yahoo.com.
yahoo.com. 2320 IN MX 1 mx1.mail.yahoo.com.
The problem being discussed here is that host mx2.mail.yahoo.com. may
exist at several IP addresses (i.e., that a subsequent lookup of
mx2.mail.yahoo.com. may produce several A records.)(?) So that if,
after sorting for priorities, we decide to connect to
mx2.mail.yahoo.com. , then we need to try each of the IP addresses for
mx2.mail.yahoo.com. before we go on to try the next host-name in our
priority ordering (which would be mx1.mail.yahoo.com.) Is that the
problem?
Do we know for sure that the JavaMail code underlying the call:
transport = session.getTransport(urlname);
(in method RemoteDelivery.deliver(Mail, Session)) does not do this for us?
Do you have an example, Søren, of a MX host which you know has
multiple A records, so that I can test with it?
The return is a Collection of String objects. Each one is currently of the
form "host", but if we were to handle multi-homed hosts by using "host/IP",
it seems to me that we could either parse it directly ...
I guess this may require an additional call to the underlying
DNSServer.rawDNSLookup(), because I don't think
DNSServer.findMXRecords() ever has the redundant A records. This is
interesting -- but with my ignorance of DNS I am just guessing.
Rich
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Monitoring in James (was Monitoring)
We could do it this way.
The Monitor service is effectively a registry of name to metrics object
mappings, so it provides register() and lookup() methods to set and
retrieve these mappings. This can be be done using JNDI. The naming
scheme provides an implied hierarchy. It does not know or do anything
about aggregating metric values. Eventually we could provide several
implementations of the service one for JMX, one for SNMP. Or one
implentation with multiple adaptors (SNMP, AgentX) - kind of like way
JMX has HTTP and RMI adaptors.
The monitored services are responsible for creating and registering
metrics sets, they are also responsible for setting up the aggregation
rules using event listeners using information obtained from the config
file. Something like this:
metrics/mta/protocols/SMTP
metrics/mta/protocols
metrics/mta/
We could drop the type if we give top level MTA metrics the full set of
group metrics and simply ignore the ones that aren't used or relevant.
Protocol specific adaptors such as SNMP would be responsible for
ignoring unwanted attributes.
Would result in initialization code equivalent to:
MonitorMetrics mtaMetrics =
(MonitorMtaMetrics)monitor.lookup("metrics/mta");
MonitorMetrics protocolMetrics =
(MonitorMetrics)monitor.lookup("metrics/mta/protocols");
MonitorMetrics metrics = (MonitorMetrics)new
MonitorMetricsSet();
metrics.addListener(protocolMetrics);
metrics.addListener(mtaMetrics)
monitor.register("metrics/mta/protocols/SMTP", metrics);
Actual metric updates would be done using methods such as:
metrics.addMessageReceived(long deltaCount, long deltaSize, long
deltaRecipients);
metrics.addMessageStored(long deltaCount, long deltaSize, long
deltaRecipients);
metrics.subtractMessageStored(long deltaCount, long deltaSize, long
deltaRecipients);
metrics.addMessageTransmitted(long deltaCount, long deltaSize, long
deltaRecipients);
metrics.addMessageConversion(long deltaCount);
metrics.addLoopDetected(long deltaCount);
This makes the monitor service much simpler, but it puts a lot more
burden on the individual components to set up the hierachy associations
and the aggregation using listeners. It also makes mistakes much more
likely because the full name strings have to be specified multiple times
in the config file and have match, but I guess good error detection and
reporting would alleviate this somewhat. There's also the issue of how
and when to create group entries such as "Protocols" that don't have a
direct implementation point in James - this could be done automatically
at register() time but means that typos will result in new entries being
created instead of useful error messages being output.
More thoughts?
Steve
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2003 10:13 AM
> To: James Developers List
> Subject: RE: Monitoring
>
>
> > The Monitor service would be exposed via JMX (automatically
> thanks to
> > Phoenix and hopefully Merlin).
>
> > The monitor service configuration would allow declaration of groups
> > and act as a factory for other components that wish to be monitored.
>
> My suggestion would be to use JNDI for this purpose, and to
> have a JNDI context containing the metrics.
>
> ../metrics/protocols/SMTP/..
>
> An SNMP service would expose an SNMP protocol view of the
> information in the metrics context. A component would get
> its metrics context and interact with the beans that we'll
> probably store there. So long as we have a suitably common
> interface, the rest is automagic.
>
> --- Noel
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
Stephen J. McConnell wrote: > Right now I'm in the process of pulling together the next release of > Merlin. The main *feature* of the new release will be a much cleaning > embedding strategy based on a bunch of improvements from Alex (Apache > Directory Project). > If you or other have thoughts on this I'm real interested in getting > feedback, suggestions, options, etc. Alex, myself, and (AIUI) James Strachan are all of the mind that it would be very useful, indeed important, for the Avalon container (e.g., Merlin) to support JSR 77/88 directly. http://www.jcp.org/en/jsr/detail?id=77 http://www.jcp.org/en/jsr/detail?id=88 Like them or not, those are the standard Java specifications for management and deployment. Enabling components written to use those specifications to be directly supported by in Avalon container would make such a container far more attractive, and would allow the Avalon container to leverage work being done for those JSRs. There is code in the Geronimo CVS that does this (as explained by James, the actual Geronimo kernel *is* a JSR 77/88 container), so you would not be starting from scratch. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Monitoring
Yes this is the next critical step. I think everyone at Avalon would be in favor of this since it has surprisingly become the basis for IoC in the J2EE container world. Yes, I'm all for it as Noel says! Once the repo release is complete is suspect this is the next priority concern. What do you say Steve? Alex > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Friday, December 05, 2003 1:53 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; James Developers List > Subject: RE: Monitoring > > Stephen J. McConnell wrote: > > > Right now I'm in the process of pulling together the next release of > > Merlin. The main *feature* of the new release will be a much cleaning > > embedding strategy based on a bunch of improvements from Alex (Apache > > Directory Project). > > > If you or other have thoughts on this I'm real interested in getting > > feedback, suggestions, options, etc. > > Alex, myself, and (AIUI) James Strachan are all of the mind that it would > be > very useful, indeed important, for the Avalon container (e.g., Merlin) to > support JSR 77/88 directly. > > http://www.jcp.org/en/jsr/detail?id=77 > http://www.jcp.org/en/jsr/detail?id=88 > > Like them or not, those are the standard Java specifications for > management > and deployment. Enabling components written to use those specifications > to > be directly supported by in Avalon container would make such a container > far > more attractive, and would allow the Avalon container to leverage work > being > done for those JSRs. There is code in the Geronimo CVS that does this (as > explained by James, the actual Geronimo kernel *is* a JSR 77/88 > container), > so you would not be starting from scratch. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
