127.0.0.1, yet I see indications that this won't fly in a pure IPv6
world. If a single value won't work, is there any good way to detect
which stacks are available via Java APIs during deployment?
--
Jess Holle
It seems that java.net.InetAddress.getLoopbackAddress().getHostAddress()
should give the right answer -- if one is running with Java 7.
That said, is there a value that can be used for AJP's address
attribute that simply does the right thing here?
On 1/23/2015 1:38 PM, Jess Holle wrote:
I'd
,
On 1/23/15 3:35 PM, André Warnier wrote:
Jess Holle wrote:
It seems that
java.net.InetAddress.getLoopbackAddress().getHostAddress() should
give the right answer -- if one is running with Java 7.
That said, is there a value that can be used for AJP's address
attribute that simply does the right
/portable behavior?
--
Jess Holle
-starter.
[Yes, you could always reproduce the issue with Java connectors, but
that's painful and there are, of course, other reason for avoiding
native libraries, e.g. having to build them across the numerous
architectures one supports, rather than simple write-once-run-anywhere.]
--
Jess Holle
for these issues and found nothing helpful.
Should 7.0.55 work with Java 8 as is? If not, what is necessary to
make it work?
--
Jess Holle
Sorry for the false alarm.
A little more digging showed that an old ECJ was getting used at runtime
-- because it had been thwacked into the runtime classpath. [Don't ask.]
It now works fine.
On 8/29/2014 9:14 AM, Mark Thomas wrote:
On 29/08/2014 14:56, Jess Holle wrote:
I have a web
requests due to
recyling behavior!
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
be greatly
appreciated!
--
Jess Holle
it is relevant):
* Sprint 3.2.2
* JDK 7u51
--
Jess Holle
On 4/7/2014 10:21 AM, Jess Holle wrote:
We're seeing a bizarre failure of getParameterMap() wherein this
servlet API returns an empty map.
I thought we'd loused this up somehow via our servlet request filters,
but the debugger shows
seem like it should be...
Tinkering with the internal state of the Request object, to set
parametersParsed to false and/or parameterMap to null in the debugger
doesn't help getParameterMap() succeed, though...
--
Jess Holle
On 4/7/2014 11:52 AM, Jess Holle wrote:
P.S. The only way I
Thanks for the pointers -- I'll make good use of these.
As for #2, yes, the value of getQueryString() is as per expectations.
On 4/7/2014 1:01 PM, Konstantin Kolinko wrote:
Several quick thoughts
1. What is the value of
request.getAttribute(org.apache.catalina.parameter_parse_failed)
Thanks!
On 7/10/2013 5:18 AM, Mark Thomas wrote:
On 10/07/2013 00:06, Jess Holle wrote:
Is there an ETA (in terms of both a version and rough date) for Tomcat
moving to the new spec versions introduced by Java EE 7?
Tomcat 8.
Implementation complete? Best guess is a couple of months
Is there an ETA (in terms of both a version and rough date) for Tomcat
moving to the new spec versions introduced by Java EE 7?
I'm talking about new servlet, JSP, EL, etc, specs, not about
non-web-tier stuff that's not even part of Tomcat.
--
Jess Holle
environments can leverage WebSockets in any
substantive fashion.
--
Jess Holle
Note:
If you use various things like RMI and CMS GC and don't set one or two
key properties you'll always have a perm gen leak.
It's a nice feature of CMS :-)
On 5/21/2013 10:44 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fachhoch,
On 5/21/13 10:53 AM,
On 5/3/2013 11:58 AM, Rainer Jung wrote:
Although AFAIR last time it couldn't do my favorite quotient of
deltas, but until now I haven't found a standard tool doing that.
Average response time in last intervall = delta(cumulatedResponseTime)/
On 5/3/2013 12:26 PM, Rainer Jung wrote:
On 03.05.2013 19:03, Jess Holle wrote:
On 5/3/2013 11:58 AM, Rainer Jung wrote:
Although AFAIR last time it couldn't do my favorite quotient of
deltas, but until now I haven't found a standard tool doing that.
Average response time in last intervall
http://blogs.cisco.com/security/linuxcdorked-faqs/ claims this is not a
cPanel vulnerability per se...
On 5/2/2013 6:22 AM, Darryl Lewis wrote:
Last Friday (April 26), ESET and Sucuri simultaneously blogged about the
discovery of Linux/Cdorked, a backdoor impacting Apache servers running
and override the necessary methods. This is a
lot easier to read than InvocationHandler code required by the dynamic
proxy approach. I'd bet that most who end up doing any substantive work
in this area end up creating their own reusable pass-through wrapper
classes for easy extension.
--
Jess
On 2/4/2013 9:32 AM, Williams, Nick wrote:
-Original Message-
From: Jess Holle [mailto:je...@ptc.com]
...
It's that you can't make Java source code which /implements /JDBC interfaces
and make it compilable with both Java 6 and Java 7. The JDBC interfaces have
new methods in Java 7
As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
to pre-compile all our JSP pages.
When doing so I get a huge number of new failures which boil down to the
following stack trace. Any ideas here? I can dig in to try to see
what's causing this, but this is new
:36 PM, Violeta Georgieva wrote:
2013/1/17 Jess Holle je...@ptc.com
As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
to pre-compile all our JSP pages.
When doing so I get a huge number of new failures which boil down to the
following stack trace. Any ideas here? I can
Stick with the older ecj -- the newer one is broken.
On 1/10/2013 9:22 PM, Ralph Schaer wrote:
Hi
Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file
of tomcat-embed-jasper still points to version 3.7.2 of ecj.
Is it safe to use ecj 3.7.2 with Tomcat 7.0.34?
It's unfortunately not
an issue in ECJ.
--
Jess Holle
On 12/13/2012 1:07 AM, Mark Thomas wrote:
Jess Holle je...@ptc.com wrote:
I moved to Tomcat 7.0.34 -- apparently with inadequate testing / too
much trust.
Some JSPs that precompiled just fine with 7.0.33 and many previous
Tomcat versions now produce the error shown
compiler until proven otherwise.
--
Jess Holle
[jasper2] java.lang.ArrayStoreException:
org.eclipse.jdt.internal.compiler.ast.ReturnStatement
[jasper2] at
org.eclipse.jdt.internal.compiler.flow.FinallyFlowContext.recordNullReference(FinallyFlowContext.java:440)
[jasper2
Well, don't give Oracle too much credit -- or grief.
According to various articles (look them up, I didn't save the URLs),
they were notified of these vulnerabilities ~4 months ago.
Unfortunately several days ago serious attacks in the wild using these
vulnerabilities were discovered --
, Tony Anecito wrote:
Thanks Everyone. I agree on the security issue just seemed the last couple of
updates had no substance beyond just security. MS sends updates quite often but
I look forward to advances in other areas like performance ect.
Regards,
-Tony
--- On Fri, 8/31/12, Jess Holle je
On 8/17/2012 3:18 PM, Konstantin Kolinko wrote:
2012/8/16 Jess Holle je...@ptc.com:
It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat
web app, BCEL chokes on the Java 7 specific byte-code therein ala
org.apache.tomcat.util.bcel.classfile.ClassFormatException
then, can I completely exclude this jar from annotation scanning?
--
Jess Holle
On 8/16/2012 11:14 AM, Pid * wrote:
On 16 Aug 2012, at 17:10, Jess Holle je...@ptc.com wrote:
It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat web
app, BCEL chokes on the Java 7 specific byte-code therein ala
The only way I know to address this obnoxious issue is to create your
own custom RMIClassLoaderSpi and install it early enough.
The custom RMIClassLoaderSpi is very simple:
public String getClassAnnotation( final Class cl )
{
return ( null ); // we don't need no stinking
more heap under 32-bit
addressing. How much depends on the OS, etc, but generally is much more
like 3GB.
--
Jess Holle
On 5/16/2012 8:04 AM, André Warnier wrote:
Miguel Gonzalez wrote:
there wasn't a limit of 32 bits OS for running JVM for more than 1.5 Gb?
Not exactly. I'm not sure
So I read that the servlet 3.1 spec (and related EL specs, etc) is to go
final in the second half of 2012.
Approximately when should we expect a Tomcat that supports the new specs
-- in terms of number of months after the specs' final release?
--
Jess Holle
On 3/13/2012 8:49 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 3/13/12 8:47 AM, Jess Holle wrote:
So I read that the servlet 3.1 spec (and related EL specs, etc) is
to go final in the second half of 2012.
Approximately when should we expect a Tomcat
How can this be a low priority JVM bug!?!
On 3/7/2012 11:21 AM, Konstantin Kolinko wrote:
2012/3/7 Kari Scottkari.sc...@cdw.com:
We are using Tomcat 7.0.23 with jdk1.6.0_30 on Solaris 10, mod_ajp 1.3 and
Apache 2.2.21.
I'm using the following code to retrieve memory information from our
. This is maddening when
nothing has changed -- the compiler should produce the same results in
any case. This particular issue is hard enough to reproduce that I've
not had a chance to try it with 3.7.1.
--
Jess Holle
On 3/1/2012 9:50 AM, Jess Holle wrote:
In some cases we are seeing:
2012-03-01 18:43:55,624 ERROR [ajp-bio-9920-exec-2]
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/PDMPJL100].[jsp]
- Servlet.service() for servlet [jsp] in context with path
[/PDMPJL100] threw exception
either ignore this (ouch) or really dig into debugging
Tomcat's internals (which while far easier than trying to do so with
httpd is still not where I'd wanted to spend my time).
--
Jess Holle
On 2/4/2012 5:49 PM, Jess Holle wrote:
Yes, I'm using Tomcat authentication. Yes, the issue is after
. The harder part is rebuilding pieces
of Tomcat with full debug information (I'm assuming Tomcat is normally
not built with local variable debug information) and finding my way
through unfamiliar code. But that's life :-)
--
Jess Holle
#saveRequest() and #restoreRequest() methods
and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved
with the correct content body. So now the only question that remains is
why it does not get restored.
--
Jess Holle
On 2/5/2012 9:43 AM, Jess Holle wrote:
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
javac srcdir=java destdir=${tomcat.classes}
debug=${compile.debug}
deprecation=${compile.deprecation}
source=${compile.source}
target=${compile.target
On 2/5/2012 10:38 AM, Jess Holle wrote:
Diving in deeper, I see that AbstractAjpProcessor.action() is setting
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
After that is done, however, I don't see anything that tries to read
AbstractAjpProcessor.bodyBytes
don't
want to maintain this patch forever (nor have everyone else suffer from
this bug in the AJP case).
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
On 2/5/2012 11:22 AM, Jess Holle wrote:
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I think adding the following line
On 2/5/2012 11:24 AM, Jess Holle wrote:
On 2/5/2012 11:22 AM, Jess Holle wrote:
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I
On 2/5/2012 12:04 PM, André Warnier wrote:
Hi.
I've just been following this thread, and this is not about the
problem per se, but a comment about the overall design of the
application.
The fact that you do a POST without being authenticated, and that you
rely on the server to save the
On 2/5/2012 12:22 PM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle je...@ptc.com:
Also it strikes me that maxSavePostSize should really be backed up by a use
of a SoftReference in SavedRequest.
This would allow one to allow relatively large POST bodies to be saved
unless/until this threatened
On 2/5/2012 2:53 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 2/5/12 1:23 PM, Jess Holle wrote:
Certainly this is an optional / quality of implementation feature.
I'm perfectly aware that other form-based authentication solutions
will not save POST
Yes, I'm using Tomcat authentication. Yes, the issue is after
authentication on the POST retry.
On 2/4/2012 12:27 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 2/3/12 5:59 PM, Jess Holle wrote:
Or could this be getting loused up by having a servlet
issues
with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working
in a context that's still using 7.0.23 at the moment.]
I'm left wondering what could be causing the issue.
--
Jess Holle
P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me
now. I'll
In case this makes any difference this is with the AJP BIO connector.
On 2/3/2012 4:51 PM, Jess Holle wrote:
I posted a query recently wherein I thought that POST data was being
lost *only* if the user had been authenticated, their session timed
out, and then they POST'ed to a URL requiring
Or could this be getting loused up by having a servlet request filter
that calls getParameterMap() first thing?
I'd *assume* not -- as that would be pretty hokey...
On 2/3/2012 4:53 PM, Jess Holle wrote:
In case this makes any difference this is with the AJP BIO connector.
On 2/3/2012 4:51
.
Now I see that neither case works.
--
Jess Holle
. In that case, Tomcat fails to deliver the POST data.
I assume this is a known issue/limitation. If not, is there some
configuration setting I'm missing or some such? This is with Tomcat 7.0.23.
--
Jess Holle
feature. I'd argue all servlet engines should really
provide this feature for just this reason. That said, I can live with A.
--
Jess Holle
/ Tomcat behaves this way. If one quickly
restarts Tomcat for some reason and session data is preserved, you
really don't want all the users to have to login again do you?
--
Jess Holle
On 12/6/2011 7:05 PM, André Warnier wrote:
Jess Holle wrote:
When doing a graceful shutdown of Tomcat
.
My remaining question is /why/ Tomcat behaves this way. If one quickly
restarts Tomcat for some reason and session data is preserved, you really
don't want all the users to have to login again do you?
--
Jess Holle
On 12/6/2011 7:05 PM, André Warnier wrote:
Jess Holle wrote:
When doing
.]
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 12/7/2011 11:47 AM, Mark Thomas wrote:
On 07/12/2011 17:04, Jess Holle wrote:
I note that in recent versions of Tomcat (e.g. 7.0.23), the session id
changes when you do a form-based authentication.
I do not see any sort of notice via anything one can listen to via the
servlet API to receive
You get an error when that's what's occurring, though.
On 12/7/2011 12:55 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 12/6/11 6:17 PM, Jess Holle wrote:
Okay, I now notice this plainly stated in the documentation for
JNDIRealm (which I'm using
?
Intentional? Configurable?
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Okay, I now notice this plainly stated in the documentation for
JNDIRealm (which I'm using):
The cached user is *not* saved and restored across sessions
serialisations.
That seems a bit odd...
On 12/6/2011 5:12 PM, Jess Holle wrote:
When doing a graceful shutdown of Tomcat, the sessions
by a login form or
2. Add some other custom header to your response. If it's not there
but you got a 200, then something hijacked the response -- quite
probably a login form.
--
Jess Holle
On 9/1/2011 5:49 PM, Mabry Tyson wrote:
Summary: When requiring form authentication, Tomcat responds
in size.
--
Jess Holle
On 6/22/2011 10:16 AM, Jess Holle wrote:
On 6/22/2011 9:08 AM, Mark Thomas wrote:
Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat should
, Charles R wrote:
From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: Slower start with Tomcat 7.0.14 and higher
Well the classloaders are clearly hierarchical, so only one Class
instance is loaded. The fact that both ClassLoaders can see the jar
does not result in 2 Class objects
I think we need
of internal classloader logic.
Overall I'm pretty confident that things are okay here -- especially as
we've been using and testing this configuration for quite some time now.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr
danger -- other than worse performance in use cases I don't
have -- in me patching my own Tomcat to always use FileUrlJar? Should
this perhaps be a config option? Or possibly a config option based on
file size? [FileUrlJar may only be faster for larger jars from what
little I know...]
--
Jess
to the
previous performance. If, however, #1 explains much of the degradation,
then I'll need to look into excluding jars from scanning, etc.
--
Jess Holle
such a profile here in a bit...
--
Jess Holle
On 6/20/2011 2:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
despite scanning all our jars) cannot be re-attained.
I might go there anyway for *some* of our jars, but I will likely want
to start doing more via annotations and less via web.xml as well -- and
would like to minimize the startup performance penalty entailed in doing so.
--
Jess Holle
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 3:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs
On 6/20/2011 5:05 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 5:47 PM, Jess Holle wrote:
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
Maybe you could move /some/ of them?
The libraries in question are actually loaded by the application
calls before/after this), but not so
easy for an asynchronous request...
--
Jess Holle
On 5/18/2011 6:31 AM, Dan Checkoway wrote:
I've messed around a bit, and I figured out a more reliable way to do
it...but it's pretty nasty. Basically I'm iterating and grabbing the
requestCount attribute from
means for a filter to interject itself between the final write to a
response and stream/socket closure?
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
belatedly discover you want a cardinality of 'n'
rather than 1.
--
Jess Holle
On 5/13/2011 8:56 AM, Caldarale, Charles R wrote:
From: JanAa [mailto:jan.aage...@norse-solutions.com]
Subject: Re: Multiple context paths for single deployment
What I want is an alias for the context so that more than
one
could answer (Mladen?), but
realize there are relatively few involved in mod_jk code.
--
Jess Holle
On 5/3/2011 6:14 AM, Jess Holle wrote:
On 5/3/2011 3:18 AM, Mark Thomas wrote:
As I write this it occurs to me that an AJP-NIO connector would be a big
help to you here. I don't know how much work that would be to write but
with the refactoring already completed for Tomcat 7 it might
working well with the event MPM sounds
like a good thing for us to do.
If mod_event is going to be the default, then ensuring mod_jk works well
with it sounds like a rather critical thing to do.
--
Jess Holle
-
To unsubscribe, e
note that there are noises about broader/better support for
the mod_event MPM worker. Does mod_jk work with mod_event there to
reduce the threads required in Apache?
--
Jess Holle
Or for a somewhat better UI and more capability overall, VisualVM.
[Note that VisualVM's MBean tree is via a plug-in, so you need to
install the plug-in before you get this functionality.]
On 3/14/2011 2:42 PM, Leon Rosenberg wrote:
thanx guys.
Leon
On Mon, Mar 14, 2011 at 11:34 AM, Mikolaj
If you use a recent version of Java 6 both jconsole and VisualVM come
with the JDK (at least in most cases -- VisualVM does not run on or come
with IBM's JVM).
On 3/14/2011 2:55 PM, Jess Holle wrote:
Or for a somewhat better UI and more capability overall, VisualVM.
[Note that VisualVM's
On 3/11/2011 6:04 AM, Jess Holle wrote:
On 3/11/2011 3:22 AM, Mark Thomas wrote:
The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%
The 1
this works against the 65K limit or not.
Note the last 2 results are essentially identical (I didn't compare byte
counts).
Yet when I try this last configuration with the JSP that goes over 65K
it fails with JDT and succeeds with javac.
--
Jess Holle
On 3/12/2011 9:50 AM, Jess Holle wrote
of generics...
Anyway, I guess the page owners will have to try to clean things up.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
as a point of comparison.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
here.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
P.S. This was with Tomcat 7.0.10.
On 3/10/2011 9:10 PM, Jess Holle wrote:
I've been looking at moving to Tomcat 7 from Tomcat 6.
Most things look good.
I have been surprised by one thing, however: Tomcat 7 produces larger
JSP class files than Tomcat 6 from the same JSP source files, tag
.
On 3/10/2011 9:10 PM, Jess Holle wrote:
I've been looking at moving to Tomcat 7 from Tomcat
6.
Most things look good.
I have been surprised by one thing, however: Tomcat 7
produces larger JSP class files than Tomcat 6 from the same
JSP source files, tag libraries, etc. Around 12%
larger
On 3/10/2011 10:34 PM, Caldarale, Charles R wrote:
From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: JSP class size increase in Tomcat 7
Yes, both Java 6 Update 24.
Just to verify, are both instances Tomcat running in the same JVM mode (-client
or -server)? (That shouldn't affect
to go
elsewhere, not return a 404.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
P.S. I certainly want to finish processing requests that are already
being processed -- I want a graceful shutdown.
On 3/9/2011 8:16 AM, Jess Holle wrote:
I want to stop all incoming requests at a given point. I am running
Tomcat within a larger process and I want to stop accepting new
request after the stop/destroy().
--
Jess Holle
On 3/9/2011 8:50 AM, Mladen Turk wrote:
On 03/09/2011 03:26 PM, Jess Holle wrote:
P.S. I certainly want to finish processing requests that are already
being processed -- I want a graceful shutdown.
It's a two way process.
First in mod_jk mark
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
On 3/9/2011 12:50 PM, Mark Thomas wrote:
On 09/03/2011 15:47, Jess Holle wrote:
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
On 3/9/2011 1:40 PM, Mark Thomas wrote:
On 09/03/2011 18:50, Mark Thomas wrote:
On 09/03/2011 15:47, Jess Holle wrote:
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
By the way, I did some more testing and though I would have sworn that
destroy() prevented any further requests in Tomcat 6.0.x it also appears
to allow at least 1 additional request.
On 3/9/2011 1:44 PM, Jess Holle wrote:
On 3/9/2011 1:40 PM, Mark Thomas wrote:
On 09/03/2011 18:50, Mark
ask if these symptoms have been seen by
others.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
1 - 100 of 170 matches
Mail list logo
