tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason McIntosh <>
Subject Re: Patches to Tomcat - number of versions and how to add a JMX attribute
Date Mon, 08 Apr 2013 21:55:34 GMT
On Mon, Apr 8, 2013 at 1:24 PM, Konstantin Kolinko

> 2013/4/8 Jason McIntosh <>:
> > Devs:
> > I wanted to get some input on this patch.  It adds the ability to specify
> > how many versions to remove, when undeployOldVersions is set and parallel
> > deployments occur.  This is my first attempt at patching tomcat, and I’m
> > not totally sure I’ve got everything, have met tomcat standards, etc.
> > Specifically, I'm not sure if I should really add more attributes to the
> > interface or not, as that could break some things if the API was set for
> > 7.0. Here’s the bugzilla link where I submitted this:
> >
> >
> >
> 1. Do not use tab characters. All indenting is done using spaces.
> Most of the code uses "Java formatting" as specified by Sun and as is
> available in many IDEs, but using spaces instead of tabs+spaces combo.
Apologies here - stupid windows system and my IDE configuration.
 Conceptually though is the patch of interest?  It should be applied to the
trunk (I mentioned that in the bugzilla link).  I'll try and get the patch
updated to remove the tab characters and switch to spaces.  The questions I
have are should I be modifying the Host interface or just the concrete
implementation?  Is it appropriate to add additional logging output or is
there a preference to have more of this in JMX attributes/properties?

> >
> > Additionally, I’m working on adding a patch to add a JMX attribute on
> what
> > “current” versions of any given application should be responding to
> > requests (tied to parallel deployments as well).  Any advice on where in
> > the code to start on this?
> A getter/setter and several lines in mbeans-descriptors.xml file.
> I do not understand your description of the feature that you are
> trying to add (“current” versions etc.).  Maybe you can explain it in
> more details?
Specifically, it's hard to tell what version (when two applications with
the same context root have been deployed using parallel deployments) which
tomcat is routing new traffic to.  I'd like to be able to see  (and
query) this in a consistent manner.  From a management perspective, I could
then query all my running tomcat servers to obtain the current version of
all apps deployed to all servers.  I was thinking when the parallel
deployment process kicks off to register a new/updated attribute with the
current version - assuming that the new war is actually a newer version.

> > I’m having a hard time finding where the
> > parallel deployment process kicks in and how to register the JMX
> > attribute.  For example, I saw the HostConfig class (where I added my
> patch
> > code), but I’m not seeing any place where that shows up in JConsole.
>  Based
> > on the mbeans descriptors, I would have thought it’d have shown up under
> > Catalina/Listener but there is no such section in JConsole.  I could add
> a
> > new attribute to the Host JMX definitions to track this, but not sure
> > that’s the right place either.  Wanted to get some advice on this.
> StandardHost and StandardContext should show up.
> If I have "examples##1" and "examples##2" then with current Tomcat
> trunk I see in JConsole
> Catalina -> Host -> localhost
> Catalina -> WebModule -> //localhost/examples##1
> Catalina -> WebModule -> //localhost/examples##2
Yes, but this information doesn't tell you where tomcat is routing traffic
to.  It's obvious to a viewer that "1" is greater than "2", but what about
when you have 3 applications, ie version
"100005004082013080031", "100005004082013090031" and so on (i.e. version,
date and time from a continuous integration server) it's much harder to see
what the current app is running that should be processing requests for a
given context path.  I might be able to query all apps in a running state,
then for each sort them and do this kind of logic, but it seemed to make
sense to me that tomcat should report which version of any given context
path should be responding to new requests.  Conceptually, if the last
element in any WebModule is the current release, that would be fine as
well, but I didn't see that as defined behavior in tomcat.  That's also a
bit trickier to get working than just having a path to an attribute I can

> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Jason McIntosh

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message