On Mon, Apr 8, 2013 at 1:24 PM, Konstantin Kolinko <knst.koli...@gmail.com>wrote:
> 2013/4/8 Jason McIntosh <mcinto...@gmail.com>: > > 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: > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=54808 > > > > 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. > > http://tomcat.apache.org/getinvolved.html > > 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 query. > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Jason McIntosh http://mcintosh.poetshome.com/blog/ 573-424-7612
