Well the exception when invoking destroy() directly is:
2011-03-09 09:28:16,238 ERROR [RMI TCP Connection(13)-10.196.0.84]
org.apache.tomcat.util.modeler.BaseModelMBean - Exception invoking method
destroy
org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
attempted ([before_destroy]) for component [Connector[AJP/1.3-8008]] in state
[STARTED]
at
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:386)
at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:278)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
...
I can kind of understand this -- destroy() does not auto-invoke stop()
and is complaining that the incoming state is not what it expects.
When invoking stop() and then destroy() the destroy() succeeds
[something I missed in my original post], but an exception is still logged:
2011-03-09 09:29:21,939 ERROR [RMI TCP Connection(21)-10.196.0.84]
org.apache.catalina.core.StandardService - Failed to stop connector
[Connector[AJP/1.3-8010]]
org.apache.catalina.LifecycleException: An invalid Lifecycle transition was
attempted ([before_stop]) for component [Connector[AJP/1.3-8010]] in state
[DESTROYING]
at
org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:386)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:212)
at
org.apache.catalina.core.StandardService.removeConnector(StandardService.java:309)
at
org.apache.catalina.connector.Connector.destroyInternal(Connector.java:984)
at
org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:284)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
...
That seems quite inappropriate. Note that Tomcat 6.0.x also logs errors
(but not exception traces) when one attempts to invoke either stop() or
destroy().
What's more troublesome to me is that with every approach I've tried at
least 1 request still gets through. In some cases this request works
normally. In other cases the request gets a 200 and no content or a
404. After this initial request things behave more appropriately --
with the particulars depending on what I try to stop.
It really is troubling me that I have to reach back up to all the web
servers targeting a Tomcat to tell them to take a given Tomcat out of
the rotation rather than just make a simple Java call in Tomcat to tell
it to stop taking new requests.
--
Jess Holle
On 3/9/2011 9:09 AM, Mark Thomas wrote:
On 09/03/2011 15:06, Jess Holle wrote:
So there's no way to do this from the Tomcat side?
The process embedding Tomcat knows it's stopping. It does not
necessarily even have an ability to connect to the web server(s) that
are connecting to it [Apache, IIS, or SJWS, but all via the JK
connector]. I therefore want to say "this Tomcat no longer open for
business" from the Tomcat side while finishing all requests already in
progress.
Also I was somewhat inaccurate/mistaken in my summary of Tomcat 7.0.10
behavior. If you invoke stop() and then destroy() on a connector(),
then an exception is logged /but /the destroy() call succeeds. That
said, when it succeeds you get a 200 with no content on the next
request. The request *after* that is returns a 503 from Apache -- and
presumably would have been load balanced to another Tomcat (I only have
1 in my test at the moment). There's still odd behavior for a single
request after the stop/destroy().
Can you post the Exception? That sounds like a bug that needs to be fixed.
I recall coming across this before. I think it was related to keep-alive
connections and was non-trivial to solve. Open a bugzilla entry and I'll
take another look. No promises though. It might end up as won't fix.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
